TLS Handshake

The TLS handshake is the setup phase of every HTTPS connection. In it, the client and server agree on a protocol version and cipher, the server authenticates itself, normally with a certificate, and the two establish the shared keys that will encrypt the rest of the session — ideally with perfect forward secrecy so those keys are ephemeral. TLS 1.3 streamlined the process to as little as one round trip. In a resumed TLS 1.3 session, optional early data (0-RTT) can be sent before the handshake completes. Early data has weaker replay protection and should be limited to requests that can be safely repeated.

Protocol reference: RFC 8446, 2.3.

The handshake is also a rich source of identity. The client's opening ClientHello lists its supported ciphers, extensions and versions in an order that varies by software, and that pattern is exactly what a TLS fingerprint — encoded as JA3 or JA4 — captures. So the same handshake that secures your data can also reveal what client made it. A proxy relays the handshake untouched and changes only your IP; the fingerprint is set by your client, which is why matching a real browser's handshake is a client-software problem, not a network one.

The handshake also determines your TLS fingerprint, so the same negotiation that secures your data can reveal what client made it via JA3 or JA4. A proxy relays the handshake untouched and changes only your IP, meaning fingerprint control is a client-software problem. For automation, use software that negotiates TLS like a real browser and keep your User-Agent consistent with it, so a strict server sees one coherent story rather than a contradiction.