How HTTPS and TLS Really Work: Handshake Explained

You typed https:// in front of a URL, saw the padlock, and moved on. But when a certificate expires at 2 a.m., a mixed-content warning breaks your checkout page, or a client asks why their API call fails with a TLS error, "the padlock means it's secure" stops being a useful answer. This article explains what actually happens on the wire during an HTTPS connection and how to configure it without guesswork.

What HTTPS Adds to HTTP

HTTPS is plain HTTP carried inside a TLS (Transport Layer Security) session. TLS provides three concrete guarantees:

• Confidentiality — traffic is encrypted, so intermediaries cannot read it.
• Integrity — tampering in transit is detected and the connection fails.
• Authentication — the server proves it controls the private key for the certificate presented.

Note what is not on that list: HTTPS says nothing about whether the server is trustworthy, whether the application has vulnerabilities, or whether the data is safe at rest. It protects the pipe, not the endpoints.

The TLS Handshake, Step by Step

The handshake is the negotiation that happens before any HTTP bytes flow. In TLS 1.3 it takes a single round trip; TLS 1.2 needs two. Here is the TLS 1.3 flow in plain terms:

1. ClientHello — the client sends supported TLS versions, a list of cipher suites, a random nonce, and a key share for a Diffie-Hellman key exchange (typically X25519).
2. ServerHello — the server picks a version and cipher suite, returns its own key share, and sends its certificate chain plus a signature over the handshake transcript.
3. Key derivation — both sides compute the shared secret from the Diffie-Hellman exchange. Ephemeral keys mean the session key is unique and forward secrecy holds: compromising the server's long-term key later does not decrypt recorded traffic.
4. Finished — both sides send a MAC over the transcript. If anything was altered, the handshake aborts.
5. Application data — HTTP requests and responses are encrypted with symmetric keys derived from the shared secret.

The certificate is where authentication lives. The server signs the handshake with its private key; the client verifies that signature using the public key in the certificate, then verifies the certificate itself against a trusted root CA, checking the hostname, validity dates, and revocation status.

Symmetric vs Asymmetric: Why Both Are Used

Asymmetric cryptography (RSA or ECDSA) is slow but solves key distribution. Symmetric ciphers (AES-GCM, ChaCha20-Poly1305) are fast but require a shared key. TLS uses asymmetric crypto only during the handshake to establish a symmetric session key, then encrypts bulk data with that key. This is why a modern TLS 1.3 connection is fast: one round trip, then cheap AES or ChaCha20 for everything else.

Cipher Suites and What Actually Matters

A cipher suite is a named bundle of algorithms. In TLS 1.3 the list is short and all options are considered safe; in TLS 1.2 you must choose carefully. A quick comparison:

Practical takeaway: enable TLS 1.2 and 1.3 only, disable TLS 1.0/1.1, and prefer ECDSA certificates for lower handshake cost. Let your server or reverse proxy pick the suite order; most defaults are sane in 2024-era software.

How to Inspect a Real Connection

You do not need to trust documentation — verify your own endpoints. openssl s_client shows the negotiated version, cipher, and certificate chain:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Look at the Protocol and Cipher lines, then check the certificate chain output for expiry and SAN entries. If the chain is incomplete, some clients will fail while browsers succeed, which is a classic source of "it works in Chrome but not in curl" bugs.

Common HTTPS Misconfigurations

• Missing intermediate certificate — the server sends only its leaf cert. Browsers may fetch the intermediate, but API clients often will not.
• Mixed content — an HTTPS page loads a script or image over HTTP; browsers block or downgrade it. Audit with your browser console.
• No HSTS — without Strict-Transport-Security, a first request over HTTP can be intercepted before the redirect happens.
• Weak or outdated protocol versions — leaving TLS 1.0 enabled for a legacy client quietly weakens every connection.
• Certificate expiry — automate renewal; a manual calendar reminder is not a strategy.

A Reasonable Server Configuration

For Nginx, a minimal modern block looks like this:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

The fullchain.pem file is what prevents the missing-intermediate problem. Keep the redirect from port 80 in a separate server block so HTTP still works for ACME challenges.

What HTTPS Does Not Protect

Once the request reaches your server, TLS is done. Injection flaws, broken access control, leaked secrets in logs, and misconfigured CORS all live above the transport layer. Treat TLS as the baseline, not the security program. If you are debugging an incident, separate transport problems (handshake failures, expired certs) from application problems (500s, bad payloads) early — they have completely different fixes.

FAQ

Does HTTPS encrypt the URL path and query string?

Yes. In HTTPS, the entire HTTP request, including the path and query string, is inside the encrypted TLS record. However, the hostname (SNI) and destination IP are visible during the handshake unless Encrypted Client Hello is in use.

Is TLS 1.3 always faster than TLS 1.2?

Usually, because it saves a round trip and supports 0-RTT resumption. On high-latency connections the difference is noticeable; on a local network it is minor. The bigger win is that TLS 1.3 removes legacy cipher options entirely.

Do I still need HSTS if I redirect HTTP to HTTPS?

Yes. A redirect only helps after the browser has reached your server. HSTS tells the browser to skip HTTP entirely for future requests, closing the window where a first request could be intercepted.

When you are auditing a deployment and need to check certificate details or decode a captured handshake quickly, keep a terminal-based workflow handy — and if you are documenting the findings for a team, the Markdown editor is a fast way to turn raw openssl output into a readable report.