Skip to main content

TLS Handshake

Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated: the client and the server must agree on the version of the TLS protocol, choose the cipher suite, and verify certificates if necessary. Unfortunately, each of these steps requires new packet roundtrips between the client and the server, which adds startup latency to all TLS connections.

0 ms
TLS runs over a reliable transport (TCP), which means that we must first complete the TCP three-way handshake, which takes one full roundtrip.
56 ms
With the TCP connection in place, the client sends a number of specifications in plain text, such as the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use.
84 ms
The server picks the TLS protocol version for further communication, decides on a ciphersuite from the list provided by the client, attaches its certificate, and sends the response back to the client. Optionally, the server can also send a request for the client’s certificate and parameters for other TLS extensions.
112 ms
Assuming both sides are able to negotiate a common version and cipher, and the client is happy with the certificate provided by the server, the client initiates either the RSA or the Diffie-Hellman key exchange, which is used to establish the symmetric key for the ensuing session.
140 ms
The server processes the key exchange parameters sent by the client, checks message integrity by verifying the MAC, and returns an encrypted "Finished" message back to the client.
168 ms
The client decrypts the message with the negotiated symmetric key, verifies the MAC, and if all is well, then the tunnel is established and application data can now be sent.

TLS Parameters -

Source -

Popular posts from this blog

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a