http is inherently vulnerable to MitM attacks because client-server communication is transmitted in plaintext over the Internet. This makes http sessions vulnerable to MitM, Session Hijacking, and other dangerous attacks. To remediate this vulnerability, security researchers created https, which stands for Hypertext Transfer Protocol over SSL encryption. Note: Since 2008, we’ve been using TLS 1.2, which is the updated version of SSL 3.0.

https uses both symmetric and asymmetric encryption. Why? Number one, it is more secure. And, number two, asymmetric encryption is too slow to encrypt a large amount of data for a continuous session https session. To solve that problem, we use symmetric encryption. We can map out the steps of establishing an https session in 6 steps. Here’s how it works. If you have trouble visualizing the process, refer to this diagram:

Step 1: ClientHello

The client requests an https session with the Web server. This is accomplished by entering an https address in the URL bar. Let’s just say it is one of the Web servers for https://google.com.

This first initial step is called the ClientHello message. In this message, the client sends a list of cipher suites that it can perform, which are responsible for encryption, authenticity, and data integrity. Also included in the ClientHello is something called a ClientRandom. This is a nonce or cryptographically-generated pseudorandom number.

Finally, the client requests to see the server’s X.509-compliant digital certificate.

Step 2: ServerHello

The Web server responds with a ServerHello message by providing its own ServerRandom. The server also sends over its certificate. Certificates are digital documents issued by Certificate Authorities (CAs). The correct pronunciation is “cahs,” not “C-A’s.” To trust a certificate, the CA that issued the certificate itself must be trusted. Many Web browsers include already-trusted CAs; however, CAs can also be trusted if a copy of their root certificate exists in the “Trusted Root Certification Authority” store. Certificates themselves contain a list of information that is useful to our Web browsers.

As you can see from the certificate pictured above, we have a:

• Serial Number: Uniquely identifies the certificate.
• Issuer: This identifies the CA that issued the certificate.
• Valid from: The certificate is valid from a start date and time.
• Valid to: The certificate is valid until a specified date and time.
• Public Key: Perhaps the most important part of the certificate is the RSA asymmetric public key of the Web server.

Notice that the Web server’s RSA private key is not included in the certificate. Only the Web server is allowed to access the private key. The Server also sends over a hash of its digital signature encrypted with the RSA private key.

Of the Cipher suites provided by the Client, the server picks the strongest one that both parties can perform. For illustrative purposes, let’s say it’s TLS_RSA_WITH_AES_256_CBC_SHA. This means the client and the server will use the TLS transport encryption protocol using Rivest, Shamir, and Adelman (RSA) for authenticity. It will also use an AES-256 key with SHA-256 for message integrity checking.

Step 3: Client Picks Symmetric Key

The client will check to make sure that the certificate is not on a Certificate Revocation List (CRL) and that it’s not expired. CRL is pronounced as “crill.” If all is well, it will accept the certificate. It also decrypts the digital signature with the RSA public key and rehashes it to make sure both hashes match.

The client creates a symmetric key using a symmetric block cipher, such as AES with 256-bit encryption. The AES encryption key is 53. In reality, the key is actually very long, but it’s shortened for this demonstration. This symmetric encryption key will be used to encrypt session data transferred between the client and the Web server. The symmetric key itself is encrypted using the asymmetric RSA public key that was provided by the Web server’s certificate. The symmetric key now becomes a cyphertext (e.g., GH@jkPS). That way, when it travels over the network, it is encrypted and cannot be viewed by eavesdroppers.

Step 4: Client Sends Encrypted Symmetric Key

The client sends the encrypted symmetric key to the Web server. Only the Web server’s private key can decrypt this. Why? Because asymmetric encryption uses two key pairs (a private key and a public key). If the public key encrypts data then the private key decrypts the same data, meaning they both work together. So, even if a hacker intercepts this initial TLS handshake, he would need the private key to decrypt the information, which he does not have access to.

Step 5: Server Decrypts Symmetric Key

The Web server decrypts the client’s symmetric key by using its RSA private key. Now, both the client and the Web server have a shared symmetric key that will be used to encrypt the session data. This symmetric key was transferred over the Internet using asymmetric encryption. And perhaps, most importantly, the symmetric key was sent through what we call an “out-of-band” key exchange because application data will now commence in its own symmetric encryption tunnel.

Step 6: Finished

Now that both the client and Web server know the symmetric key, they can begin communicating over the Internet and exchanging Web page information that is encrypted with the symmetric key. And, that’s it. This all happens so fast that we should show more of an appreciation for how complex it really is.