During the TLS 1.2 handshake, the server sends its public key as part of the Server Hello. This process of securely exchanging a shared secret is typically accomplished using public key cryptography where the client and the server use a public-private key pair.

The second round trip ensures that client and server securely exchange the master secret, which is necessary to encrypt/decrypt the application data that is subsequently sent. As shown in the diagram below, this first round trip of the SSL handshake comprises of the Client Hello (that advertises supported client cipher suites including the key sharing options) and the Server Hello (that includes server certificate containing the public key and the chosen cipher suite).įigure 2: A full TLS 1.2 handshake requires two network round trips. The first round trip is spent learning the server’s capability so that the client and server can agree on how to share the master secret used to encrypt the data transfer. In TLS 1.2 and earlier, the starting assumption is that the client knows nothing. The TLS handshake process ensures appropriate cryptographic information is shared between client and server before secure data transfers can take place. This has caused a healthy debate in the Internet Security community around the need to revisit the TLS handshake process (among other security enhancements) to provide better security in a shortened negotiation cycle. According to a study by researchers at Microsoft, an additional 250ms of delay resulted in a 1.5% decrease in revenue. Combined with DNS resolution and TCP connection time it could take well over 500ms before the first byte of content can be transferred. A TLS handshake requires two round-trips adding up to 300ms for every new HTTPS session. Every network round-trip adds approximately 150ms of latency to a web request. To quantify the impact of slow SSL times, imagine a user in London, UK trying to access a service that is hosted in San Jose, CA. As HTTPS has become the de-facto standard for all web communication over the last few years, this extra cost of ensuring web security has been a necessary but problematic component for businesses looking to expand their digital footprint. Enforcing stricter web security requirements have traditionally been tied with higher load on clients, servers, and networks. Security and performance have historically been seen as tradeoffs. One of the primary goals of TLS 1.3 is to address this inefficiency within the TLS handshake by reducing the network round trips required to encrypt a session and simplifying cipher negotiation. There’s a great discussion on this topic in our blog post on the anatomy of an HTTP(S) request. The SSL phase of an HTTP GET request can often be the slowest component of response time because the SSL handshake requires two network round-trips before encrypted data transfers can take place. Figure 1: Components of HTTP Response Time.

Performing a tls handshake firefox