SSL handshake: come funziona step-by-step

Cos'è il TLS handshake

L'handshake TLS è la procedura iniziale di una connessione HTTPS, durante la quale client e server negoziano la versione del protocollo, le cipher suite, autenticano il server e generano le chiavi di sessione che serviranno a cifrare i dati applicativi. Tutto questo avviene prima ancora che il browser invii la prima richiesta HTTP.

Step 1: ClientHello

Il client (browser) invia un messaggio iniziale che contiene:

  • Versioni TLS supportate (es. TLS 1.2, TLS 1.3)
  • Lista delle cipher suite proposte, in ordine di preferenza
  • Random nonce a 32 byte (client_random)
  • Lista di estensioni: SNI (Server Name Indication), ALPN (HTTP/2 negotiation), supported_groups (curve ellittiche), signature_algorithms
  • In TLS 1.3: già i parametri di key share ECDHE

SNI è fondamentale perché permette al server di sapere quale vhost il client sta chiedendo, necessario quando un'IP serve più certificati diversi.

Step 2: ServerHello

Il server risponde con la sua selezione:

  • Versione TLS scelta (la più alta supportata da entrambi)
  • Una sola cipher suite, scelta dalla lista del client
  • Random nonce a 32 byte (server_random)
  • Estensioni accettate
  • In TLS 1.3: anche il key share del server

Step 3: Certificate

Il server invia la propria chain di certificati: il certificato del server seguito dagli intermediate fino (esclusa) alla root CA. Il client verifica:

  • Validità della firma di ciascun cert nella chain
  • Date di validità (non scaduto, non in futuro)
  • Corrispondenza tra hostname richiesto e SAN/CN del certificato
  • Stato di revoca via OCSP (o stapling se presente)
  • Catena fino a una CA root nel proprio truststore
  • Presenza nei Certificate Transparency log

Se una qualsiasi verifica fallisce, l'handshake si interrompe con errore.

Step 4: Key Exchange

Client e server devono accordarsi su una chiave segreta condivisa. In TLS 1.2 il processo varia in base alla cipher suite:

  • ECDHE: server invia parametri ECDH effimeri firmati, client risponde con la sua parte; la chiave master deriva dal Diffie-Hellman
  • RSA (deprecato in TLS 1.3): client genera un pre-master secret, lo cifra con la chiave pubblica RSA del server

In TLS 1.3 il key exchange è integrato in ClientHello/ServerHello: solo ECDHE, tutto compresso in un round trip.

Step 5: Generazione chiavi di sessione

Dal pre-master secret (o dal risultato ECDHE), insieme ai due random nonce, client e server derivano via PRF (HKDF in TLS 1.3) le chiavi simmetriche di sessione:

  • Chiave di cifratura client→server
  • Chiave di cifratura server→client
  • Chiave di autenticazione (MAC) per entrambe le direzioni, se non si usa AEAD
  • IV (Initialization Vector) per ciascuna direzione

Tutto il traffico applicativo successivo userà queste chiavi.

Step 6: Finished

Client e server si scambiano un messaggio Finished cifrato che funge da check di integrità dell'intero handshake. Contiene un'hash di tutti i messaggi scambiati: se un'attaccante avesse manipolato qualcosa nel mezzo (downgrade attack), il Finished non corrisponderebbe e la connessione fallirebbe.

Step 7: Application Data

L'handshake è completo. Il client invia la prima richiesta HTTP (GET, POST) cifrata con le chiavi di sessione. Da questo momento ogni byte applicativo è protetto.

Session Resumption

Aprire una sessione TLS è costoso (round trip, operazioni asimmetriche). Per evitare di rifarlo a ogni connessione, TLS supporta:

  • Session ID: il server memorizza la sessione e la riusa al ritorno
  • Session Ticket: il server cifra la sessione e la consegna al client, che la rimanda al ritorno (stateless server)
  • TLS 1.3 PSK: pre-shared key derivata dalla sessione precedente, abilita 0-RTT

Confronto TLS 1.2 vs TLS 1.3

TLS 1.2 richiede 2 round trip per il primo handshake. TLS 1.3 lo riduce a 1, e con il 0-RTT permette di inviare dati applicativi insieme al primo pacchetto della ripresa di sessione.

Debug pratico

Per ispezionare un'handshake:

openssl s_client -connect tuosito.it:443 -tlsextdebug -msg

Mostra ogni messaggio TLS scambiato con il dettaglio di estensioni e cipher.

Hai bisogno di aiuto?

Se vuoi gestione SSL dal team di G Tech Group, scrivici tramite il modulo di contatto.

Hai trovato utile quest'articolo?