TLS and the HTTPS Handshake: What It Costs in Latency

Quick answer: TLS (Transport Layer Security) is the protocol that encrypts web traffic and proves a server's identity; "HTTPS" simply means HTTP carried inside TLS. Setting it up on a new connection costs extra round trips: TLS 1.3 needs one, TLS 1.2 needs two, both after the TCP handshake. The cost in milliseconds is therefore about the round-trip time to the server multiplied by the number of round trips, plus a little CPU time. Reused or resumed connections avoid most of it.

What does TLS actually do?

TLS provides three guarantees for data travelling between two programs, typically a browser and a web server:

• Confidentiality: the content is encrypted, so someone on the same Wi-Fi network or at an ISP cannot read it.
• Integrity: any modification of the data in transit is detected.
• Authentication: the client can verify it is talking to the real owner of the hostname, using a certificate.

TLS sits on top of a reliable transport, normally TCP (see TCP and UDP explained). The browser first opens a TCP connection, then runs the TLS handshake inside it, and only then sends the HTTP request. With HTTP/3, TLS 1.3 is built into QUIC instead and the two handshakes are merged (see HTTP/1.1, HTTP/2, HTTP/3 and QUIC).

TLS does not hide who you are talking to from the network. The destination IP address is visible, and the hostname is usually visible through SNI (explained below). It protects the content, not the fact that a connection exists.

How do certificates and certificate authorities work?

A certificate is a signed document that binds a public key to one or more hostnames. During the handshake the server sends its certificate and proves it holds the matching private key. The client then checks several things:

1. The hostname being visited appears in the certificate's Subject Alternative Name list (wildcards such as *.example.com cover one label only).
2. The current date is inside the certificate's validity period.
3. The certificate is signed by an intermediate certificate, which is signed by a root certificate authority (CA) that is already trusted by the operating system or browser trust store.
4. The certificate has not been revoked, where revocation checking applies.

The chain of signatures from the server certificate up to a trusted root is called the certificate chain. Servers are expected to send the intermediates along with their own certificate. If an intermediate is missing, some clients fetch it themselves (adding delay) and others fail outright.

Public CAs issue certificates after the applicant proves control of the domain. Lifetimes are limited, and the industry has been steadily shortening them, so automated renewal is the norm. A certificate that is not renewed in time is one of the most common causes of "secure connection failed" errors on otherwise healthy sites.

What happens during a TLS 1.2 handshake?

A full TLS 1.2 handshake after the TCP connection is open takes two round trips before the client can send encrypted application data:

1. Round trip 1: the client sends ClientHello (supported versions, cipher suites, random value, SNI). The server answers with ServerHello, its certificate, and its key-exchange parameters.
2. Round trip 2: the client sends its key-exchange share and a Finished message; the server replies with its own Finished.
3. Now the client sends the HTTP request and the server answers.

Including the TCP handshake (one round trip), a first HTTPS request over TLS 1.2 needs three round trips before the request leaves, and a fourth for the response, so roughly 4 RTTs until the first byte of the response arrives, plus DNS beforehand.

What is different in TLS 1.3?

TLS 1.3 (published in 2018) redesigned the handshake so the client guesses the key-exchange method in its first message. The server can then answer with everything needed to finish, so the full handshake takes one round trip. It also removed old, weak algorithms and encrypts more of the handshake, including the certificate.

Step	TLS 1.2 (full)	TLS 1.3 (full)	TLS 1.3 resumed with 0-RTT
TCP handshake	1 RTT	1 RTT	1 RTT
TLS handshake	2 RTT	1 RTT	0 RTT extra (request sent with first flight)
HTTP request and first response byte	1 RTT	1 RTT	1 RTT (shared with handshake)
Total before first response byte	about 4 RTT	about 3 RTT	about 2 RTT

The totals exclude DNS lookup and server processing time. Over QUIC, TCP and TLS are combined, so a first connection needs about 2 RTT total and a resumed one with 0-RTT about 1 RTT.

How much does HTTPS cost in milliseconds?

The formula is simple: extra time = RTT × extra round trips + computation. Computation (key exchange, signature verification) is typically a few milliseconds on modern hardware, and more on weak phones or very busy servers. The round-trip part dominates once distance grows.

RTT to server	TLS 1.3 extra	TLS 1.2 extra	Difference
10 ms (nearby CDN edge)	about 12 to 15 ms	about 22 to 25 ms	about 10 ms
40 ms (same continent)	about 42 to 45 ms	about 82 to 85 ms	about 40 ms
100 ms (another continent)	about 102 to 105 ms	about 202 to 205 ms	about 100 ms
250 ms (far side of the world, or satellite-grade)	about 250 ms	about 500 ms	about 250 ms

Worked example. A visitor in Madrid loads a site whose server is in New York, with a round trip of about 85 ms. DNS is already cached. Over TLS 1.2 the first response byte arrives after about 4 × 85 = 340 ms plus server time. Over TLS 1.3 it is about 3 × 85 = 255 ms. If the same site is served from a CDN edge in Madrid at 12 ms, the same TLS 1.2 sequence costs about 48 ms. Shortening the distance helps every handshake step at once, which is why CDNs matter (see CDN and anycast).

What are session resumption and 0-RTT?

Doing a full handshake every time would be wasteful, so TLS lets a client that has talked to a server before skip the expensive parts.

• Session resumption: after a successful handshake the server hands the client a ticket (or ID in TLS 1.2). On the next connection the client presents it, and both sides derive new keys without exchanging certificates again. In TLS 1.2 resumption cuts the handshake to one round trip; in TLS 1.3 the handshake is already one round trip, but resumption saves certificate transfer and verification work.
• 0-RTT early data (TLS 1.3 and QUIC): a resuming client can send the HTTP request in its very first flight. This removes the handshake wait entirely. The trade-off is that early data is replayable, so servers should accept it only for idempotent requests.
• Connection reuse: the cheapest option is not to reconnect at all. HTTP keep-alive and HTTP/2 keep one TLS connection open for many requests.

Tickets expire (commonly after minutes to hours, set by the server), so a returning visitor after a long gap pays for a full handshake again.

What is SNI and why does it matter?

A single IP address often serves hundreds of HTTPS sites. The server must choose a certificate before it can decrypt anything, so the client includes the desired hostname in the ClientHello. This field is Server Name Indication (SNI). It makes shared hosting and CDNs practical.

Two consequences for testing: connecting to a bare IP address over HTTPS usually produces a certificate error or a default site, because no hostname was supplied or the certificate does not list the IP; and in most networks SNI is visible in clear text, so content filters can block a site by name even though the page content is encrypted. Encrypted Client Hello (ECH) is a newer extension that hides SNI where both sides support it.

What are certificate errors and what do they mean for a latency test?

When validation fails, a browser stops the connection or shows a warning. Typical causes and what they imply:

Error cause	What it usually means	Effect on a timing test
Expired certificate	Server owner failed to renew	Request fails; shows as no reply or error
Name mismatch	Certificate does not list the hostname	Request fails
Unknown issuer / incomplete chain	Missing intermediate, private CA, or device lacks the root	Fails on some devices, works on others
Wrong system date	Your clock is far off, so valid certificates look expired or not-yet-valid	Everything HTTPS fails on your device
Interception by a proxy or antivirus	A middlebox presents its own certificate	Works only if its root is installed; adds delay

For a browser-based tool such as GlobeLatency, a failed TLS handshake produces no usable response, so the destination is reported as "No reply" rather than as a slow time. A destination showing "No reply" for you but working for others may therefore have a certificate problem on your path (corporate inspection, a wrong clock) rather than a network outage. See troubleshooting GlobeLatency for a checklist.

What is mixed content?

Mixed content occurs when a page loaded over HTTPS requests a sub-resource (script, image, API call) over plain HTTP. Browsers block the active kinds outright and may upgrade or block passive ones, because an on-path attacker could rewrite an HTTP response and thereby control the secure page. If you run a site, serve every resource over HTTPS. If you test a custom destination, remember that an http:// address cannot be fetched from an https:// page, so use the https:// form.

How does the handshake show up in first-request timings?

Any measurement that starts a clock before the connection exists includes DNS, TCP, and TLS. That is why the first timing to a host is typically larger than later ones. GlobeLatency's measurements use real HTTPS requests timed from request start until the response headers arrive, so a pass that needs a new connection includes TCP and TLS setup; later passes may reuse the connection, which cache-busting does not prevent (see how GlobeLatency measures). That is also one reason these numbers sit a little above an ICMP ping to the same host (see ping vs HTTPS latency).

Worked example. A visitor is 30 ms from a server over TLS 1.3 with no connection open. Pass 1: TCP 30 ms + TLS 30 ms + request and headers 30 ms plus a few ms of processing, about 95 ms. Pass 2 over the reused connection: about 32 ms. The average of three passes is (95 + 32 + 32) / 3 ≈ 53 ms, while the best pass shows 32 ms. Neither number is wrong; they measure different things. The best pass approximates the network round trip, the first pass approximates a cold visit.

Common mistakes and myths

• "HTTPS makes everything slow." The cost is concentrated in connection setup. Once a connection is open, encryption overhead is small on modern CPUs with hardware AES support.
• "A padlock means the site is trustworthy." It means the connection is encrypted and the name matches. Malicious sites can have valid certificates.
• Comparing a first request with a warmed one. Always say whether a timing includes setup.
• Blaming the network for a TLS failure. Clock errors, proxies, and expired certificates all look like connectivity problems.
• Enabling 0-RTT everywhere. Replayable early data is unsafe for requests that change state.
• Testing an IP address over HTTPS and concluding the server is broken, when the certificate simply does not cover the IP.

What to do next

If you run a site, confirm it negotiates TLS 1.3, sends a complete certificate chain, and uses HTTP/2 or HTTP/3 so connections are reused (HTTP versions explained). To see how setup and server time combine into page load, read TTFB and web performance. To see your own numbers, run a free latency test and compare the best pass with the average; a big gap often points to connection setup or jitter.