Cosa succede in un handshake TLS? | Handshake SSL

In un handshake TLS/SSL, client e server scambiano certificati SSL, requisiti della suite di cifratura e dati generati casualmente per la creazione di chiavi di sessione.

Obiettivi di apprendimento

Dopo aver letto questo articolo sarai in grado di:

  • Scopri cos'è un handshake TLS
  • Scopra cosa realizza un handshake TLS
  • Spiegare i passaggi in un handshake TLS
  • Esplora i diversi tipi di handshake TLS

Argomenti correlati


Vuoi saperne di più?

Ricevi un riepilogo mensile degli approfondimenti Internet più popolari!

Fai riferimento all'Informativa sulla privacy di Cloudflare per scoprire come raccogliamo ed elaboriamo i tuoi dati personali.

Copia link dell'articolo

Cos'è un handshake TLS?

L'handshake TLS

TLS is an encryption and authentication protocol designed to secure Internet communications. A TLS handshake is the process that kicks off a communication session that uses TLS. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the cryptographic algorithms they will use, and agree on session keys. TLS handshakes are a foundational part of how HTTPS works.

Handshake TLS e SSL

SSL, or Secure Sockets Layer, was the original security protocol developed for HTTP. SSL was replaced by TLS, or Transport Layer Security, some time ago. SSL handshakes are now called TLS handshakes, although the "SSL" name is still in wide use.

Whitepaper
Maximize the power of TLS
Guide
The Zero Trust guide to securing aplication access

Quando si verifica un handshake TLS?

A TLS handshake takes place whenever a user navigates to a website over HTTPS and the browser first begins to query the website's origin server. A TLS handshake also happens whenever any other communications use HTTPS, including API calls and DNS over HTTPS queries.

Gli handshake TLS si verificano dopo che una connessione TCP è stata aperta tramite un handshake TCP.

Secure SSL
Free SSL included with any Cloudflare plan

Cosa succede durante un handshake TLS?

Nel corso di un handshake TLS, il client e il server operano insieme come segue:

  • Specificano la versione di TLS (TLS 1.0, 1.2, 1.3, ecc.) che utilizzeranno
  • Decidono quali suite di crittografia (vedi sotto) utilizzeranno
  • Autenticano l'identità del server tramite la chiave pubblica del server e la firma digitale dell'autorità di certificazione SSL
  • Generano chiavi di sessione per utilizzare la crittografia simmetrica dopo il completamento dell'handshake

Quali sono le fasi di un handshake TLS?

Gli handshake TLS sono una serie di datagrammi, o messaggi, scambiati da un client e un server. Un handshake TLS prevede più passaggi, poiché il client e il server si scambiano le informazioni necessarie per completare l'handshake e rendere possibile un'ulteriore conversazione.

The exact steps within a TLS handshake will vary depending upon the kind of key exchange algorithm used and the cipher suites supported by both sides. The RSA key exchange algorithm, while now considered not secure, was used in versions of TLS before 1.3. It goes roughly as follows:

  1. Il messaggio 'client hello': il client inizia l'handshake inviando un messaggio "hello" al server. Il messaggio includerà la versione TLS supportata dal client, le suite di crittografia supportate e una stringa di byte casuali nota come "casuale client".
  2. Il messaggio 'server hello': in risposta al messaggio di saluto del client, il server invia un messaggio contenente il certificato SSL del server, la suite di cifratura scelta dal server e la stringa "casuale server", un'altra stringa casuale di byte generata dal server.
  3. Autenticazione: il client verifica il certificato SSL del server con l'autorità di certificazione che lo ha emesso. Ciò conferma che il server è chi dice di essere e che il client sta interagendo con l'effettivo proprietario del dominio.
  4. Il segreto premaster: il client invia un'altra stringa casuale di byte, il "segreto premaster". Il segreto premaster è crittografato con la chiave pubblica e può essere decrittografato solo con la chiave privata dal server. (Il client ottiene la chiave pubblica dal certificato SSL del server.)
  5. Chiave privata utilizzata: il server decritta il segreto premaster.
  6. Chiavi di sessione create: sia il client che il server generano chiavi di sessione dalla stringa casuale client, dalla stringa casuale server e dal segreto premaster. Dovrebbero arrivare agli stessi risultati.
  7. Il client è pronto: il client invia un messaggio "terminato" che viene crittografato con una chiave di sessione.
  8. Il server è pronto: il server invia un messaggio "terminato" crittografato con una chiave di sessione.
  9. Crittografia simmetrica sicura ottenuta: l'handshake è stato completato e la comunicazione continua utilizzando le chiavi di sessione.

All TLS handshakes make use of asymmetric cryptography (the public and private key), but not all will use the private key in the process of generating session keys. For instance, an ephemeral Diffie-Hellman handshake proceeds as follows:

  1. Client hello: il client invia un messaggio di benvenuto client con la versione del protocollo, la stringa casuale client e un elenco di suite di crittografia.
  2. Server hello: il server risponde con il suo certificato SSL, la suite di cifratura selezionata e il server casuale. Contrariamente all'handshake RSA descritto sopra, in questo messaggio il server include anche quanto segue (passo 3):
  3. Server's digital signature: The server computes a digital signature of all the messages up to this point.
  4. Digital signature confirmed: The client verifies the server's digital signature, confirming that the server is who it says it is.
  5. Client DH parameter: The client sends its DH parameter to the server.
  6. Il client e il server calcolano il segreto premaster: invece del client che genera il segreto del premaster e lo invia al server, come in un handshake RSA, il client e il server utilizzano i parametri DH che si sono scambiati per calcolare separatamente un segreto del premaster corrispondente.
  7. Chiavi di sessione create: ora, il client e il server calcolano le chiavi di sessione dal segreto premaster, dalla stringa casuale client e dalla stringa casuale server, proprio come in un handshake RSA
  8. Il client è pronto: uguale all'handshake RSA.
  9. Il server è pronto
  10. Crittografia simmetrica sicura ottenuta

*Parametro DH: DH sta per Diffie-Hellman. L'algoritmo Diffie-Hellman utilizza calcoli esponenziali per arrivare allo stesso segreto premaster. Il server e il client forniscono ciascuno un parametro per il calcolo e, se combinati, producono un calcolo diverso su ciascun lato, con risultati uguali.

Per saperne di più sul contrasto tra gli handshake Diffie-Hellman effimeri e altri tipi di handshake e su come ottengono la segretezza diretta, consulta Cos'è Keyless SSL?

What is different about a handshake in TLS 1.3?

TLS 1.3 does not support RSA, nor other cipher suites and parameters that are vulnerable to attack. It also shortens the TLS handshake, making a TLS 1.3 handshake both faster and more secure.

The basic steps of a TLS 1.3 handshake are:

  • Client hello: The client sends a client hello message with the protocol version, the client random, and a list of cipher suites. Because support for insecure cipher suites has been removed from TLS 1.3, the number of possible cipher suites is vastly reduced. The client hello also includes the parameters that will be used for calculating the premaster secret. Essentially, the client is assuming that it knows the server’s preferred key exchange method (which, due to the simplified list of cipher suites, it probably does). This cuts down the overall length of the handshake — one of the important differences between TLS 1.3 handshakes and TLS 1.0, 1.1, and 1.2 handshakes.
  • Server generates master secret: At this point, the server has received the client random and the client's parameters and cipher suites. It already has the server random, since it can generate that on its own. Therefore, the server can create the master secret.
  • Server hello and "Finished": The server hello includes the server’s certificate, digital signature, server random, and chosen cipher suite. Because it already has the master secret, it also sends a "Finished" message.
  • Final steps and client "Finished": Client verifies signature and certificate, generates master secret, and sends "Finished" message.
  • Crittografia simmetrica sicura ottenuta

0-RTT mode for session resumption

TLS 1.3 also supports an even faster version of the TLS handshake that does not require any round trips, or back-and-forth communication between client and server, at all. If the client and the server have connected to each other before (as in, if the user has visited the website before), they can each derive another shared secret from the first session, called the "resumption main secret." The server also sends the client something called a session ticket during this first session. The client can use this shared secret to send encrypted data to the server on its first message of the next session, along with that session ticket. And TLS resumes between client and server.

Cos'è una suite di cifratura?

A cipher suite is a set of algorithms for use in establishing a secure communications connection. There are a number of cipher suites in wide use, and an essential part of the TLS handshake is agreeing upon which cipher suite will be used for that handshake.

To learn more about TLS/SSL, see How does SSL work?.