Se hai mai navigato su un URL HTTPS attraverso un browser, hai sperimentato l’SSL handshake. Anche se potrebbe non notarlo, il browser e il sito web stanno creando una connessione HTTPS usando un SSL handshake a senso unico.
Lo scopo principale di un SSL handshake è quello di fornire privacy e integrità dei dati per la comunicazione tra un server e un client. Durante l’handshake, server e client si scambiano importanti informazioni necessarie per stabilire una connessione sicura.
Ci sono due tipi di SSL handshake descritti come SSL a una via e SSL a due vie (Mutual SSL). La differenza tra questi due è che in SSL a una via, solo il client convalida l’identità del server mentre in SSL a due vie, sia il server che il client convalidano l’identità dell’altro. Di solito, quando navighiamo su un sito web HTTPS, viene usato un SSL a senso unico dove solo il nostro browser (client) convalida l’identità del sito web (server). L’SSL a due vie è usato per lo più nelle comunicazioni da server a server dove entrambe le parti devono convalidare l’identità l’una dell’altra.
Durante un SSL handshake, il server e il client seguono la seguente serie di passi.
1. Client Hello
Il client invierà le informazioni che saranno richieste dal server per iniziare una connessione HTTPS.
Nel log di cui sopra, possiamo vedere che il client hello con TLS v1.2. Con questo, il client notifica al server che ha il supporto per le versioni TLS 1.2 e inferiori. L’elenco dei cifrari che sono supportati dal client può anche essere visto dal log di cui sopra. Da questa lista, il server selezionerà una suite di cifrari che supporta. Se la lista contiene suite di cifrari che il server non riconosce, supporta o desidera utilizzare, il server ignorerà quei cifrari. Se non sono state trovate suite di cifratura supportate, il server invierà un avviso di fallimento e chiuderà la connessione.
2. Server Hello
Il server risponderà con la configurazione che ha selezionato dal Client Hello insieme alle sue informazioni per procedere con l’handshake. Server Hello sarà il seguente.
Il server selezionerà la versione TLS in base alla più bassa tra quella suggerita dal client nel messaggio Client Hello e la più alta supportata dal server. Il server invierà anche la cipher suite che ha selezionato dalla lista dei cifrari presentata dal client.
Insieme al Server Hello, il server invierà anche il certificato del server con la catena del certificato. La catena del certificato sarà convalidata rispetto ai certificati nel negozio di fiducia del client.
3. Server Key Exchange Message
Questo messaggio sarà inviato dal server al client portando i dettagli richiesti dal client per generare il pre-master secret. Questo messaggio non sarà inviato se si usa l’algoritmo di scambio di chiavi RSA (più avanti) o qualsiasi altro algoritmo di scambio di chiavi che non richiede le informazioni dal server per generare un segreto pre-master.
Per lo scambio di chiavi Elliptic Curve Diffie Hellman(ECDH), i seguenti dettagli sulla chiave pubblica ECDH del server vengono inviati al client.
4. Richiesta di certificato
Questo è il posto dove SSL a senso unico differisce da SSL a due vie. In SSL unidirezionale, l’autenticità del cliente non viene convalidata. Quindi, questo passo è omesso nel SSL a senso unico.
Durante questo passo, il server invierà una richiesta di certificato dal client con il tipo di certificato, gli algoritmi di firma del certificato e le autorità di certificazione supportate dal server. Ci possono essere situazioni in cui l’elenco delle autorità di certificazione può essere vuoto. In tali scenari, il client può scegliere se inviare o evitare l’invio del certificato client (dipende dall’implementazione del client)
Infine, il server invia il messaggio Server Hello Done che indica la fine del Server Hello. Dopo aver inviato questo messaggio, il server aspetterà la risposta del client.
5. Certificato del client
Il client presenta la sua catena di certificati al server. Il certificato deve essere appropriato per l’algoritmo di scambio di chiavi della suite di cifratura negoziata, e qualsiasi estensione negoziata.
6. Messaggio di scambio di chiavi del cliente
Questo messaggio deve essere inviato dal cliente dopo il messaggio del certificato del cliente. Se il certificato client non viene presentato (in SSL unidirezionale), il messaggio di scambio di chiavi client deve essere inviato dopo che il client riceve il messaggio ServerHelloDone.
Come tutti sappiamo i dati trasferiti tra il server e il client in una connessione HTTPS saranno criptati. La crittografia simmetrica viene utilizzata per questo scopo in quanto il costo computazionale è molto più basso della crittografia asimmetrica. Per usare la crittografia simmetrica, ci deve essere una chiave comune tra le due estremità. Lo scopo di questo messaggio è di generare quella chiave comune tra quel client e il server senza esporla a un estraneo.
Ci sono due metodi di scambio di chiavi client descritti nella specifica TLS v1.2. Sono RSA e Diffie-Hellman.
Se RSA è usato come algoritmo di scambio di chiavi, il client genera un segreto pre-master di 48 byte. Il client cripta il segreto pre-master con la chiave pubblica del certificato e lo invia al server. Solo il server avrà la chiave privata corrispondente per decifrare e ottenere il segreto pre-master generato dal client.
Se viene usato Diffie-Hellman, i parametri Diffie-Hellman vengono trasmessi per permettere sia al client che al server di generare lo stesso segreto pre-master.
Dopo di che, entrambe le parti genereranno un segreto master usando il segreto pre-master e il segreto master sarà usato per generare la chiave simmetrica per criptare i dati della sessione
7. Finito
Dopo l’autenticazione riuscita e la generazione dei segreti pre-master/master secrets, un messaggio change cipher spec sarà inviato sia dal client che dal server indicando che il resto della comunicazione sarà criptata.
Il messaggio Finito seguirà immediatamente il messaggio change cipher spec. Questo sarà il primo messaggio cifrato con gli algoritmi negoziati. I dati dell’applicazione saranno trasferiti solo dopo che entrambe le parti avranno inviato il messaggio finito e verificato il contenuto del messaggio.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/