Ce este un SSL/TLS Handshake?

Un SSL/TLS Handshake este o negociere între două părți dintr-o rețea – cum ar fi un browser și un server web – pentru a stabili detaliile conexiunii lor. Aceasta determină ce versiune de SSL/TLS va fi utilizată în sesiune, ce suită de cifru va cripta comunicarea, verifică serverul (și uneori și clientul) și stabilește că există o conexiune securizată înainte de a transfera date.

Toate acestea se întâmplă în fundal, din fericire – de fiecare dată când vă direcționați browserul către un site securizat are loc o interacțiune complexă pentru a vă asigura că datele dumneavoastră sunt în siguranță.

Aceasta este versiunea simplă. Ați putea observa că orice duzină de descrieri vor respecta mai mult sau mai puțin acest format, în timp ce diferă în detaliu într-o duzină de moduri diferite – uneori în mod confuz. Haideți să aruncăm un grafic care arată un model general al modului în care funcționează o strângere de mână TLS, da?

Aveți nevoie de un certificat? SSL.com vă acoperă. Comparați opțiunile aici pentru a găsi alegerea potrivită pentru dvs., de la certificate S/MIME și de semnare a codurilor și multe altele.

COMANDĂ ACUM

Graficul obligatoriu SSL/TLS Handshake

Toate site-urile legate de SSL/TLS au propria versiune a unei diagrame handshake – iată-o pe a noastră! (Click to enbiggen.)

Să clarificăm unele confuzii, dacă se poate

O parte din confuziile legate de modul în care funcționează handshake-urile SSL/TLS se datorează faptului că handshake-ul este doar preludiul sesiunii efective, securizate propriu-zise. Să încercăm să abordăm câteva puncte comune:

Criptare asimetrică vs. simetrică

Handshake-ul în sine folosește criptarea asimetrică – se folosesc două chei separate, una publică și una privată. Deoarece sistemele de criptare asimetrică au o suprasolicitare mult mai mare, acestea nu sunt utilizabile pentru a oferi securitate cu normă întreagă, în lumea reală. Astfel, cheia publică este utilizată pentru criptare, iar cheia privată pentru decriptare numai în timpul handshake-ului, ceea ce permite celor două părți să stabilească în mod confidențial și să schimbe o „cheie partajată” nou creată. Sesiunea în sine utilizează această cheie unică partajată pentru a efectua criptarea simetrică, ceea ce face ca o conexiune securizată să fie fezabilă în practică (costurile sunt mult mai mici). Așadar, răspunsul complet și corect la întrebarea „Este criptarea SSL/TLS asimetrică sau simetrică?” este „Mai întâi una, apoi cealaltă.”

Ce este o „suită de cifrare”?

Însuși strângerea de mână are mai multe etape, fiecare dintre ele fiind gestionată în conformitate cu reguli diferite. Detaliile pot fi găsite aici, dar esența este că, mai degrabă decât o serie de negocieri separate de du-te-vino (despre ce chei să folosească, cum să cripteze handshake-ul propriu-zis, cum să autentifice handshake-ul și așa mai departe), părțile pot conveni să folosească o „suită de cifrare” – o selecție preexistentă sau un kit de componente convenite. (Rețineți că criptarea asimetrică este costisitoare din punct de vedere al timpului și al resurselor – utilizarea suitei de cifrare ca o scurtătură accelerează handshake-ul propriu-zis). Specificațiile TLS permit un număr destul de mare de suite de cifrare, iar clientul și serverul vor avea aproape întotdeauna acces la una pe care o pot utiliza amândoi.

Basic vs. mutually-authenticated handshake

Un alt aspect derutant este faptul că modelul de bază pe care l-am descris mai sus permite clientului să verifice serverul, iar marea majoritate a sesiunilor securizate prin TLS necesită doar acest lucru. Cu toate acestea, unele suite de cifre vor cere clientului să trimită și un certificat și o cheie publică pentru autentificarea reciprocă a ambelor părți. Această autentificare bidirecțională va adăuga, bineînțeles, costuri suplimentare la handshake – cu toate acestea, în unele cazuri (de exemplu, atunci când două bănci negociază o conexiune securizată pentru transferuri de fonduri), suita de cifrare va insista asupra acesteia, iar securitatea suplimentară se consideră că merită.

Sesiuni diferite vor avea parametri de securitate diferiți

Care nou handshake creează o nouă sesiune, iar setările utilizate în una dintre ele pot diferi drastic de altele, în funcție de suita de cifrare aleasă. Acesta este unul dintre motivele pentru care există atât de multe iterații diferite ale acelui afurisit de grafic de handshake și motivul pentru care oferim aici o prezentare destul de generală. De asemenea, trebuie să știți că sesiunile pot seta parametri care s-ar putea să nu fie exact ceea ce vă așteptați. În funcție de suita de cifrare, unii pași pot fi adăugați (cum ar fi cerința de autentificare bidirecțională) sau absenți. De fapt, există de fapt suite de cifrare care negociază ca o sesiune să nu utilizeze niciun fel de criptare. (Da, știm, o conexiune HTTPS pe portul 443 care decide să trimită date în clar nu are sens nici pentru noi. SSL.com vă recomandă cu tărie să nu faceți acest lucru – fiți doar conștienți că este în domeniul posibilului.)

.

Lasă un răspuns

Adresa ta de email nu va fi publicată.