Che cos'è una stretta di mano TLS?

Un handshake di sicurezza del livello di trasporto (TLS) stabilisce una comunicazione crittografata e autenticata tra un client (ad esempio un browser Web) e un serverLa stretta di mano comporta lo scambio di messaggi, l'accordo sulla crittografia Algoritmi, verificando il serverl'identità di (e facoltativamente quella del cliente) e la generazione condivisa chiavi segrete per crittografare i successivi trasferimenti di datiÈ il fondamento per uno scambio sicuro di dati, garantendo che le informazioni trasmesse rimangano riservate e a prova di manomissione.

Cosa significa TLS Handshake?

Un handshake TLS è una serie di passaggi che avvia una connessione sicura convalidando le parti coinvolte, selezionando parametri di sicurezza compatibili e creando chiavi di crittografia condivise. L'handshake determina come i dati saranno crittografati, verifica il servercertificato digitale e stabilisce il canale sicuro necessario per proteggere l'integrità dei dati e riservatezza. È una parte essenziale di TLS, un protocollo progettato per fornire privacy e data security sulle reti.

Quali sono i componenti di un handshake TLS?

Di seguito sono riportati i componenti principali che rendono possibile un handshake TLS.

Cliente e Server

L'handshake coinvolge due entità principali: il client, che avvia la connessione (ad esempio, un browser web o altra applicazione), e il server, che ospita la risorsa o il servizio a cui il client desidera accedere. Il client avvia l'handshake proponendo vari parametri per crittografia e dell' autenticazione, e il server risponde con le opzioni scelte in base alle configurazioni supportate.

Suite di cifratura

Una suite di cifratura è una raccolta di algoritmi crittografici utilizzati durante l'handshake e i successivi trasferimenti di dati. Include l'algoritmo di scambio di chiavi, il cifrario di crittografia di massa, l'algoritmo del codice di autenticazione del messaggio e talvolta l'algoritmo di firma digitale. Il client suggerisce un elenco di suite di cifratura supportate e il server ne seleziona uno che riconosce e ritiene accettabile.

Certificati

I certificati sono documenti digitali utilizzati per confermare l'identità di una parte comunicante. Nella maggior parte delle connessioni TLS, il server presenta un certificato X.509, rilasciato da un ente attendibile autorità di certificazione (CA). Questo certificato vincola il server'S dominio nome a una chiave pubblica. Il client verifica la catena di certificati per assicurarsi che non sia stata manomessa e che sia stata emessa da una CA legittima.

Chiavi pubbliche e private

Le chiavi pubbliche e private sono parte integrante di TLS. server detiene una chiave privata che corrisponde alla chiave pubblica elencata nel suo certificato. Durante l'handshake, queste chiavi partecipano a operazioni crittografiche asimmetriche. I client utilizzano la chiave pubblica nel server certificato per crittografare un pezzo di dati (come il segreto pre-master), e solo il serverLa chiave privata può decifrare esso.

Chiavi di sessione

Una volta che il cliente e server concordano su un insieme di parametri crittografici, generano simmetriche chiavi di sessione. Queste chiavi crittografano e decrittografano i messaggi durante la fase di trasferimento dati, offrendo vantaggi sia in termini di riservatezza che di prestazioni. Gli algoritmi di crittografia simmetrici sono solitamente molto più rapidi di quelli asimmetrici, motivo per cui l'handshake utilizza metodi asimmetrici per l'autenticazione e lo scambio di chiavi, quindi ricorre a metodi simmetrici per la crittografia di dati in blocco.

Come funziona l'handshake TLS?

L'handshake TLS si svolge in genere in diversi passaggi che garantiscono un canale sicuro e autenticato. Ogni fase ha uno scopo definito e consiste in scambi di messaggi che finalizzano i parametri di crittografia e verificano l'autenticità del server e possibilmente il cliente.

Cliente Ciao

Il client inizia l'handshake inviando un messaggio ClientHello al serverQuesto messaggio contiene le seguenti informazioni:

• Elenco delle suite di cifratura e delle versioni TLS supportate.
• Un valore casuale (casuale client) utilizzato in seguito nella generazione della chiave.
• Supporto compressione metodi (sebbene la compressione sia ampiamente deprecata nelle recenti versioni di TLS).

ServerCiao

server risponde con un ServerMessaggio di benvenuto. Questa risposta include:

• Versione TLS selezionata.
• La suite cifrante scelta dalla proposta del cliente.
• Un altro valore casuale (server casuale).

Scambio di certificati e chiavi

server invia il suo certificato, che contiene il serverla chiave pubblica insieme alla catena di certificati. Dopo di che, il server può inviare parametri di scambio di chiavi aggiuntivi se la suite di cifratura scelta lo richiede (ad esempio, in Diffie-Hellman o cifrari Diffie-Hellman a curva ellittica).

Il cliente verifica il servercertificato, assicurandosi che sia valido, non scaduto e firmato da una CA attendibile.

Verifica del cliente e segreto pre-master

Dopo che il cliente verifica il servercertificato, genera un segreto pre-master e lo crittografa utilizzando il serverchiave pubblica. Questo segreto pre-master criptato viene quindi inviato al server.

server utilizza la sua chiave privata per decifrare il segreto pre-master, ed entrambe le parti ricavano le chiavi di sessione dal segreto pre-master, il client casuale e il server casuale.

Finalizzazione dell'handshake

Sia il cliente che server inviare messaggi "Finished" l'uno all'altro, che vengono crittografati con le chiavi di sessione appena derivate. Questi messaggi verificano che le chiavi concordate funzionino correttamente e che non si sia verificata alcuna manomissione.

Una volta che questi messaggi sono stati scambiati e verificati correttamente, l'handshake è completato e le comunicazioni successive vengono crittografate utilizzando le chiavi di sessione.

Quando si verifica un handshake TLS?

Un handshake TLS si verifica ogni volta che un client avvia una nuova connessione sicura a un server su TLS. Gli scenari comuni includono:

• Accesso a un sito Web tramite HTTPS (HTTP tramite TLS).
• Avvio email sicura comunicazioni (come SMTPS, IMAPS o POP3S).
• Connessione ad applicazioni sicure che si basano su TLS per la crittografia (ad esempio, Tunnel VPN o sicuro filetto trasferimenti).

L'handshake si ripete se viene stabilita una nuova sessione o se viene attivata una rinegoziazione TLS per aggiornare le chiavi crittografiche per connessioni di lunga durata.

Esempio di handshake TLS

Di seguito è riportata una procedura dettagliata di come avviene un tipico handshake HTTPS (HTTP su TLS) tra un client e un server.

Fase 1: richiesta del cliente alla pagina protetta

Il browser Web di un utente avvia una connessione sicura inviando un messaggio ClientHello all' server su "example.com". Il messaggio ClientHello fa parte del protocollo TLS Handshake e contiene diverse informazioni importanti:

• Versione/i del protocollo supportata/eIl client propone una o più versioni di TLS (ad esempio, TLS 1.2, TLS 1.3) che è in grado di utilizzare.
• Cliente casuale. un 32-byte valore casuale generato dal client, utilizzato in seguito nella derivazione della chiave.
• ID sessione o ticket di sessioneSe il client si è connesso di recente allo stesso server e possiede un ticket di sessione o un ID di sessione valido, può offrirlo per richiedere la ripresa della sessione, il che può saltare o abbreviare alcuni passaggi dell'handshake.
• Suite di cifratura. Queste suite sono un elenco di algoritmi crittografici supportati dal client. Ogni suite di cifratura specifica un meccanismo di scambio di chiavi (ad esempio, RSA, ECDHE), un algoritmo di crittografia (ad esempio, AES) e un algoritmo di codice di autenticazione del messaggio o tag di autenticazione (ad esempio, SHA256).
• EstensioniLe implementazioni TLS moderne includono varie estensioni come server indicazione del nome (SNI), che indica il hostname il client sta tentando di raggiungere. Ulteriori estensioni potrebbero indicare curve ellittiche supportate, algoritmi di firma e altri parametri che migliorano la sicurezza o le prestazioni.

Dopo aver ricevuto questo ClientHello, il server esamina le suite di cifratura proposte e le versioni TLS per determinare se ne supporta qualcuna. L'handshake TLS continua solo se server trova almeno un set di parametri compatibile.

Passo 2: Server Risponde

Dopo aver elaborato ClientHello, il server risponde con un ServerMessaggio di benvenuto. Sono inclusi diversi elementi chiave:

• Versione del protocollo scelta. server seleziona una versione di TLS (ad esempio, TLS 1.2) che sia il client che server supporto.
• Server conUn altro valore casuale di 32 byte generato dal server, utilizzato con il client random per derivare chiavi condivise.
• Selezione della suite di cifraturaDall'elenco del cliente, il server sceglie una singola suite di cifratura che supporta. Ad esempio, potrebbe scegliere uno scambio di chiavi ECDHE_RSA, una crittografia AES_128_GCM e SHA256 per l'autenticazione dei messaggi.
• ID sessione o nuovo ticket di sessione. Se il server supporta la ripresa della sessione, può accettare l'ID di sessione proposto dal client o fornirne uno nuovo.
• Estensioni. server include risposte di estensione pertinenti, indicando eventuali parametri o vincoli specifici.

Dopo l' ServerCiao, l' server in genere invia messaggi di handshake aggiuntivi:

• Certificato. server trasmette la sua catena di certificati, che include il suo certificato di entità finale (l'effettivo server certificato) e tutti i certificati intermedi necessari per collegarlo a un'autorità di certificazione radice (CA).
• Server scambio di chiavi. A seconda della suite di cifratura scelta, il server fornisce parametri di scambio delle chiavi (ad esempio, la chiave pubblica effimera Diffie-Hellman) che il client utilizzerà per generare un segreto condiviso.
• Richiesta certificato (facoltativo). Se il server richiede l'autenticazione del client, richiede un certificato client in questa fase. Ciò è meno comune nella tipica navigazione web ma più frequente in ambienti che necessitano di TLS reciproco.

Fase 3: convalida del certificato

Il cliente esamina il servercertificato per garantire che la connessione sia realmente con l'host previsto e non con un impostore:

• Verifica della catena di certificatiIl cliente verifica che il serverIl certificato di è rilasciato e firmato da una CA attendibile. Il browser o sistema operativo mantiene un archivio di certificati radice attendibili. Il browser controlla anche i certificati intermedi per formare una catena di fiducia valida fino a una CA radice riconosciuta.
• Scadenza e validitàIl client controlla le date "Non prima" e "Non dopo" del certificato per confermare che il certificato sia attualmente valido.
• Corrispondenza del nome di dominioIl client conferma che il nome di dominio elencato nel certificato (solitamente presente nel campo Subject Alternative Name) corrisponde a "example.com" o a qualsiasi altro dominio richiesto.
• Controllo di revocaIl client può utilizzare l'elenco di revoche dei certificati (CRL) o il protocollo di stato dei certificati online (OCSP) per verificare se il certificato o un certificato intermedio è stato revocato.

Se una qualsiasi parte del processo di convalida fallisce, ad esempio a causa di una firma non valida, di un certificato scaduto o di un nome di dominio non corrispondente, il client in genere interrompe la connessione o visualizza un avviso per l'utente.

Fase 4: Scambio di chiavi e generazione di chiavi di sessione

Una volta che il cliente ha convalidato il servercertificato (e facoltativamente inviato il proprio certificato se richiesto), il client procede con lo scambio di chiavi:

• Scambio di chiavi clientSe viene utilizzato uno scambio di chiavi RSA, il client genera un segreto pre-master e lo crittografa con il serverla chiave pubblica (ottenuta da server certificato). Se viene utilizzata una suite di cifratura ECDHE o DHE, il client fornisce anche la propria chiave pubblica effimera per i calcoli Diffie-Hellman.
• Decrittazione o calcolo della chiave condivisa. server decifra il segreto pre-master con la sua chiave privata o, nel caso di Diffie-Hellman/ECDHE, combina la chiave del client e serverle chiavi pubbliche per calcolare un segreto condiviso.
• Derivazione segreta del maestroUtilizzando il segreto pre-master (o segreto condiviso DH), il client e server entrambi derivano un segreto master. Questa derivazione coinvolge anche il client casuale e server casuale. Le funzioni pseudo-casuali (come quelle in TLS 1.2 o il "Handshake Secret" in TLS 1.3) vengono utilizzate per garantire una forte casualità crittografica.
• Creazione della chiave di sessioneDal segreto principale, il cliente e server generare chiavi simmetriche separate per crittografare i dati in uscita, decrittografare i dati in entrata e verificare l'integrità dei messaggi. Queste chiavi di sessione sono in genere negoziate per essere effimere (specialmente nei cifrari basati su ECDHE), il che fornisce segreto in avanti.

Fase 5: Trasferimento sicuro dei dati

Dopo che entrambe le parti hanno ottenuto le chiavi di sessione, il client e server exchange Finito messaggi:

• Messaggi finiti. Ogni lato calcola un hash crittografico di tutti i messaggi di handshake inviati finora (la trascrizione dell'handshake) e lo crittografa con le chiavi di sessione appena stabilite. Questi messaggi "Finished" verificano che entrambe le parti condividano lo stesso stato di handshake e che non si sia verificata alcuna manomissione.
• Conferma della stretta di manoIl cliente e server confermare la ricezione del messaggio Finished dell'altro. Se gli hash corrispondono, indica che l'handshake è stato completato con successo e in modo sicuro.
• Dati dell'applicazione crittografati. Dati successivi, come HTML file, immagini o qualsiasi altro contenuto del livello applicativo, viene crittografato con la chiave simmetrica concordata. La crittografia garantisce la riservatezza, mentre la crittografia hash o MAC (a seconda della suite crittografica) garantisce l'integrità.
• Persistenza della connessione e ripresa della sessione. Se una delle due parti supporta la ripresa della sessione TLS, può riutilizzare il master secret negoziato per una connessione futura. Ciò riduce il sovraccarico di dover eseguire nuovamente un handshake completo.

Una volta completata la fase di handshake, il browser e server comunicare tramite un canale sicuro. I browser solitamente visualizzano un'icona a forma di lucchetto o un indicatore simile nella barra degli indirizzi per mostrare che la connessione è crittografata e autenticata tramite TLS.

Perché gli handshake TLS sono importanti?

L'handshake TLS fornisce un metodo per stabilire comunicazioni sicure in reti che potrebbero essere soggette a intercettazioni o manomissioni.

 Da una stretta di mano riuscita derivano diversi vantaggi:

• Autenticazione. Il cliente è assicurato della serverl'identità di , prevenendo attacchi man-in-the-middle.
• riservatezzaTutto il traffico che segue l'handshake viene crittografato, garantendo che le parti non autorizzate non siano in grado di leggere i dati.
• Integrità dei datiL'autenticazione dei messaggi garantisce che i dati trasmessi non siano stati alterati durante il transito.

Il processo di handshake, attraverso l'uso di algoritmi crittografici e certificati, stabilisce un solido livello di fiducia che protegge le informazioni durante il transito.

Cosa succede se un handshake TLS fallisce?

Un handshake TLS non riuscito determina l'impossibilità di creare una connessione sicura. La connessione viene spesso terminata e gli utenti potrebbero riscontrare messaggi di errore come "SSL / TLS "handshake non riuscito" o "Impossibile stabilire una connessione sicura".

L'errore si verifica quando problemi quali versioni TLS incompatibili, certificati non validi, certificati scaduti o orologi di sistema non corretti impediscono una negoziazione corretta.

Come risolvere un handshake TLS?

Amministratori di sistema e gli utenti finali possono risolvere i guasti dell'handshake affrontando le cause profonde:

• Aggiorna o installa certificati validi. Devi sostituire i certificati scaduti o non validi. I provider di hosting e gli amministratori devono assicurarsi che i certificati siano firmati da CA attendibili e rimangano aggiornati.
• Controllare la configurazione e i protocolli supportati. Garantire che sia il cliente che server supportare le stesse versioni TLS e le stesse suite di cifratura è fondamentale. Disattivare vecchi protocolli come SSLv3 o TLS 1.0 elimina quelli noti vulnerabilità e previene gli errori di handshake correlati ai metodi di crittografia obsoleti.
• Sincronizzare gli orologi di sistema. Gli orologi di sistema precisi sono importanti per convalidare i tempi di scadenza e validità dei certificati. A server oppure un client con un'impostazione oraria errata potrebbe rifiutare certificati altrimenti validi.
• Verificare gli archivi di trust CA. Il sistema operativo o l'applicazione del client mantiene un elenco di CA attendibili. Verificare che la CA radice o intermedia pertinente sia presente e non revocata aiuta a prevenire errori di handshake.
• Ispezione server configurazione. Non configurato correttamente servers (ad esempio, priorità di suite di cifratura non corrette o catene di certificati incomplete) spesso portano a problemi di handshake. Esaminando server I registri e le configurazioni aiutano a individuare la discrepanza e consentono una rapida risoluzione.

Qual è la differenza tra SSL e TLS Handshake?

Il termine "handshake SSL" si riferisce al processo di handshake utilizzato dal livello di socket sicuro (SSL) protocollo, che era uno standard precedente per la crittografia e la protezione dei dati. L'handshake TLS è l'evoluzione moderna di SSL, che offre misure di sicurezza più forti e algoritmi crittografici aggiornati.

Sebbene i flussi di lavoro siano simili, TLS ha introdotto miglioramenti rispetto a SSL, tra cui suite di cifratura migliorate, migliore gestione dei certificati e meccanismi crittografici più robusti. SSL è stato deprecato a causa di vulnerabilità note e la maggior parte dei sistemi moderni utilizza TLS per comunicazioni sicure.

Molti riferimenti usano ancora "SSL" per descrivere l'handshake sicuro anche quando TLS viene utilizzato in background, ma il termine più accurato nelle implementazioni correnti è "handshake TLS". Il principio fondamentale rimane lo stesso: un processo di handshake negozia parametri di sicurezza, scambia certificati e stabilisce chiavi condivise per la comunicazione crittografata.