Come funziona davvero TLS per proteggere una connessione HTTPS?

Le persone dicono "HTTPS significa che è crittografato" e si fermano lì, ma la parte interessante è come due sconosciuti su internet concordano su un segreto condiviso senza mai incontrarsi, su una rete piena di persone che potrebbero stare ascoltando. È quello che fa TLS, e i meccanismi meritano di essere compresi se hai a che fare con networking, web dev, o security.

L'handshake, passo dopo passo

Quando il tuo browser si connette a https://example.com, ecco all'incirca cosa succede (TLS 1.3, che la maggior parte dei siti usa ora):

1. ClientHello — il browser invia i cipher suite supportati, un nonce casuale, e un tentativo di key share (usando qualcosa come X25519 o secp256r1) per lo scambio di chiavi.
2. ServerHello — il server sceglie un cipher suite, invia il suo key share, e ritorna il suo certificato più una firma che prova che possiede la chiave privata corrispondente a quel certificato.
3. Derivazione della chiave — entrambi i lati ora calcolano indipendentemente lo stesso segreto condiviso usando la matematica stile Diffie-Hellman sui loro key share. Nessuno dei due trasmette mai il segreto stesso; viene derivato, non inviato.
4. Finished messages — entrambi i lati confermano che l'handshake non è stato manomesso inviando un MAC sull'intera trascrizione dell'handshake.

Dopo quello, tutto è crittografato con chiavi simmetriche derivate dal segreto condiviso, di solito AES-128-GCM o ChaCha20-Poly1305. TLS 1.3 ha ridotto l'handshake a due round-trip di TLS 1.2 a effettivamente un round trip, il che è un vero guadagno di latenza su larga scala.

Perché il certificato conta più della crittografia

La crittografia senza verifica dell'identità è inutile — chiunque può configurare un canale crittografato, incluso un attaccante che esegue un man-in-the-middle. Il certificato è quello che lega una chiave pubblica a un nome di dominio, ed è firmato da una Certificate Authority (CA) come Let's Encrypt o DigiCine.

Il tuo browser si fida di un elenco fisso di CA radice incorporato nel trust store del sistema operativo o del browser. Il certificato del server sale in catena attraverso certificati intermedi a una di quelle radici. Se la catena non si valida, o il dominio nel certificato non corrisponde a quello che hai richiesto, ricevi la pagina di avviso rosso. Quel modello di chain-of-trust è il confine di sicurezza effettivo — ruba la chiave di firma di una CA e puoi coniare certificati validi per qualsiasi dominio, ecco perché i compromessi della CA sono trattati come incidenti importanti.

Cosa fanno la crittografia simmetrica e asimmetrica qui

La crittografia asimmetrica (RSA o curva ellittica) è lenta e costosa, quindi TLS la usa solo durante l'handshake — per autenticare il server e per aiutare a stabilire il segreto condiviso. Una volta fatto, tutti i dati effettivi (HTML, JSON, qualunque cosa) sono crittografati con cifrari simmetrici veloci. Questo approccio ibrido è lo stesso pattern che vedrai in SSH, PGP, e nella maggior parte dei sistemi crypto del mondo reale: asincronica per identità e scambio di chiavi, simmetrica per dati di massa.

La forward secrecy è un dettaglio correlato che vale la pena conoscere: poiché il segreto condiviso proviene da key share Diffie-Hellman effimeri generati freschi per sessione, anche se qualcuno registra il tuo traffico e successivamente ruba la chiave privata del server, non può ancora decriptare le sessioni vecchie. Quella proprietà non esisteva nello scambio di chiavi solo RSA più vecchio.

Verificarlo tu stesso

Non hai bisogno di fidarti ciecamente di un'icona di lucchetto verde. Esegui:

openssl s_client -connect example.com:443 -tls1_3

Quello ti mostra il cipher suite negoziato, la catena di certificati, e se l'handshake è effettivamente completato. Per uno sguardo più veloce a quello che vede un browser, curl -v https://example.com stampa la versione TLS e i dettagli del certificato prima della risposta HTTP.

Puoi anche decriptare il tuo traffico in Wireshark se esporti la variabile d'ambiente SSLKEYLOGFILE prima di lanciare Chrome o Firefox — genuinamente utile per il debug dei problemi TLS invece di indovinare.

Dove questo effettivamente fallisce in pratica

La maggior parte dei fallimenti HTTPS nel mondo reale non sono vulnerabilità crittografiche, sono operazionali: certificati scaduti, catene intermedie mal configurate, client bloccati su versioni TLS vecchie, o contenuti misti (una pagina HTTPS che carica una risorsa HTTP). I veri attacchi a livello di protocollo contro TLS 1.3 moderno sono rari perché la specifica ha chiuso la maggior parte dei padding oracle e dei downgrade trick che hanno afflitto SSL 3.0 e il primo TLS. I punti deboli ora sono di solito gli endpoint — una CA compromessa, una chiave privata rubata, o un utente che clicca oltre un avviso di certificato che non avrebbe dovuto.

Se vuoi approfondire, i segmenti di networking e crittografia di Korra Studio coprono la matematica Diffie-Hellman sottostante e l'analisi del protocollo a livello di pacchetto in più profondità.