Skip to main content

TLS: Handshake, Certificates, Why and How

What This Concept Is​

TLS (Transport Layer Security) sits between TCP and the application and provides three properties to the channel above it:

  • Confidentiality -- an on-path observer cannot read the plaintext.
  • Integrity -- an on-path attacker cannot modify the stream undetected.
  • Authentication -- the client knows it is talking to the server named in the certificate (and optionally vice versa with mTLS).

Underneath, TLS uses:

  • Public-key cryptography during the handshake to establish shared secrets without ever transmitting them in the clear.
  • Symmetric cryptography (AES-GCM, ChaCha20-Poly1305) for bulk encryption of records afterwards.
  • X.509 certificates signed by Certificate Authorities (CAs) that the client trusts, forming a chain of trust up to a root CA baked into the OS or browser.

TLS 1.3 (RFC 8446) is the current standard and is considerably simpler than 1.2.

Why It Matters Here​

You cannot talk about HTTP meaningfully without TLS. Every modern web deployment assumes encryption-in-transit. Beyond HTTP, TLS secures SMTP, IMAP, MQTT, gRPC, and most modern RPCs.

More importantly, TLS is a concrete example of a recurring systems pattern: use expensive public-key crypto to bootstrap a session key, then use cheap symmetric crypto for bulk. Understanding that once makes the rest of applied cryptography less mysterious.

Concrete Example​

A simplified TLS 1.3 handshake over TCP:

Client                                                  Server
       ----  TCP 3-way handshake (SYN / SYN-ACK / ACK)  ----

       --- ClientHello ---------------------------------> 
            versions=[TLS 1.3]
            cipher_suites=[TLS_AES_128_GCM_SHA256, ...]
            key_share=<client's ephemeral ECDHE public key>
            server_name="example.com"     (SNI)

       <-- ServerHello ---------------------------------
            selected_cipher
            key_share=<server's ephemeral ECDHE public key>
            {Certificate, CertificateVerify, Finished}   (encrypted)

       --- {Finished} ----------------------------------->

  ... now encrypted application_data records flow both ways ...

After ClientHello + ServerHello both sides can derive the shared secret from ECDHE. The server's certificate is delivered encrypted; the client verifies the signature chain and that the certificate matches example.com. One round trip, then data.

Common Confusion / Misconception​

"HTTPS encrypts the URL." Only the path and query are encrypted. The hostname is sent in plaintext in the TLS SNI extension, and the IP is obviously visible to the network. (Encrypted Client Hello / ECH is the evolving fix for SNI leakage.)

"The certificate is the secret." The certificate is public. What is secret is the server's private key, which the certificate vouches for. Stealing a certificate means nothing without the paired private key.

How To Use It​

For any TLS-protected service:

  1. Ask what identity the certificate asserts (CN / SAN).
  2. Ask what CA signed it and whether the client trusts that CA.
  3. Check for expiry and renewal automation.
  4. Prefer TLS 1.3 and modern AEAD cipher suites. Turn off SSLv3, TLS 1.0, TLS 1.1.
  5. Remember that TLS does nothing about application-layer vulnerabilities above it.

Check Yourself​

  1. Why does TLS use public-key crypto for the handshake but symmetric crypto for the bulk data?
  2. What would change if a Certificate Authority's private key were stolen?
  3. Why is TLS 1.3 a 1-RTT (or even 0-RTT) handshake while TLS 1.2 was 2-RTT?
  4. What does "forward secrecy" mean, and which part of the TLS 1.3 handshake provides it?
  5. Why are self-signed certificates fine for development but not for public deployment?

What TLS Does Not Protect​

It is easier to reason about TLS once you know what is not inside its guarantees:

  • TLS does not protect against a compromised endpoint. If your server is breached, TLS still happily delivers the plaintext to the attacker.
  • TLS does not hide the fact that a connection is happening, nor -- without ECH -- the hostname in SNI.
  • TLS does not protect against time-of-check/time-of-use bugs in your application.
  • TLS does not make revoked or fraudulent certificates go away; it relies on CT logs, OCSP, and short lifetimes to mitigate that.

Confidentiality + integrity + authentication of the channel, nothing more.

Mini Drill or Application​

  1. Run openssl s_client -connect example.com:443 -servername example.com and read the certificate chain it prints.
  2. Identify: the leaf certificate, any intermediates, and the root. Which one is actually sent by the server, and which must be preinstalled on your machine?
  3. Use curl --tlsv1.3 -v https://example.com/ and find the line that reports the negotiated cipher suite.

Read This Only If Stuck​