Cosa succede in un handshake TLS? | Handshake SSL

Cos'è un handshake TLS?

TLS è un protocollo di crittografia progettato per proteggere le comunicazioni Internet. Un handshake TLS è il processo che avvia una sessione di comunicazione che utilizza la crittografia TLS. Durante un handshake TLS, le due parti comunicanti si scambiano messaggi per riconoscersi, verificarsi a vicenda, stabilire gli algoritmi crittografici che utilizzeranno e concordare le chiavi di sessione. Gli handshake TLS sono una parte fondamentale del funzionamento di HTTPS.

Handshake TLS e SSL

SSL, o Secure Sockets Layer, era il protocollo di sicurezza originario sviluppato per HTTP. Qualche tempo fa, SSL è stato sostituito da TLS, o Transport Layer Security. Gli handshake SSL sono ora chiamati handshake TLS, sebbene il nome "SSL" sia ancora ampiamente utilizzato.

Quando si verifica un handshake TLS?

Un handshake TLS si verifica ogni volta che un utente accede a un sito Web tramite HTTPS e il browser inizia prima a interrogare il server di origine del sito Web. Un handshake TLS si verifica anche ogni volta che qualsiasi altra comunicazione utilizza HTTPS, incluse le chiamate API e le query DNS su HTTPS.

Gli handshake TLS si verificano dopo che una connessione TCP è stata aperta tramite un handshake TCP.

Cosa succede durante un handshake TLS?

Nel corso di un handshake TLS, il client e il server operano insieme come segue:

• Specificano la versione di TLS (TLS 1.0, 1.2, 1.3, ecc.) che utilizzeranno
• Decidono quali suite di crittografia (vedi sotto) utilizzeranno
• Autenticano l'identità del server tramite la chiave pubblica del server e la firma digitale dell'autorità di certificazione SSL
• Generano chiavi di sessione per utilizzare la crittografia simmetrica dopo il completamento dell'handshake

Quali sono le fasi di un handshake TLS?

Gli handshake TLS sono una serie di datagrammi, o messaggi, scambiati da un client e un server. Un handshake TLS prevede più passaggi, poiché il client e il server si scambiano le informazioni necessarie per completare l'handshake e rendere possibile un'ulteriore conversazione.

I passaggi esatti all'interno di un handshake TLS variano a seconda del tipo di algoritmo di scambio di chiavi utilizzato e delle suite di crittografia supportate da entrambe le parti. L'algoritmo di scambio di chiavi RSA, oggi considerato non sicuro, veniva utilizzato nelle versioni di TLS precedenti alla 1.3. Ecco come funziona:

1. Il messaggio 'client hello': il client inizia l'handshake inviando un messaggio "hello" al server. Il messaggio includerà la versione TLS supportata dal client, le suite di crittografia supportate e una stringa di byte casuali nota come "casuale client".
2. Il messaggio 'server hello': in risposta al messaggio di saluto del client, il server invia un messaggio contenente il certificato SSL del server, la suite di cifratura scelta dal server e la stringa "casuale server", un'altra stringa casuale di byte generata dal server.
3. Autenticazione: il client verifica il certificato SSL del server con l'autorità di certificazione che lo ha emesso. Ciò conferma che il server è chi dice di essere e che il client sta interagendo con l'effettivo proprietario del dominio.
4. Il segreto premaster: il client invia un'altra stringa casuale di byte, il "segreto premaster". Il segreto premaster è crittografato con la chiave pubblica e può essere decrittografato solo con la chiave privata dal server. (Il client ottiene la chiave pubblica dal certificato SSL del server.)
5. Chiave privata utilizzata: il server decritta il segreto premaster.
6. Chiavi di sessione create: sia il client che il server generano chiavi di sessione dalla stringa casuale client, dalla stringa casuale server e dal segreto premaster. Dovrebbero arrivare agli stessi risultati.
7. Il client è pronto: il client invia un messaggio "terminato" che viene crittografato con una chiave di sessione.
8. Il server è pronto: il server invia un messaggio "terminato" crittografato con una chiave di sessione.
9. Crittografia simmetrica sicura ottenuta: l'handshake è stato completato e la comunicazione continua utilizzando le chiavi di sessione.

Tutti gli handshake TLS utilizzano la crittografia asimmetrica (la chiave pubblica e quella privata), ma non tutti utilizzeranno la chiave privata nel processo di generazione delle chiavi di sessione. Ad esempio, un handshake Diffie-Hellman effimero procede come segue:

1. Client hello: il client invia un messaggio di benvenuto client con la versione del protocollo, la stringa casuale client e un elenco di suite di crittografia.
2. Server hello: il server risponde con il suo certificato SSL, la suite di cifratura selezionata e il server casuale. Contrariamente all'handshake RSA descritto sopra, in questo messaggio il server include anche quanto segue (passo 3):
3. Firma digitale del server: il server calcola una firma digitale di tutti i messaggi fino a questo punto.
4. Firma digitale confermata: il client verifica la firma digitale del server, confermando l'identità del server.
5. Parametro DH client: il client invia il suo parametro DH al server.
6. Il client e il server calcolano il segreto premaster: invece del client che genera il segreto del premaster e lo invia al server, come in un handshake RSA, il client e il server utilizzano i parametri DH che si sono scambiati per calcolare separatamente un segreto del premaster corrispondente.
7. Chiavi di sessione create: ora, il client e il server calcolano le chiavi di sessione dal segreto premaster, dalla stringa casuale client e dalla stringa casuale server, proprio come in un handshake RSA
8. Il client è pronto: uguale all'handshake RSA.
9. Il server è pronto
10. Crittografia simmetrica sicura ottenuta

*Parametro DH: DH sta per Diffie-Hellman. L'algoritmo Diffie-Hellman utilizza calcoli esponenziali per arrivare allo stesso segreto premaster. Il server e il client forniscono ciascuno un parametro per il calcolo e, se combinati, producono un calcolo diverso su ciascun lato, con risultati uguali.

Per saperne di più sul contrasto tra gli handshake Diffie-Hellman effimeri e altri tipi di handshake e su come ottengono la segretezza diretta, consulta Cos'è Keyless SSL?

Cosa c'è di diverso in un handshake in TLS 1.3?

TLS 1.3 non supporta RSA, né altre suite di crittografia e parametri vulnerabili agli attacchi. Inoltre abbrevia l'handshake TLS, rendendo l'handshake TLS 1.3 più rapido e sicuro.

I passaggi fondamentali di un handshake TLS 1.3 sono i seguenti:

• Client hello: il client invia un messaggio di benvenuto client con la versione del protocollo, la stringa casuale client e un elenco di suite di crittografia. Poiché il supporto delle suite di crittografia non sicure è stato eliminato da TLS 1.3, il numero di suite di crittografia possibili è notevolmente inferiore. Il client hello include anche i parametri che verranno utilizzati per calcolare il segreto premaster. In sostanza, il client presume di conoscere il metodo di scambio di chiavi preferito dal server (e probabilmente lo conosce, visto il numero ridotto di suite di crittografia). Questo riduce la lunghezza complessiva dell'handshake, che rappresenta una delle differenze più importanti tra l'handshake di TLS 1.3 e quello di TLS 1.0, 1.1 e 1.2.
• Il server genera il segreto master: a questo punto, il server ha ricevuto la stringa casuale client e i parametri e le suite di crittografia del client. Possiede già la stringa casuale server, poiché è in grado di generarla in autonomia. Pertanto, il server può creare il segreto master.
• Server hello e "Finished": il server hello include il certificato del server, la firma digitale, la stringa casuale server e la suite di crittografia scelta. Poiché possiede già il segreto master, invia anche un messaggio "Finished".
• Fasi finali e client "Finished": il client verifica la firma e il certificato, genera il segreto master e invia il messaggio "Finished".
• Crittografia simmetrica sicura ottenuta

Modalità 0-RTT per la ripresa della sessione

TLS 1.3 supporta inoltre una versione ancora più rapida dell'handshake TLS che non richiede alcuna comunicazione da e verso client e server. Se il client e il server si sono già connessi tra loro in precedenza (ad esempio, se l'utente ha già visitato il sito Web), entrambi possono ricavare un altro segreto condiviso dalla prima sessione, chiamato "segreto principale di ripresa". Durante questa prima sessione, il server invia al client un documento chiamato ticket di sessione. Il client può utilizzare questo segreto condiviso per inviare dati crittografati al server nel primo messaggio della sessione successiva, insieme al ticket di sessione. E l'handshake TLS riprende tra il client e il server.

Cos'è una suite di cifratura?

Una suite di crittografia è un insieme di algoritmi da utilizzare per stabilire una connessione di comunicazione sicura. Esistono numerose suite di crittografia ampiamente utilizzate e una parte essenziale dell'handshake TLS è concordare quale suite di crittografia verrà utilizzata per tale handshake.

Per saperne di più su TLS/SSL, consulta Come funziona SSL?