What Is TLS and How Does It Secure Connections?

What TLS Does

Transport Layer Security (TLS) encrypts data between two endpoints - typically a browser and a web server. It provides three properties: confidentiality (nobody can read the data), integrity (nobody can modify the data), and authentication (you are talking to who you think you are).

TLS sits between the application layer (HTTP, SMTP, etc.) and the transport layer (TCP). It wraps the application data in encrypted records before TCP transmits them. The application sees a normal stream; the network sees ciphertext.

The TLS Handshake

Before encrypted data flows, client and server negotiate encryption parameters through a handshake. In TLS 1.2, this takes two round trips:

1. Client sends ClientHello: supported TLS versions, cipher suites, random number
2. Server responds with ServerHello: chosen version and cipher suite, its random number
3. Server sends its certificate and optionally requests client certificate
4. Both sides perform key exchange (typically ECDHE) to derive a shared secret
5. Both sides send Finished messages encrypted with the new keys

TLS 1.3 reduces this to one round trip by combining steps. The client includes key share data in the ClientHello, allowing the server to complete the exchange in a single response. For resumed sessions, TLS 1.3 supports 0-RTT (zero round trip) where encrypted data is sent immediately with the ClientHello.

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello + key share
    S->>C: ServerHello + key share + cert
    Note over C,S: Both derive session keys
    S->>C: Finished (encrypted)
    C->>S: Finished (encrypted)
    Note over C,S: All data now encrypted

TLS 1.3 handshake: one round trip to establish encryption. Client and server exchange key shares and derive session keys immediately.

Cipher Suites

A cipher suite specifies four algorithms:

• Key exchange - how the shared secret is derived (ECDHE, DHE)
• Authentication - how the server proves identity (RSA, ECDSA)
• Encryption - how data is encrypted (AES-256-GCM, ChaCha20-Poly1305)
• Hash - how integrity is verified (SHA-256, SHA-384)

TLS 1.3 simplified cipher suites to just five options, all using AEAD (Authenticated Encryption with Associated Data) ciphers. TLS 1.2 supports dozens of cipher suites including legacy options (RC4, DES, MD5) that should be disabled.

Certificates

A TLS certificate binds a domain name to a public key. It is signed by a Certificate Authority (CA) that your browser trusts. The trust chain: server cert signed by intermediate CA, intermediate CA signed by root CA, root CA in your browser's trust store.

Let's Encrypt provides free, automated certificates that renew every 90 days. Before Let's Encrypt, certificates cost money and required manual renewal, which discouraged adoption. As of 2025, over 95% of web traffic uses TLS.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, published 2018) made significant improvements:

• Reduced handshake from 2 round trips to 1 (0-RTT for resumption)
• Removed all legacy cipher suites (only 5 strong options remain)
• Made forward secrecy mandatory (ECDHE required, static RSA removed)
• Encrypted the certificate during handshake (was plaintext in TLS 1.2)
• Simplified the state machine and removed problematic features (renegotiation, compression)

Forward Secrecy

Forward secrecy (also called perfect forward secrecy, PFS) means that compromising the server's long-term private key does not compromise past sessions. Each session uses ephemeral Diffie-Hellman keys that are discarded after use.

Without forward secrecy (static RSA key exchange in TLS 1.2), an attacker who records encrypted traffic today and later obtains the server's private key can decrypt all recorded sessions. With forward secrecy, each session's encryption keys are unique and never stored, making retroactive decryption impossible.

TLS and Wireless Security

TLS is the primary defense against wireless eavesdropping. On an open WiFi network, all traffic is visible to anyone on the same channel. TLS ensures the content remains encrypted even when the WiFi link provides no encryption.

The BLEShark Nano's captive portal operates over HTTP (not HTTPS) because the Nano does not have a CA-signed certificate. This is standard for captive portals - the initial redirect must happen over HTTP since the client has no way to validate a self-signed certificate for an arbitrary domain. Once past the portal, clients should use HTTPS for all subsequent browsing.

Get the BLEShark Nano