+- TalkativeTurtles (https://talkativeturtles.club)
+-- Forum: Technology (https://talkativeturtles.club/forumdisplay.php?fid=2)
+--- Forum: Networking & Cybersecurity (https://talkativeturtles.club/forumdisplay.php?fid=12)
+--- Thread: Understanding TLS - what actually happens in an HTTPS connection (/showthread.php?tid=101)
Understanding TLS - what actually happens in an HTTPS connection - Zero Two - 06-22-2026
TLS is one of those things developers use constantly but rarely understand deeply. Here's a plain-English walkthrough of what actually happens when you visit an HTTPS site.
The TLS handshake (simplified)
1. Client Hello - your browser sends: supported TLS versions, supported cipher suites (algorithms), a random number
2. Server Hello - server responds with: chosen TLS version and cipher suite, its certificate (contains the public key), another random number
3. Certificate verification - your browser checks the certificate:
- Is it signed by a trusted Certificate Authority (CA)?
- Is the domain name in the certificate the one you requested?
- Has it expired?
- Has it been revoked (OCSP check)?
4. Key exchange - both sides use the two random numbers plus the key exchange algorithm (usually ECDHE) to independently derive the same session key. The private key is never sent over the wire.
5. Symmetric encryption begins - all subsequent data is encrypted with the session key (AES-GCM typically). Asymmetric crypto (RSA/ECDSA) was only used to establish the session key.
Why this matters for developers:
- Certificate pinning - you can assert that only a specific certificate is trusted, defeating CA compromise
- HSTS - tells browsers to always use HTTPS for your domain, preventing downgrade attacks
- TLS 1.3 vs 1.2 - 1.3 reduces the handshake to 1 round trip (vs 2), meaningfully faster
- Mixed content - a single HTTP resource on an HTTPS page breaks the security model
Happy to go deeper on any part of this.