Skip to main content

SSL/TLS Handshake Simulator

Visualize how SSL/TLS handshakes work with certificate verification, key exchange, and cipher negotiation. Compare TLS 1.2 and 1.3 protocols.

Category: Security

Topics covered: security, networking, tls, ssl, certificates, educational

// simulator

SSL/TLS Handshake Simulator

Visualize how SSL/TLS handshakes work with certificate verification, key exchange, and cipher negotiation. Compare TLS 1.2 and 1.3 protocols.

Supported byBecome a sponsor
BitriseAtomsizedDigitalOceanDevDojoSMTPfastQuizAPI

How to use this simulator

Watch how your browser establishes a secure HTTPS connection. Use the Play button for auto-advance, or Next/Prev to step through manually. Each step shows what data is exchanged between client and server.

💡 Tip: Try different TLS versions and failure scenarios to see how the handshake changes.

SSL/TLS Handshake

Visualize how secure connections are established

TLS Version
Scenario
Client
Server
1/5

ClientHello

Client initiates with key share

Client → Server
•TLS version: 1.3
•Random bytes (32 bytes)
•Cipher suites (AEAD only)
•Key share extension (ECDHE)
•Supported versions extension
TLS 1.2 vs TLS 1.3

TLS 1.2

  • • 2 round-trips (2-RTT) to establish
  • • Supports older cipher suites
  • • RSA key exchange still allowed
  • • Separate ChangeCipherSpec message
  • • Widely supported (legacy systems)

TLS 1.3
Recommended

  • • 1 round-trip (1-RTT) - 50% faster!
  • • Only AEAD ciphers (more secure)
  • • Perfect Forward Secrecy required
  • • Encrypted earlier in handshake
  • • 0-RTT resumption possible

Key Concepts

Cipher Suite

A combination of algorithms: key exchange (ECDHE), authentication (RSA/ECDSA), encryption (AES-GCM), and hashing (SHA256).

Perfect Forward Secrecy

Even if the server's private key is compromised, past sessions remain secure because each session uses unique ephemeral keys.

Certificate Authority (CA)

A trusted organization that issues digital certificates. Browsers have a list of trusted root CAs built-in.

AEAD (Authenticated Encryption)

Combines encryption and authentication in one step (e.g., AES-GCM). Required in TLS 1.3 for better security.

Understanding SSL/TLS Handshakes

What you'll learn

  • How TLS 1.2 and TLS 1.3 handshakes differ
  • Certificate chain validation process
  • Key exchange mechanisms (RSA, ECDHE)
  • Cipher suite negotiation
  • Common TLS failure scenarios
  • Perfect Forward Secrecy (PFS)

TLS versions

  • TLS 1.3: Latest version with 1-RTT handshake, mandatory PFS, and removed insecure algorithms.
  • TLS 1.2: Still widely used, 2-RTT handshake with optional PFS.
  • TLS 1.0/1.1: Deprecated, should not be used due to security vulnerabilities.

Key concepts

  • Certificate: Digital document that binds a public key to an identity.
  • Cipher Suite: Set of algorithms for encryption, authentication, and key exchange.
  • PFS: Ensures session keys aren't compromised even if server's private key is.
  • AEAD: Authenticated Encryption with Associated Data (e.g., AES-GCM).

Best practices

  • Use TLS 1.3 where possible, TLS 1.2 as minimum.
  • Disable weak cipher suites (RC4, DES, export ciphers).
  • Enable HSTS to prevent protocol downgrade attacks.
  • Keep certificates up to date and use short validity periods.
  • Use Certificate Transparency (CT) logging.

Overview

Before a browser sends anything over HTTPS, it and the server run a TLS handshake to agree on keys and prove the server identity. This simulator animates that handshake message by message for both TLS 1.2 and TLS 1.3. In TLS 1.2 you see ClientHello, ServerHello, the certificate, the key exchange, ChangeCipherSpec and Finished across two round trips. In TLS 1.3 the client sends its key share in the first message, the server replies with its key share, encrypted extensions and certificate, and the connection is ready after a single round trip. You can open the certificate chain to see how a server certificate is signed by an intermediate CA that chains to a root CA the client already trusts. Failure scenarios show what makes a browser stop with a warning: an expired certificate, a hostname that does not match the certificate, a weak cipher and a certificate from an untrusted CA. Knowing which step fails is what lets you fix a TLS error quickly instead of guessing.

Try this

  1. Play the handshake in TLS 1.2, then switch to TLS 1.3 and compare the number of round trips.
  2. Open the certificate chain view to see the server certificate, the intermediate CA and the root CA.
  3. Pick the "Hostname Mismatch" and "Expired Certificate" scenarios and see where the handshake fails.

Frequently asked questions

What is the difference between TLS 1.2 and TLS 1.3?
TLS 1.3 completes the handshake in one round trip instead of two, encrypts more of the handshake, and removes older, weaker algorithms such as static RSA key exchange.
What is a certificate chain?
The path from the server certificate through one or more intermediate certificates to a root CA that the client trusts. Servers must send the intermediates, or some clients cannot build the chain.
What causes a certificate hostname mismatch error?
The name in the address bar does not appear in the certificate subject alternative names, for example a certificate for example.com used on www.example.com or on a different domain.

Try next

Sponsored
Carbon Ads
$ cd /games
// share