What is an SSL/TLS Handshake?

An SSL/TLS handshake is the opening exchange between a client and a server that sets up an encrypted HTTPS session. Despite the name “SSL,” modern sites use TLS (Transport Layer Security). The handshake authenticates the server (and sometimes the client), agrees on cryptographic algorithms, and derives session keys so application data stays confidential and tamper-resistant.

What happens during the handshake?

The client sends a ClientHello with supported TLS versions, cipher suites, random bytes, and extensions (including Server Name Indication). The server answers with ServerHello, its certificate chain, and key exchange material. The client verifies the certificate against trusted authorities, finishes key agreement, and both sides derive shared keys. They then exchange finished messages to confirm the negotiation succeeded.

TLS 1.3 shortens the process compared with TLS 1.2, often saving round trips. Misconfiguration (expired certificates, weak ciphers, or a broken chain) causes browsers to show warnings or fail the connection entirely.

Why fraud and bot detection teams care

The ClientHello is visible before encryption and carries a distinctive layout: versions, cipher order, extensions, and curves. That layout is the basis for TLS fingerprinting and JA3-style hashes used in security products. Real browsers differ from scripting libraries, headless automation, and many bots, so the handshake helps identify non-human traffic even when IP and user-agent look normal.

Platforms that fight click fraud and ad fraud, including ClickPatrol, combine TLS signals with behavior and campaign data. The handshake is not proof of fraud by itself (attackers can mimic popular clients), but mismatches and rare fingerprints raise risk scores and support detection pipelines.