HTTPS (HyperText Transfer Protocol Secure) is such an amazing protocol that does most of the heavy lifting on Internet. Yet, I feel we do not give enough credits to it. It is an interesting concept that involves quite a few components.
HTTPS is based on SSL/TLS (Secure Sockets Layer/Transport Layer Security) encryption. TLS encryption protocol is used to encrypt network data. The protocol uses encryption, hashing, digital certificates to provide confidentiality, integrity and authentication for data in transit.
- Encryption (Confidentiality):
The main difference between symmetric and asymmetric encryption is the way keys are incorporated for encryption and decryption. Symmetric encryption like AES and 3DES use single key for both encryption and decryption. In other words, one key is generated that encrypts data on one end and the same key decrypts data on the other end. That means, the symmetric key used in this process must be transported, over a medium, to end-users that are intended to view the data. Asymmetric encryption such as RSA and Diffie Hellman use two different keys – one for encryption and one for decryption. The key used to encrypt data cannot be used to decrypt. Asymmetric encryption has a key pair, public key and private key, that are mathematically related. If public key is used to encrypt data, then private key is used for decryption and the other way around. Symmetric encryption suffers key management problem. It is difficult to transport key before a secure tunnel has been established. This calls for use of asymmetric encryption where no actual keys are transported. Only the pre-required key material essential to generate session keys is transported over the network. Session keys never travel on the network. But symmetric ciphers are preferred over asymmetric ciphers for encrypting/decrypting large amount of data as the symmetric ciphers are computationally much faster than asymmetric ciphers. Therefore, conjunction of both symmetric and asymmetric encryption is preferred. Asymmetric encryption is used to generate or exchange the secret keys that are used to derive session keys. Session keys which are also called symmetric keys will be used to encrypt and decrypt large data. Session keys can be one time use keys, they are discarded once the session is completed. This achieves the goal of securing keys, keep it computationally faster, hence making the system robust.
Before we proceed, let’s have a look at TLS handshake:
“Key Exchange” in the above figure is where the asymmetric encryption comes to picture.
Going back to encryption, let’s look at “Key Exchange” in detail.
We now know public (asymmetric) key encryption is used in key exchange during TLS handshake. When using RSA or DSA encryption, client generates pre-master key and this is used on both sides to generate master keys and eventually the session keys. This will be the essential component to arrive at the final keys used to encrypt/decrypt. Now, pre-master key must remain private to protect confidentiality of the session. Client encrypts this key with server’s public key (obtained from servers digital certificate). Only server that has private key of the key-pair can decrypt the message. Both sides now have the pre-master key. Using the parameters exchanged during TLS session and the pre-master key, both sides apply pseudo random function to generate master secret. Sessions keys are eventually derived from master keys on both ends. Master secrets or session keys are never transported on the session. After both the sides have the session keys, data sent back and forth is encrypted and this is going to be symmetric encryption. Because both client and server use the same key (session key). Fig 1.2 shows the steps involved in Key Exchange with RSA(Rivest–Shamir–Adleman).
When using Diffie-Hellman, only the public DH components are sent back and forth. The private components remain remain private to each side. No secret keys essential to produce session keys are shared on the network, therefore these components are not encrypted at all. The term “key exchange” doesn’t make sense when referring to DH algorithm. Sometimes this process is called key generation. DH algorithm works in such a way that whatever components are shared in public domain cannot by themselves be used to compromise the session. That is why the key generation process does not use encryption. Fig. 1.3 depicts the steps involved in Key Exchange with DH.
Wireshark is a strong tool to capture and analyze packets. Let’s see how TLS handshake actually looks when you open up your browser and try to connect an https website.
2. Dissecting TLS with Wireshark
Fig. 2.1 shows the entire TLS handshake. Let’s look at each message closely.
[NB: After capturing this session and working on it, I realized DH encryption is used and therefore Fig. 1.1 changes slightly. Fig 1.4 shows TLS Handshake when DH encryption is used]
In Fig. 1.4 you will notice that in most cases Server Key Exchange happens before Client Key Exchange. That is because both client and server generate their DH components independently.
Let’s get back to our Wireshark packets.
In this capture (Fig. 2.2), we see that the client prefers TLS 1.2 but the minimum it can offer is TLS 1.0. Which means, if server prefers 1.0, client can support that. You also see that client hello record contains random data that the server will need later for authentication of the keys (or handshake in general). Next is the Cipher Suites – this will be the list of ciphers that my browser, safari 12.1, can offer.
Client Hello sends server all ciphers that it supports. Fig. 2.3. This is followed by Server Hello.
The data sent out to client in Server Hello are the TLS version and the cipher chosen by the server and the random string that client will use later for authentication.
Cipher Suite chosen is: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Breaking this down:
TLS – This simply indicates the protocol
ECDHE – Ephemeral Elliptic-Curve Diffie-Hellman public key encryption is used for key exchange
RSA – Algorithm used for authentication is RSA
AES_256_GCM – 256-bit Galois Counter Mode AES encryption for bulk encryption
SHA384 – MAC (Message Authentication Code) Algorithm.
Next packet to follow is Server Certificate (Authentication).
Server sends its certificate to the client. Certificate has information such as the Certificate Authority (CA) or the intermediate CA that has signed it. The domain name, authentication and hashing algorithm that it can support.
You can see that Google Internet Authority G3 is the intermediate authority that issues certificates for all of google domains which are in turn signed by GlobalSign – Root Certificate Authority. When a certificate is signed by intermediate authority, all intermediate CAs must attach the Root CA digitally signed certificate to complete certificate chain.
When client receives this certificate, it checks for three things:
- The digital certificate itself
- The Certificate chain (Intermediate CAs and Root CA)
- Validity of the certificate
- The revocation status of the certificate
We will see key exchange messages next.
We saw that the chosen encryption algorithm is DH, so the server sends the public DH components to client in Server Key Exchange packet and that is followed by Server Hello done through which server conveys it is done passing all the parameters.
Once the client checks out the certificate (authentication accomplished), it sends the public DH components just like server did. This is followed by Change Cipher Spec which indicates all the messages sent by client from on now will be encrypted using the session key. The last message from client to server is the Finished message that has the hash of handshake components encrypted with session key. This will be used by server to ensure integrity of the handshake process. Since it is encrypted, Wireshark labels it as Encrypted Handshake Message. See Fig. 2.8.
The last message of the handshake from server to client will be Change Cipher Spec indicating that the following messages will be encrypted using session key and the encrypted Finished message. Like client, server sends the hash of the handshake components encrypted with session key to ensure integrity. If both client and server determine the other’s finished message is correct, this will open a secure tunnel for bulk data exchange. See Fig. 2.9.
I hope this was informative!