Cos’è una stretta di mano SSL/TLS?
Una stretta di mano SSL/TLS è una negoziazione tra due parti su una rete – come un browser e un server web – per stabilire i dettagli della loro connessione. Determina quale versione di SSL/TLS sarà usata nella sessione, quale suite di cifratura cifrerà la comunicazione, verifica il server (e a volte anche il client), e stabilisce che una connessione sicura è in atto prima di trasferire i dati.
Tutto questo avviene in background, fortunatamente – ogni volta che indirizzate il vostro browser verso un sito sicuro ha luogo una complessa interazione per assicurarsi che i vostri dati siano al sicuro.
Questa è la versione semplice. Potreste notare che una dozzina di descrizioni si attengono più o meno a questo formato, mentre differiscono nei dettagli in una dozzina di modi diversi – a volte in modo confuso. Lanciamo un grafico che mostri un modello generale di come funziona un handshake TLS, che ne dite?
ORDINA ORA
Grafico obbligatorio della stretta di mano SSL/TLS
Tutti i siti relativi a SSL/TLS hanno la loro versione di un diagramma della stretta di mano – ecco il nostro! (Clicca per ingrandire.)
Chiariamo un po’ di confusione, se possiamo
Alcune confusioni su come funzionano le strette di mano SSL/TLS sono dovute al fatto che la stretta di mano è solo il preludio alla sessione sicura vera e propria. Cerchiamo di affrontare alcuni punti comuni:
Crittografia asimmetrica contro simmetrica
Lo stesso handshake usa la crittografia asimmetrica – vengono usate due chiavi separate, una pubblica e una privata. Poiché i sistemi di crittografia asimmetrica hanno un overhead molto più alto, non sono utilizzabili per fornire sicurezza a tempo pieno, nel mondo reale. Così, la chiave pubblica è usata per la crittografia e la chiave privata per la decrittografia solo durante l’handshake, il che permette alle due parti di impostare e scambiare in modo confidenziale una “chiave condivisa” appena creata. La sessione stessa utilizza questa singola chiave condivisa per eseguire la crittografia simmetrica, e questo è ciò che rende una connessione sicura fattibile nella pratica reale (l’overhead è enormemente inferiore). Quindi la risposta completa e corretta a “La crittografia SSL/TLS è asimmetrica o simmetrica?” è “Prima una, poi l’altra.”
Cos’è una “cipher suite”?
Lo stesso handshake ha più fasi, ciascuna gestita secondo regole diverse. I dettagli possono essere trovati qui, ma il nocciolo della questione è che piuttosto che una serie di negoziazioni separate avanti e indietro (su quali chiavi usare, come criptare l’handshake stesso, come autenticare l’handshake e così via) le parti possono concordare di usare una “cipher suite” – una selezione preesistente o un kit di componenti concordati. (Ricordate che la crittografia asimmetrica è costosa in termini di tempo e risorse – usare la suite di cifratura come scorciatoia accelera l’handshake stesso). Le specifiche TLS permettono un certo numero di suite di cifratura, e il client e il server avranno quasi sempre accesso a una che possono entrambi utilizzare.
Basic vs mutually-authenticated handshake
Un altro punto che confonde è che il modello base che abbiamo descritto sopra permette al client di verificare il server, e la stragrande maggioranza delle sessioni protette da TLS richiede solo questo. Tuttavia, alcune suite di cifratura richiederanno al client di inviare anche un certificato e una chiave pubblica per l’autenticazione reciproca di entrambe le parti. Questa autenticazione bidirezionale aggiungerà ovviamente un overhead all’handshake – tuttavia, in alcuni casi (per esempio, dove due banche stanno negoziando una connessione sicura per i trasferimenti di fondi) la suite di cifratura insisterà su di essa, e si ritiene che la sicurezza extra ne valga la pena.
Sessioni diverse avranno parametri di sicurezza diversi
Ogni nuovo handshake crea una nuova sessione, e le impostazioni usate in una possono differire drasticamente da un’altra a seconda della suite di cifratura scelta. Questo è uno dei motivi per cui esistono così tante iterazioni diverse di quel maledetto grafico di handshake, e perché stiamo dando una panoramica abbastanza ampia qui. Sappiate anche che le sessioni possono impostare parametri che potrebbero non essere esattamente quelli che vi aspettate. A seconda della suite di cifratura, alcuni passi possono essere aggiunti (come il requisito di autenticazione bidirezionale) o assenti. In effetti, ci sono suite di cifratura che negoziano una sessione per non usare alcun tipo di cifratura. (Sì, lo sappiamo, una connessione HTTPS sulla porta 443 che decide di inviare dati in chiaro non ha senso neanche per noi. SSL.com raccomanda vivamente di non farlo – basta essere consapevoli che è nel regno del possibile.