How HTTPS and TLS Work Step by Step

HTTPS is HTTP wrapped in encryption. The "S" stands for Secure, and the security comes from TLS - Transport Layer Security. Every time you see a padlock icon in your browser, TLS is running beneath the HTTP layer, encrypting every byte of data between your device and the server.

But TLS is not magic. It is a carefully sequenced protocol with specific steps that must complete before any encrypted data flows. Understanding those steps reveals both the strength of modern encryption and the points where it can be undermined.

TCP Comes First

Before TLS can begin, a TCP connection must be established. This is the standard three-way handshake: SYN, SYN-ACK, ACK. Only after TCP is ready does the TLS handshake start on top of it.

This means HTTPS requires at least two round trips before any application data can flow - one for TCP, one (or more) for TLS. This latency cost is one reason HTTP/3 switched to QUIC, which combines both handshakes into a single round trip.

The TLS Handshake

The TLS handshake is where the client and server agree on encryption parameters and establish shared secret keys. The exact messages depend on the TLS version, but the core flow is consistent.

Step 1: ClientHello. The client sends a message listing its supported TLS versions, cipher suites (combinations of key exchange, encryption, and hashing algorithms), and a random value called the client random. It may also include the Server Name Indication (SNI) extension, which tells the server which domain the client is trying to reach - essential for servers hosting multiple sites on one IP.

Step 2: ServerHello. The server responds with its chosen TLS version and cipher suite (selected from the client's list), its own server random value, and its digital certificate.

Step 3: Certificate. The server sends its X.509 certificate, which contains the server's public key, the domain name, the issuing Certificate Authority (CA), and a validity period.

Step 4: Key Exchange. Both sides perform a key exchange (typically ECDHE) to derive shared secret material without ever transmitting it directly.

Step 5: Finished. Both sides send a Finished message encrypted with the newly derived keys, proving that the handshake completed successfully and was not tampered with.

sequenceDiagram
    participant C as Client
    participant S as Server
    Note over C,S: TCP handshake already complete
    C->>S: ClientHello - versions, cipher suites, client random, SNI
    S->>C: ServerHello - chosen suite, server random
    S->>C: Certificate - X.509 with public key
    S->>C: ServerKeyExchange - ECDHE parameters
    S->>C: ServerHelloDone
    C->>C: Verify certificate chain
    C->>S: ClientKeyExchange - ECDHE public value
    C->>S: ChangeCipherSpec
    C->>S: Finished - encrypted verification
    S->>S: Derive session keys
    S->>C: ChangeCipherSpec
    S->>C: Finished - encrypted verification
    Note over C,S: Symmetric encryption active
    C->>S: Encrypted HTTP request
    S->>C: Encrypted HTTP response

Figure 1 - The full TLS 1.2 handshake sequence from ClientHello to encrypted data exchange

Certificate Verification

When the client receives the server's certificate, it does not blindly trust it. The client performs a chain of verification steps:

1. Domain match - the certificate's Common Name (CN) or Subject Alternative Name (SAN) must match the domain the client is connecting to.
2. Validity period - the current date must fall within the certificate's Not Before and Not After dates.
3. Chain of trust - the certificate must be signed by a Certificate Authority (CA) that the client trusts. The CA's certificate may itself be signed by a higher CA, forming a chain up to a root CA. Root CA certificates are pre-installed in your operating system and browser.
4. Revocation check - the client may check whether the certificate has been revoked via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol).

If any of these checks fail, the browser shows a certificate warning. This is exactly what happens when a captive portal tries to intercept an HTTPS connection - it cannot produce a valid certificate for the target domain, so the browser flags it.

graph TD
    subgraph "Certificate Chain of Trust"
        ROOT[Root CA - pre-installed in OS/browser] --> INTER[Intermediate CA - signed by Root]
        INTER --> LEAF[Server Certificate - signed by Intermediate]
    end
    subgraph "Client Verification Steps"
        V1[Check domain matches SAN/CN] --> V2[Check validity dates]
        V2 --> V3[Walk the chain to a trusted root]
        V3 --> V4[Check revocation - CRL/OCSP]
        V4 --> V5{All checks pass?}
        V5 -->|Yes| TRUST[Connection proceeds]
        V5 -->|No| WARN[Certificate warning shown]
    end
    LEAF -.-> V1

Figure 2 - Certificate chain of trust and the verification steps a client performs

Key Exchange and Forward Secrecy

The key exchange is the most cryptographically interesting part of TLS. Modern TLS uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) for this step.

In ECDHE, both the client and server generate temporary (ephemeral) key pairs. They exchange their public values, and each side independently computes the same shared secret using their own private key and the other side's public value. This shared secret is never transmitted over the network.

The shared secret is then fed into a key derivation function along with the client random and server random to produce the actual encryption keys used for the session.

The "ephemeral" part is critical. Because new key pairs are generated for every session, compromising the server's long-term private key does not allow decryption of past sessions. This property is called forward secrecy. Even if an attacker records encrypted traffic today and steals the server's private key next year, they still cannot decrypt the recorded sessions.

Older TLS configurations used RSA key exchange, where the client encrypted the pre-master secret directly with the server's public key from the certificate. This works, but lacks forward secrecy - if the server's private key is ever compromised, all past sessions encrypted with that key can be decrypted. TLS 1.3 removed RSA key exchange entirely for this reason.

The Record Layer

Once the handshake completes, all data flows through the TLS record layer. This layer takes the application data (HTTP requests and responses), breaks it into records of up to 16 KB, and processes each record through three operations:

1. Compression - historically optional and now disabled (it enabled the CRIME attack)
2. Encryption - using the symmetric cipher agreed during the handshake, typically AES-128-GCM or AES-256-GCM
3. Authentication - a MAC (Message Authentication Code) or AEAD tag ensures the record was not modified in transit

AES-GCM is an AEAD (Authenticated Encryption with Associated Data) cipher, meaning encryption and authentication happen in a single operation. This eliminates an entire class of attacks that exploited the separation of encryption and authentication in older cipher modes like CBC.

Each record includes a sequence number to prevent replay and reordering attacks. The receiver decrypts the record, verifies the authentication tag, and passes the plaintext up to the HTTP layer.

TLS 1.2 vs TLS 1.3

TLS 1.3, finalized in 2018, is a significant simplification and security improvement over TLS 1.2.

Fewer round trips. TLS 1.3 completes the handshake in one round trip (1-RTT) compared to two for TLS 1.2. For resumed connections, TLS 1.3 supports 0-RTT, sending encrypted data in the very first message - though 0-RTT data is vulnerable to replay attacks and must be used carefully.

Fewer cipher suites. TLS 1.3 removed all cipher suites that lacked forward secrecy or used outdated algorithms. Only five cipher suites remain, all using AEAD encryption. No more RSA key exchange, no more CBC mode, no more RC4, no more SHA-1.

Encrypted handshake. In TLS 1.3, the server's certificate is encrypted during the handshake, preventing passive observers from seeing which certificate (and thus which site) the server presented. In TLS 1.2, the certificate was sent in plaintext.

Removed features. TLS 1.3 eliminated compression, renegotiation, static RSA key exchange, custom DHE groups, and several other features that had been sources of vulnerabilities.

graph LR
    subgraph "TLS 1.2"
        A12[2-RTT handshake] --> B12[RSA or ECDHE key exchange]
        B12 --> C12[Certificate in plaintext]
        C12 --> D12[37 cipher suites]
        D12 --> E12[CBC and GCM modes]
    end
    subgraph "TLS 1.3"
        A13[1-RTT handshake + 0-RTT option] --> B13[ECDHE only]
        B13 --> C13[Certificate encrypted]
        C13 --> D13[5 cipher suites]
        D13 --> E13[AEAD only - GCM and ChaCha20]
    end

Figure 3 - Key differences between TLS 1.2 and TLS 1.3

Why Captive Portals Fail Against HTTPS

Captive portals work by intercepting network traffic and redirecting it to a login page. With HTTP, this is straightforward - the portal intercepts the plaintext request and returns a 302 redirect to its own page.

With HTTPS, this breaks down. The captive portal cannot read the encrypted request, and it cannot forge a valid TLS response because it does not have a certificate trusted by the client for the target domain. Any attempt to intercept results in a certificate error in the browser.

This is why modern captive portal detection uses specific HTTP (not HTTPS) probe URLs. Apple devices check http://captive.apple.com/hotspot-detect.html, Android checks http://connectivitycheck.gstatic.com/generate_204, and Windows checks http://www.msftconnecttest.com/connecttest.txt. These are deliberately HTTP so captive portals can intercept them.

The BLEShark Nano's evil portal feature works within this framework. When a device connects and sends its captive portal detection probe over HTTP, the Nano intercepts it and serves its own portal page. HTTPS traffic passes through untouched because interception would require certificate forgery that browsers would immediately flag.

Understanding this boundary between HTTP and HTTPS is essential for anyone working in network security. TLS does not prevent all attacks, but it makes passive eavesdropping and active interception dramatically harder - which is exactly the point.