Come TLS stabilisce una connessione web sicura e cosa verifica il browser

Quando apri una pagina HTTPS, il browser e il server devono concordare come proteggere la comunicazione prima di scambiare i dati dell'applicazione. Questa negoziazione iniziale è nota come handshake TLS. Non è una password inserita dall'utente: è uno scambio automatico di messaggi e parametri crittografici.

TLS protegge i dati in transito tramite riservatezza e integrità, e consente di autenticare il server. Il risultato pratico è un canale in cui un osservatore di rete non dovrebbe essere in grado di leggere o modificare silenziosamente il traffico. TLS non cifra da solo le informazioni memorizzate su dispositivi o server, né decide se il contenuto del sito è onesto.

SSL è il nome del protocollo predecessore, ormai obsoleto; nelle connessioni web attuali, il protocollo pertinente è TLS. Per abitudine si parla ancora di "certificati SSL", ma il certificato è una credenziale digitale e TLS è il protocollo che stabilisce e protegge la connessione. Certificato e protocollo sono pezzi distinti: averne uno installato non basta a dimostrare che la configurazione TLS è fatta bene.

All'inizio, il client invia un messaggio ClientHello con informazioni sulle opzioni che supporta, come versioni di TLS, algoritmi e dati per lo scambio di chiavi. Il server risponde selezionando parametri compatibili. Non si sceglie una combinazione arbitraria: entrambe le estremità devono concordare sulle opzioni consentite dalle loro implementazioni e configurazioni.

In TLS 1.3, il client può includere nel primo messaggio una parte pubblica dello scambio di chiavi effimero. Il server seleziona i parametri, presenta il suo certificato e invia la sua parte corrispondente; entrambe le estremità derivano indipendentemente segreti condivisi e chiavi di traffico. Con ECDHE —Diffie-Hellman effimero su curve ellittiche— la chiave segreta di sessione non viene trasmessa come un dato che un terzo potrebbe copiare: vengono scambiati valori pubblici che permettono di calcolare il segreto su entrambi i lati.

La crittografia simmetrica protegge il traffico successivo perché è più adatta a elaborare grandi quantità di dati rispetto alle operazioni a chiave pubblica. TLS deriva chiavi di traffico per proteggere i record della connessione; non è consigliabile descrivere il processo come se il browser creasse semplicemente una chiave di sessione e la consegnasse al server. Il design esatto dipende dalla versione negoziata e dai parametri concordati.

TLS 1.3 ha ridotto l'instaurazione ordinaria a un viaggio di andata e ritorno di rete (1-RTT), mentre TLS 1.2 di solito ne richiede due prima di iniziare lo scambio normale di dati protetti. La ripresa di sessione con 0-RTT è un'opzione diversa: può consentire di inviare dati prima di completare un nuovo viaggio di andata e ritorno, ma ha rischi di ripetizione e non è indiscriminatamente appropriata per operazioni che non tollerano duplicati. Meno latenza non significa che tutte le richieste siano sicure per 0-RTT.

Il certificato del server collega un'identità —normalmente un nome di dominio— a una chiave pubblica e contiene una firma verificabile all'interno di una catena di fiducia. Il client verifica che la catena porti a un'autorità radice che riconosce, che il certificato sia nel suo periodo di validità e che il nome richiesto corrisponda ai nomi coperti dal certificato, di solito nel campo SAN (Subject Alternative Name).

La validazione non consiste solo nel guardare se c'è un lucchetto. Il browser esegue controlli automatici e può rifiutare la connessione se il certificato è scaduto, il nome non corrisponde o la catena non può essere validata. Il controllo di revoca dipende anche da meccanismi e politiche del client; non si deve supporre che un'ispezione visiva dell'icona esponga tutti i dettagli di quel processo.

Un certificato valido autentica il controllo di un dominio secondo le regole di emissione applicabili; non certifica che l'attività sia legittima, che il sito non sia fraudolento o che il contenuto sia affidabile. Un sito ingannevole può anche servire HTTPS per il proprio dominio. Il lucchetto indica una connessione protetta con quel server, non un'approvazione delle sue pratiche o affermazioni.

L'autenticazione TLS web abituale verifica principalmente il server. L'autenticazione reciproca, o mTLS, è una configurazione aggiuntiva in cui il client presenta anche un certificato per autenticarsi. Non deve essere confusa con il funzionamento normale di HTTPS, in cui l'utente non consegna necessariamente un certificato personale.

Durante una connessione TLS, la crittografia rende difficile per i terzi sul percorso leggere il contenuto protetto e l'integrità permette di rilevare modifiche ai dati in transito. L'autenticazione del server aiuta a ridurre il rischio che il client stabilisca la connessione con un impostore che non controlla l'identità certificata. Queste protezioni si applicano al percorso della connessione, non a tutti i punti attraverso cui passano i dati.

TLS non nasconde necessariamente tutte le informazioni di contesto. Ad esempio, l'indirizzo IP del server e altri metadati di rete possono rimanere visibili; inoltre, il nome del server può essere esposto durante l'instaurazione in configurazioni che non utilizzano meccanismi di protezione del nome. Non impedisce nemmeno che il sito stesso, un'estensione malevola o un dispositivo compromesso accedano ai dati una volta che vengono decifrati all'estremità.

Una connessione HTTPS non garantisce nemmeno la crittografia end-to-end tra due persone. Il server termina la connessione TLS e può leggere i dati che riceve per fornire il servizio. Il trasporto cifrato non equivale a contenuto inaccessibile per il provider: per quest'ultimo obiettivo serve un design di crittografia end-to-end in cui il servizio non controlli le chiavi di decifratura.

openssl s_client consente di aprire una connessione TLS a un server e osservare informazioni sulla negoziazione, come il protocollo selezionato, la suite di crittografia e i certificati presentati. Per un dominio di prova, un controllo di base è:

openssl s_client -connect example.com:443 -servername example.com -showcerts

L'opzione -servername invia il nome tramite SNI, necessario quando più siti condividono lo stesso indirizzo IP. Senza SNI, il server potrebbe rispondere con un certificato predefinito che non corrisponde al dominio da esaminare. Sostituisci example.com con il nome che amministri o hai il permesso di verificare.

L'output non è un verdetto di sicurezza completo. Esamina il protocollo e la crittografia negoziati, la catena presentata dal server e il codice di verifica. La verifica può dipendere dall'archivio di fiducia dell'installazione locale di OpenSSL; un risultato corretto su una macchina non dimostra come si comporteranno tutti i browser o dispositivi.

Per richiedere una connessione specifica con TLS 1.3, se la versione locale di OpenSSL lo consente, aggiungi -tls1_3; per TLS 1.2, usa -tls1_2. Queste opzioni servono a verificare la compatibilità con una versione, ma una connessione fallita può essere dovuta alla politica del server, alla rete o all'implementazione locale. Non modificare la configurazione di produzione basandoti su un singolo test.

Nel browser, il pannello delle informazioni del sito consente di esaminare la connessione e i dati del certificato, anche se il percorso esatto dipende dal browser e dalla sua versione. Per una revisione pratica, verifica almeno il nome coperto, l'emittente, la validità e se la pagina si è caricata tramite HTTPS. Gli strumenti di sviluppo possono mostrare anche informazioni di sicurezza e richieste, ma non sostituiscono una revisione della configurazione del server.

I fallimenti di handshake sono sintomi, non diagnosi: possono apparire quando client e server non condividono una versione o una suite di crittografia, quando il certificato non è valido per il nome richiesto, quando manca un certificato intermedio o quando ci sono problemi di SNI. Un orologio errato può anche far apparire un certificato come non ancora valido o già scaduto. Identificare la causa evita "riparazioni" che rimuovono protezioni.

In un servizio web, l'amministratore dovrebbe mantenere protocolli e algoritmi compatibili con i client di cui ha realmente bisogno, e rimuovere opzioni obsolete secondo la propria politica di sicurezza. TLS 1.3 riduce le opzioni crittografiche ereditate; TLS 1.2 può ancora essere necessario per la compatibilità, ma la sua sicurezza dipende dalla selezione concreta dei parametri. Non basta attivare una versione senza rivedere l'intero set di configurazione.

Un elenco utile per una prima revisione è:

• Confermare che il dominio richiesto appaia nel certificato e che questo sia valido.
• Verificare se viene inviata la catena di certificati necessaria e se il server usa il certificato corretto tramite SNI.
• Comprendere quale versione TLS e quale suite di crittografia vengono negoziate con client rappresentativi.
• Investigare i log del server e l'output di OpenSSL prima di modificare le politiche.
• Evitare di disattivare la validazione del certificato o di riattivare protocolli obsoleti come soluzione rapida.

Non disattivare la validazione per far scomparire un avviso. Se il problema è una catena incompleta, un nome errato o un certificato scaduto, ignorare il controllo trasforma un errore visibile in una connessione meno affidabile. La decisione pratica è correggere la causa sul server o sul client, non accettare alla cieca un'identità che non ha potuto essere verificata.