Transport Layer Security (TLS) Zero to Hero .. Part-3
In this article I’ll recap the concepts that I explained in Part1 and Part2. If you have already thorough with other two part, you may skip the recap part and start from the packet capture section. TLS also has multiple version and currently anything less than TLS1.2 is considered unsecure and most of the communications are moving to TLS1.3. There is significant difference between TLS 1.2 and 1.3. Part of the data that are eachanged are encrypted in 1.3 whereas similar data were clear during TLS 1.2. I’ll show the packet capture of TLS1.2 as you can easily see what data are being exchanged and then I’ll explain a bit what changed in TLS 1.3.
Recap…
If you are very familiar with these, you can skip this section.
Asymmetric Key Pair : Cryptographic key pair, private and public key. One key can encrypt some data and only another key can decrypt that data. Public key is shared publicly while private key is private to digital entity.
Digital Signature: Hash is generated from the data using hashing algorithm and then the generated hash is encrypted using one of the cryptographic key. This encrypted hash is the digital signature. Usually sender generates the signature using own private key and data along with signature is sent. Receiver validates the signature to be sure that data is intact. Purpose of digital signature is to ensure data intigrity, NOT encryption.
Digital Certificate : Some approved CA digitally signs the public key of a digital entity. Usually certificate includes few details like Common Name, Organisation etc. details of the digital entity along with the public key. This is the identity of a digital entity. There is a concept of self-signed certificate as well. That is like an organisation trusting identity issued by them, but outside the organisation, other people might NOT trust that identity.
Certificate Authority (CA) : A certificate authority is a company or organisation that acts to validate the identities of entities (such as websites, email addresses, companies, or individual persons) and bind them to cryptographic keys through the issuance of digital certificates. They issues the digital certificates that are trusted by other digital entity. They have to undergo regular audits to make sure that they are following all rules and regulations.
Symmetric vs Asymmetric encryption: In case of symmetric algorithm encryption and decryption is done using same key whereas asymmetric encryption involves a key pair, named private and public key, and one key is used to encrypt the data and another key to decrypt the data. Asymmetric encryption/ decryption is computationally much more expensive than Symmetric encryption.
Packet Capture TLS 1.2..
Few important steps in the packet captures are-
- DNS resolution
- 3-way TCP Handshake
- Client Hello
- Server Hello
- Server Certificate transfer
- Client Hello Done
If you look at the packet capture snapshot, you’ll be able to see all the steps in the flow diagram. I’ll provide detailed snapshot for few key packets.
Client Hello Packet…
In this packet client sends the TLS version it can support, it send the list of ciphers that it supports and that is how server knows whether a communication with client is possible or NOT.
Let me explain one of the cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS: self explanatory
- ECDHE: This field refers to the key exchange algorithm used to establish a shared secret key between the client and the server. Few other examples are RSA, PSK, DH etc.
- RSA: This field signifies digital signature algorithm used for server authentication and key exchange. In this cipher suite, this algorithm is used by the server to sign the ephemeral key parameters exchanged during the key exchange process. Few other examples are ECDSA, PSK, DSS, RSA etc.
- AES_128_GCM: This field describes the encryption algorithm used to encrypt data transmitted between the client and the server. Few other examples are CHACHA20, AES_256_GCM, AES_256_CBC etc.
- SHA256: This field indicates the Hash algorithms to be used . Few example of such algorithms are Poly1305, SHA384 etc.
Server Hello Packet…
Server shared the TLS version it supports. It selects one of the cipher from the cipher suit list that client sent during “client Hello”. It shares a session ID that will identify the current session. Also note that both server and client generated own random number and shared with other side. Note that in some cases server can requests clients certificate and in such case server will send a certificate request record in the hello packet so that client knows it has to send it’s certificate.
Server Key Exchange and Hello Done …
In this packet server sends it’s certificate chain. In wireshark, you can write click and export the certificate raw data to a file and inspect details. You can see multiple certificate is shared. Those are the chain of certificates. First one is of server certificate issued (signed) by second one, third oneis the issuer of second one and finally fourth one is the root. Client need to validate that certificate chain is valid and if it trust root, it trusts the server certificate. Server’s public key can be extracted from the server’s certificate itself. Also another very important data that is shared by server is Diffie-Hellman (DH) Parameters. Based on DH parameters client and server can generate same shared key.
With this Server Hello is done and now server will wait for client to respond.
Client Key Exchange…
If client trusts the server, it’ll send key exchange parameter. Note that in my case it sends Diffie Hellman (DH) parameters as both server and client agreed on cipher suit that uses DH. Point to be noted here that in your packet capture you might be able to see RSA algorithm is used for key exchanged and data that are exchanged differers based on the selected algorithm.
Based on the server and clients exchanged keys, using DH algorithm, both server and client can generate same shared secret. At this point client and server both would have below data.
- Client Generated Random number
- Server Generated Random number
- Shared Secret ( in RSA PMS is shared, for DH souple of parameters are shared)
Using the above details client and server both generates four identical key, named client encryption Key, Client HMAC key, server Encryption Key, Server HMAC key. Client encrypts data using client Key and Server encrypts data using Server key. Since both has same key they can easily decrypt the data. HMAC keys are used for data integrity checks.
In case of RSA, client generates pre Master Secret (PMS) using server and client’s random number. Encrypts that PMS using server’s public key. Now only server would be able to decrypt using it’s private key. Then both server and client generates same Master Secret and finally both generates four identical key explained above.
After that both client and server exchanges couple of packets to make sure that both client and server has correct keys and then application data transmission starts.
TLS 1.3…
There are many changes in TLS 1.3. TLS 1.3 prioritised security over backward compatibility. It removed all weak cipher suit support. Also in terms of handshake it reduces the 2 round trip to single round trip.
Here is the details from RFC and packet capture snapshots. You can see that client hello & key Exchange has been clubbed together.
TLS 1.3 itself deserves a seperate article. I am putting up few references for more detailed study.
All Parts:
Transport Layer Security — part 1
Transport Layer Security — part 2
Transport Layer Security — part 3
