È complicato. Quello che presenterò qui sotto è una versione radicalmente semplificata dei dettagli. (Poiché i dettagli reali sono contenuti in centinaia di pagine di RFC.) Esistono essenzialmente 3 passaggi crittografici per una connessione TLS:
- Autenticazione
- Scambio di chiavi
- Comunicazioni crittografate per l'applicazione
Autenticazione di solito implica che il server si identifichi con un cliente presentando un certificato. Questo certificato convalida che stai parlando con un server legittimo: ha il nome host del server incorporato, la data di scadenza ed è firmato da un'autorità di certificazione legittima. Inoltre, contiene una chiave pubblica: il possesso della chiave privata corrispondente è la prova che il certificato "appartiene a te". Molto spesso, si tratta di una coppia di chiavi RSA, sebbene sia anche possibile utilizzare DSA o ECDSA o anche un altro sistema a chiave pubblica (ma su Internet aperta, è quasi sempre 2048 o 4096 bit RSA). Questo è ciò che dà ai client avvisi sui certificati (nome host errato, CA errata, scaduto, ecc.). Questa è la parte per la quale si genera una chiave, e deve corrispondere alla specifica della cifratura.
In secondo luogo è lo scambio di chiavi . Se non stai cercando la perfetta segretezza in avanti, questo può essere semplice come il client che crittografa un pezzo di dati utilizzando la chiave pubblica del server dal suo certificato. Il server quindi decrittografa questo, ed entrambi i lati lo usano per generare la chiave di connessione. D'altra parte, se si desidera un perfetto segreto di inoltro (cioè, rubare la chiave RSA non è sufficiente per decodificare ogni connessione precedente) si usa una variante dello scambio di chiavi Diffie-Hellman: fondamentalmente una tecnica per arrivare a un segreto condiviso in modo sicuro . Senza un uomo attivo nel mezzo, una terza parte non può ottenere la chiave condivisa e la fase di autenticazione ha assicurato che non ci sia un uomo attivo nel mezzo. Questo passo DH può essere Diffie Hellman su un gruppo intero (DHE) o su una curva ellittica (ECDHE). Sia che utilizzi RSA, DHE o ECDHE per lo scambio di chiavi, ora hai una chiave segreta condivisa tra client e server che nessun altro dovrebbe avere.
Infine, ottieni la comunicazione crittografata effettiva. Crypo asimmetrico come RSA e DH sono troppo lenti per comunicazioni continue di grandi volumi, quindi per questo utilizziamo sistemi crittografici simmetrici (come AES). Questo utilizza la chiave condivisa scambiata nel passaggio precedente per comunicare. Ogni pacchetto è anch'esso firmato, o con un HMAC (quindi potresti vedere SHA256 come parte della tua specifica di cifratura) o un tag come GMAC da GCM (per AES-GCM). Inoltre, AES (e altri codici) possono essere eseguiti in diverse modalità: GCM, CTR, CBC, ecc.
Alcuni esempi:
ECDHE-RSA-AES128-SHA256 significa utilizzare Elliptic Curve Diffie-Hellman per lo scambio di chiavi, RSA per l'autenticazione e AES128 con la firma SHA256 dei messaggi. (La modalità CBC viene utilizzata, sebbene non esplicitamente inclusa.)
ECDHE-ECDSA-AES128-GCM-SHA256 è Elliptic Curve Diffie-Hellman per lo scambio di chiavi, Elliptic Curve DSA per l'autenticazione, AES 128 per crypto (GCM per la firma di pacchetti, SHA256 per la firma di altri dati.)
AECDH-RC4-SHA è la curva ellittica anonima Diffie Hellman per lo scambio delle chiavi, nessuna autenticazione (quindi anonima), RC4 per la crittografia e SHA-1 per l'autenticazione dei pacchetti. (Si prega di non usare questo, tutto è rotto dagli standard moderni, è un esempio.)