Subscribe to our
weekly update
Sign up to receive our latest news via a mobile-friendly weekly email
Explore our blog post to uncover everything you need to know about how to dissect TLS using Wireshark today. Learn more.
The primary goal of the Transport Layer Security protocol as defined in RFC 2246 (TLS version 1.0) is “to provide privacy and data integrity between two communicating applications.” The TLS protocol ensures this by encrypting data so that any third party is unable to intercept the communication; it also authenticates the peers to verify their identity. By providing a secure channel of communication between two peers, TLS protocol protects the integrity of the message and ensures it is not being tampered.
History
TLS and SSL are used interchangeably. TLS evolved from SSL protocol (SSL 3.0) that is no longer considered secure; vulnerabilities such as POODLE attack has demonstrated this. TLS has gone through two iterations, RFC 4346 (TLS 1.1) and RFC 5246 (TLS 1.2), with the latest update TLS 1.3 being a working draft.
Architecture
TLS lies in between the application and the transport layer. It is designed to work on top of a reliable transport protocol such as TCP (but has been adapted to UDP, as well) and is divided into two sub-layers:
Analyzing TLS handshake using Wireshark
The below diagram is a snapshot of the TLS Handshake between a client and a server captured using the Wireshark, a popular network protocol analyzer tool.
Let’s analyze each step.
Typically, the first message in the TLS Handshake is the client hello message which is sent by the client to initiate a session with the server.
The message contains:
where
TLS = protocol version
RSA = Key exchange algorithm determining the peer authentication
3DES_EDE_CBC = bulk encryption algorithm used for data encryption
SHA-1 = Message Authentication Code which is a cryptographic hash.
The server responds to the client with multiple messages:
The Server Hello contains the following information:
The server sends the client a list of X.509 certificates to authenticate itself. The server’s certificate contains its public key. This certificate authentication is either done by a third party (Certificate Authority) that is trusted by the peers, the operating system and the browser which contains the list of well-known Certificate Authorities or by manually importing certificates that the user trusts.
This message validates whether the server’s X.509 digital certificate is revoked or not, it is ascertained by contacting a designated OCSP (Online Certificate Status Protocol) server. The OCSP response, which is dated and signed, contains the certificate status. The client can ask the server to send the “certificate status” message which contains the OCSP response. This approach is known as OCSP Stapling. The process saves bandwidth on constrained networks as it prevents OCSP servers from getting overwhelmed with too many client requests.
The client, to indicate that it wants a certificate status message, includes an extension of the type “status_request” in the Client Hello request.
The message is optional and sent when the public key present in the server’s certificate is not suitable for key exchange or if the cipher suite places a restriction requiring a temporary key. This key is used by the client to encrypt Client Key Exchange later in the process.
This is optional and is sent when the server wants to authenticate the client, for e.g. a website where the server needs to confirm the client’s identity before providing access to private information. The message contains the type of certificate required and the list of acceptable Certificate Authorities.
This message indicates the server is done and is awaiting the client’s response.
This message contains:
This message notifies the server that all the future messages will be encrypted using the algorithm and keys that were just negotiated.
The Finished message is complicated as it is a hash of all the messages exchanged previously along with a label (“client finished”). This message indicates that the TLS negotiation is completed for the client.
Note: Wireshark displays the Finished message as Encrypted Handshake since, unlike the previous messages, this message has been encrypted with the just negotiated keys/algorithms.
The server informs the client that it the messages will be encrypted with the existing algorithms and keys. The record layer now changes its state to use the symmetric key encryption.
Like the Client Finished message but contains a different label (“server finished”). Once the client successfully decrypts and validates the message, the server is successfully authenticated.
Once the entire TLS Handshake is successfully completed and the peers validated, the applications on the peers can begin communicating with each other.
The article gives a brief explanation of how the TLS Protocol works and the analysis of the TLS handshake using a powerful tool like Wireshark. One important thing to note is applications should not rely on TLS to create the strongest secure connection between the peers as it is possible for a hacker to make the peers drop down to the least secure connection. Also, the use of TSL/SSL could impact performance (explained here). Hence, a clear understanding of the protocol will help evaluate its advantages and vulnerabilities.
Read the ebook Monitoring Network Protocols to learn Digital Experience Monitoring can help improve network performance.