Simply said, HTTPS is just your ordinary HTTP protocol covered in a thick coating of tasty SSL/TLS encryption goodness. It safeguards your passwords, communications, and credit card information on the wire between your computer and the servers you want to send this data to, preventing people like the infamous Eve from viewing or altering requests that make up your browsing experience unless something goes horribly wrong (and it can). Although there is still plenty of rope for both you and the website you are watching to hang yourselves elsewhere, the small green padlock and the letters “https” in your URL bar at least enable you to converse safely while you do so.
1. What does HTTPS do and what is it used for?
HTTPS merely adds an SSL/TLS (hereinafter referred to as “SSL”) encryption layer on top of the well-known and understood HTTP protocol. While communicating with each other through a secure SSL connection that encrypts and decrypts their requests and responses, servers and clients continue to use the exact same HTTP protocol. The SSL layer serves two key objectives:
Making sure that you are speaking with the server you believe you are speaking with and that only the server and you have access to the information the server sends back
Every single message you send and receive from a server can be intercepted by anyone, which is a really, really clever feature. the ones where you both agree on the encryption key and strategy to employ, but no actual data is sent that can be read.
2. The process of establishing an SSL connection
The handshake that establishes an SSL connection between a client and server aims to do the following:
The parties must have agreed on a “cypher suite,” which specifies which encryption technique they will use to communicate data, in order to reassure the client that it is communicating with the appropriate server (and optionally vice versa).
For any necessary keys for this algorithm to have been agreed upon by the parties
Once a connection has been made, both parties can safely communicate with one another using the chosen algorithm and keys. The handshake will be divided into three primary stages: hello, certificate exchange, and key exchange.
Hello – The client initiates the handshake by sending a ClientHello message. This includes the different cypher suites and highest SSL version that the server can support, as well as all the information it needs to establish an SSL connection with the client. The server responds with a ServerHello, which includes the same information that the client requested, as well as a determination of the encryption suite and version of SSL that will be employed based on the client’s preferences.
Exchange of certificates – Now that a connection has been made, the server must demonstrate its identity to the client. This is accomplished by employing its SSL certificate, which resembles its passport just a little bit. An SSL certificate contains a variety of pieces of information, including the owner’s identity, the name of the asset (such as a domain) to which it is tied, the public key of the certificate, the digital signature, and details regarding the certificate’s validity dates. The client verifies that it either explicitly or implicitly trusts the certificate and that it has been checked and trusted by one of many Certificate Authorities (CAs) that it also implicitly trusts. Soon, much more on this. Although the server is permitted to demand a certificate to verify the client’s identity, this rarely occurs, but this only occurs frequently in really private apps.
Key Exchange: A symmetric technique, the details of which were already agreed upon during the Hello phase, will be used to encrypt the actual message data that is sent between the client and server. As opposed to asymmetric algorithms, which demand a public/private key pair, symmetric algorithms use a single key for both encryption and decryption. This single, symmetric key must be agreed upon by all parties; this is done securely via asymmetric encryption and the server’s public/private keys.
A random key is created by the client and used by the primary, symmetric algorithm. It encrypts it with the server’s public key and an algorithm also decided upon during the Hello step (found on its SSL certificate). The relevant sections of the handshake are finished when this encrypted key is sent to the server and decrypted there using the server’s private key. The parties have secretly decided on a key to symmetrically encrypt the data that they are about to send each other since they are confident enough that they are speaking with the correct person. Now, plaintext messages can be formed, encrypted, and sent to convey HTTP requests and answers. Only the opposing party is knowledgeable about how to Man in the Middle Attackers are unable to read or alter any requests that they may intercept since they lack the knowledge necessary to decrypt this message.
An SSL certificate is really just a text file, and anyone with a text editor may create one. In truth, it is simple to make a certificate that indicates you are Google Inc. and the owner of the gmail.com domain. SSL would be a farce if this were the complete story, as identity verification would effectively consist of the client asking the server, “Are you Google? The magic that prevents this farce is in the digital signature, which enables a party to confirm that another party’s piece of paper actually is legit.
There are two reasonable justifications for believing a certificate:
If it appears on a list of certificates you implicitly trust
If it can demonstrate that the controller of one of the certificates on the list above trusts it
The first requirement is simple to verify. You can see, add, and remove trusted SSL certificates from Certificate Authorities (CAs) from the pre-installed list in your browser. These certificates are managed by a centralised set of (theoretically and typically) very safe, trustworthy, and reputable companies like Symantec, Comodo, and GoDaddy. You can trust a server if it displays a certificate from that list.
The second standard is substantially more difficult. A server can simply state, “Yeah, my name is um, Microsoft, you trust Symantec, and um, they absolutely trust me, so it’s all good,” and everything will be fine. Then, a reasonably intelligent client might go to Symantec and inquire, “I’ve got a Microsoft here who say that you trust them, is this true?” You still don’t know whether the server posing as Microsoft is indeed Microsoft or something far worse, even if Symantec says “yes, we know them, Microsoft are legit.” Digital signatures play a role in this.
3.2 Electronic signatures
As mentioned before, SSL certificates come with a public/private key combination. The certificate includes the public key for distribution, while the secret key is held in extremely strict security. During the SSL handshake, this pair of asymmetric keys is used to exchange a different key that will allow both parties to symmetrically encrypt and decode data. The symmetric key is safely sent from the client to the server using its public key, which is also used by the server to encrypt and decode it. The public key can be used to encrypt by anybody, but the private key can only be used to decrypt by the server.
A digital signature works the other way around. The “signing” of a certificate by a different authority practically states that the authority “has verified that the controller of this certificate also owns the property (domain) listed on the certificate.” In this instance, the authority encrypts (generally speaking) the contents of the certificate using their private key, and this cypher text is then appended to the certificate as its digital signature. Anyone can use the public key of the authority to decrypt this signature and confirm that the anticipated decrypted value is obtained. However, as the private key can only be used by the authority to encrypt content, only the authority is capable of producing a legitimate signature in the first place.
Therefore, your browser need not accept the word of a server that claims to hold a certificate for Microsoft.com that is certified by Symantec (or another CA). If it is authentic, Symantec will have created the server’s SSL certificate’s digital signature using their (ultra-secret) private key, and your browser can use their (ultra-public) public key to verify that this signature is legitimate. Since your client trusts Symantec, it can be certain that it is speaking to Microsoft Inc. since Symantec will have taken efforts to guarantee the company they are signing for indeed owns Microsoft INC.
Keep in mind that every root CA certificate is “self-signed,” which means the digital signature was created using the certificate’s own private key. A root CA’s certificate is not inherently exceptional; you can create your own self-signed certificate and use it to sign additional certificates if you like. But since no browsers everywhere have your random certificate pre-loaded as a CA, none of them will trust you to sign either your own or other certificates. Since your credentials are suspect, you are practically saying, “Er yeah, I’m completely Microsoft, here’s an authentic certificate of identity issued and signed by myself,” and all legitimate browsers will display a very ominous error message as a result.
As these are the organisations that their customers ultimately trust to assess websites and keep certificates secure, this places a tremendous duty on all browser and OS publishers to trust only squeaky root CAs. This is not a simple job.