Dacă ați navigat vreodată pe un URL HTTPS printr-un browser, ați experimentat handshake-ul SSL. Chiar dacă s-ar putea să nu o observați, browserul și site-ul web creează o conexiune HTTPS folosind un handshake SSL unidirecțional.
Scopul principal al unui handshake SSL este de a asigura confidențialitatea și integritatea datelor pentru comunicarea dintre un server și un client. În timpul handshake-ului, serverul și clientul vor face schimb de informații importante necesare pentru a stabili o conexiune securizată.
Există două tipuri de handshake-uri SSL descrise ca one-way SSL și two-way SSL (Mutual SSL). Diferența dintre cele două constă în faptul că în cazul SSL unidirecțional, numai clientul validează identitatea serverului, în timp ce în cazul SSL bidirecțional, atât serverul, cât și clientul își validează reciproc identitatea. De obicei, atunci când navigăm pe un site web HTTPS, se utilizează SSL unidirecțional, în care doar browserul nostru (clientul) validează identitatea site-ului web (serverul). SSL bidirecțional este utilizat mai ales în comunicarea server-server, unde ambele părți trebuie să își valideze reciproc identitatea.
În timpul unui handshake SSL, serverul și clientul urmează setul de pași de mai jos.
1. Client Hello
Clientul va trimite informațiile de care va avea nevoie serverul pentru a începe o conexiune HTTPS.
În jurnalul de mai sus, putem vedea că clientul salută cu TLS v1.2. Prin aceasta, clientul notifică serverului faptul că are suport pentru versiunile TLS 1.2 și mai mici. Lista cifrelor care sunt acceptate de client poate fi văzută, de asemenea, din jurnalul de mai sus. Din această listă, serverul va selecta o suită de cifrare pe care o acceptă. În cazul în care lista conține suite de cifre pe care serverul nu le recunoaște, nu le acceptă sau nu dorește să le utilizeze, serverul va ignora aceste cifre. Dacă nu a fost găsită nicio suită de cifrare acceptată, serverul va trimite o alertă de eșec și va închide conexiunea.
2. Server Hello
Serverul va răspunde înapoi cu configurația pe care a selectat-o din Client Hello, împreună cu informațiile sale pentru a continua cu handshake-ul. Server Hello va fi după cum urmează.
Sever va selecta versiunea TLS în funcție de cea mai mică dintre cea sugerată de client în mesajul Client Hello și cea mai mare acceptată de server. De asemenea, serverul va trimite înapoi suita de cifrare pe care a selectat-o din lista de cifre prezentată de client.
Împreună cu mesajul Server Hello, serverul va trimite și certificatul serverului cu lanțul de certificate. Lanțul de certificate va fi validat în raport cu certificatele din depozitul de încredere al clientului.
3. Server Key Exchange Message
Acest mesaj va fi trimis de către server către client, purtând detaliile necesare pentru ca acesta să genereze secretul pre-master. Acest mesaj nu va fi trimis în cazul în care se utilizează algoritmul de schimb de chei RSA (mai multe în acest sens mai târziu) sau orice alt algoritm de schimb de chei care nu necesită informații de la server pentru a genera un secret pre-master.
Pentru schimbul de chei Elliptic Curve Diffie Hellman(ECDH), următoarele detalii privind cheia publică ECDH a serverului sunt trimise către client.
4. Certificate Request
Acesta este locul în care SSL unidirecțional defilează față de SSL bidirecțional. În SSL unidirecțional, autenticitatea clientului nu este validată. Prin urmare, această etapă este omisă în handshake-ul SSL unidirecțional.
În timpul acestei etape, serverul va trimite o cerere de certificat de la client cu tipul de certificat, algoritmii de semnătură a certificatului și autoritățile de certificare acceptate de server. Pot exista situații în care lista autorităților de certificare poate fi goală. În astfel de scenarii, clientul poate alege dacă să trimită sau să evite trimiterea certificatului clientului (depinde de implementarea clientului)
În cele din urmă, serverul trimite mesajul Server Hello Done, indicând sfârșitul Server Hello. După trimiterea acestui mesaj, serverul va aștepta un răspuns al clientului.
5. Certificatul clientului
Clientul prezintă serverului lanțul său de certificate. Certificatul trebuie să fie adecvat pentru algoritmul de schimb de chei al suitei de cifrare negociate și pentru orice extensii negociate.
6. Client Key Exchange Message
Acest mesaj trebuie să fie trimis de către client după mesajul Client Certificate. În cazul în care certificatul clientului nu este prezentat (în SSL unidirecțional), mesajul de schimb de chei al clientului trebuie trimis după ce clientul primește mesajul ServerHelloDone.
După cum știm cu toții, datele transferate între server și client într-o conexiune HTTPS vor fi criptate. Criptarea simetrică este utilizată în acest scop, deoarece costul de calcul este mult mai mic decât cel al criptării asimetrice. Pentru a utiliza criptarea simetrică, trebuie să existe o cheie comună între cele două capete. Scopul acestui mesaj este de a genera acea cheie comună între acel client și server fără a o expune unei persoane din afară.
Există două metode de schimb de chei între clienți descrise în specificația TLS v1.2. Acestea sunt RSA și Diffie-Hellman.
Dacă se folosește RSA ca algoritm de schimb de chei, clientul generează un secret pre-master de 48 de octeți. Clientul criptează secretul pre-master cu cheia publică a certificatului și îl trimite către server. Numai serverul va dispune de cheia privată corespunzătoare pentru a decripta și a obține secretul pre-master generat de client.
Dacă se utilizează Diffie-Hellman, parametrii Diffie-Hellman se transmit pentru a permite atât clientului, cât și serverului să genereze același secret pre-master.
După aceea, ambele părți vor genera un secret principal utilizând secretul pre-master, iar secretul principal va fi utilizat pentru a genera cheia simetrică pentru criptarea datelor sesiunii
7. Finished
După autentificarea reușită și generarea secretelor pre-master/secrete master, atât clientul, cât și serverul vor trimite un mesaj de schimbare a specificației cifrului, indicând că restul comunicării va fi criptat.
Mesajul Finished va urma imediat mesajului de schimbare a specificației cifrului. Acesta va fi primul mesaj criptat cu algoritmii negociați. Datele aplicației vor fi transferate numai după ce ambele părți vor trimite mesajul finished și vor verifica conținutul mesajului.
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/