Lacătul verde demistificat: cum funcționează strângerea de mână SSL?

În fiecare zi, când navighezi pe Web cu securitatea în minte, te gândești la celebrul lacăt verde de lângă adresa URL a site-ului web din browser și la versiunea HTTPS a protocolului de transfer de date. În acest articol, vom descoperi de ce HTTPS este cu adevărat sigur și cum este protejată comunicarea împotriva interceptării cu urechea de către o terță parte.

În primul rând, vom prezenta pe scurt cele două concepte criptografice de bază: semnătura digitală și criptare, ne vom scufunda într-un proces numit strângere de mână SSL , care este efectuat înainte ca clientul și serverul să înceapă să facă schimb de comunicare și este folosit pentru a stabili un context criptografic securizat. Vom termina cu informații despre cum să creștem și mai mult securitatea cu un pas opțional numit autentificare certificat client.

Criptografia cu cheie publică 101: Pereche de chei

Faceți cunoștință cu Alice și Bob, două persoane care au decis să folosească metode criptografice pentru a-și schimba mesajele private în siguranță. Prima alegere cu care trebuie să se confrunte este între două tipuri diferite de criptografie: criptografie cu cheie simetrică și asimetrică (numită și criptografie cu cheie publică).

Dar stai, care sunt cheile astea ? Practic, putem simplifica faptul că o cheie este o secvență aleatorie de caractere. Putem folosi această secvență pentru a transforma (a face o anumită operație criptografică) pe un mesaj - vom cerceta în curând.

Criptografia cu cheie simetrică

Când se utilizează cripto-cheie simetrică, un expeditor generează o cheie și apoi o dublează pentru receptor. Expeditorul salvează cheia originală, iar un duplicat este livrat destinatarului. Aceeași cheie este utilizată pentru operațiunile cripto la ambele capete ale comunicării.

Și care sunt principalele beneficii și dezavantaje ale criptografiei cu chei simetrice?

Criptografia cu cheie asimetrică

Când se utilizează cripto-cheie asimetrică, atât expeditorul cât și receptorul generează o pereche de chei - o cheie publică și o cheie privată. Cheile sunt cuplate matematic între ele pentru a lucra împreună în diferite operațiuni cripto. Atât expeditorul, cât și destinatarul își salvează cheile private în siguranță, dar pot schimba cheile publice fără precauții speciale. Ei pot folosi chiar și un fel de „pagini galbene cu chei publice” – un server de chei publice pentru a trimite cheile lor publice pentru a fi accesibile de oricine.

Care sunt avantajele și dezavantajele criptografiei cu chei asimetrice?

Deoarece o configurație cripto asimetrică este mai sigură, Alice și Bob au decis să meargă cu ea! Acum pot profita de asta și pot începe să se gândească la asigurarea securității și integrității comunicării.

Criptografia cu cheie publică 101: Criptare

Când Alice îi trimite un mesaj lui Bob, ea vrea să fie sigură că nimeni altcineva nu poate vedea care este conținutul. Ea decide să cripteze mesajul. Pentru a realiza acest lucru, Alice trebuie mai întâi să obțină cheia publică a lui Bob fie de la un server de chei, fie direct de la Bob printr-un canal de comunicare. Odată ce Alice obține cheia, poate aplica o operațiune de criptare folosind cheia publică a lui Bob pe mesajul pe care dorește să-l trimită.

În general, în acest proces, mesajul este preluat de un algoritm criptografic (aka cipher) în blocuri (cel mai frecvent) și sunt efectuate unele operații pe biți între mesaj și cheie, producând o ieșire care este mesajul criptat (aka ciphertext). . Când Bob primește mesajul criptat, el este singura persoană care îl poate decripta cu cheia sa privată.

Notă:

• Criptarea mesajelor – expeditorul criptează un mesaj cu cheia publică a destinatarului
• Decriptarea mesajelor – destinatarul decriptează un mesaj cu cheia privată

Criptografia cu cheie publică 101: Semnătură

În afară de a împiedica dezvăluirea conținutului mesajului, este la fel de important să poți confirma identitatea expeditorului și să verifici dacă mesajul nu a fost modificat. O semnătură digitală (un obiect separat atașat mesajului) este folosită exact din aceste două motive.

Alice folosește mai întâi un algoritm de hashing pentru a dezvolta un mesaj hash pentru a-și genera semnătura. Hashing este calculul unei funcții matematice unidirecționale pe un mesaj care produce o ieșire cu valoare fixă ​​mai scurtă - diferită pentru o intrare diferită. Apoi își folosește cheia privată pentru a cripta (semna) hash-ul generat.

Apoi, când Bob primește mesajul și semnătura, mai întâi poate decripta semnătura folosind cheia publică a lui Alice. Când reușește, el știe că semnătura a fost într-adevăr generată de Alice (în caz contrar, decriptarea cu cheia ei publică ar eșua).

În al doilea rând, Bob poate să ia mesajul și să-l trimită folosind același algoritm pe care l-a avut Alice înainte și să confirme că hash-ul său al mesajului este același cu cel generat de Alice. Când hashurile se potrivesc, el știe că mesajul nu a fost modificat.

Notă:

• Generarea semnăturii – expeditorul criptează (semnează) hash-ul mesajului cu cheia sa privată și creează o semnătură
• Verificarea semnăturii – destinatarul decriptează mai întâi hash-ul mesajului din semnătură și verifică dacă un hash calculat de el se potrivește cu cel din semnătură
• Criptarea și semnătura pot fi utilizate separat , dar pentru cea mai mare securitate, de obicei sunt combinate. Prin urmare, majoritatea funcțiilor cripto pe care le puteți întâlni sunt numite encryptSignMessage() , decryptVerifyMessage() etc.

Sper că nu ai probleme să ții pasul cu povestea Alice și Bob. Permiteți-mi să ilustrez încă o dată întregul flux pentru a mă asigura că totul este clar și pentru a rezuma lucrurile.

1. Alice vrea să-i trimită un mesaj lui Bob
2. Alice își ia cheia privată și generează o semnătură
3. Alice ia cheia publică a lui Bob și criptează mesajul
4. Alice îi trimite mesajul lui Bob
5. Bob ia cheia publică a lui Alice și verifică semnătura
6. Bob își folosește cheia privată pentru a decripta mesajul

Bine, e suficientă teorie. Acum să vedem cum sunt folosite toate acestea în HTTPS!

SSL Handshake

Salută te rog

Când un client inițiază o conexiune la un server, este mai întâi esențial să se facă o introducere adecvată pentru a stabili contextul criptografic pentru restul comunicării. Acest lucru se poate face în pasul HTTPS CONNECT, cu mult înainte de analiza antetelor și a corpurilor cererii. Totul începe cu clientul care trimite un mesaj de salut client .

Cel mai important, mesajul conține algoritmi cripto pe care clientul îi înțelege și ceva material suplimentar, cum ar fi algoritmi de compresie acceptați, versiuni de protocol, id-ul de sesiune etc. Deoarece serverului îi place să fie politicos, răspunde și cu un mesaj de salut al serverului, care mai ales conține certificatul serverului cu cheia publică a serverului (da, procesul se bazează pe criptografia cu cheie publică – aceeași metodă pe care au ales-o Alice și Bob).

Autoritate certificată

Acum este timpul să urăm bun venit următorului nostru oaspete în scenă: o autoritate de certificare (CA). Numele sună serios – dar este doar o entitate terță parte, cu o mulțime de credite stradale, care este în principiu considerată de încredere în întreaga lume. O astfel de entitate poate valida identitatea unui server și își poate plasa semnătura digitală împreună cu certificatul serverului (în mod similar cu Alice când îi trimite mesaje lui Bob).

Verificarea certificatului

Acum să luăm în sfârșit în considerare titlul lacătului verde de lângă adresa URL a browserului dvs.

Fiecare client web are o listă de chei publice binecunoscute și de încredere ale autorităților de certificare . Poate vă amintiți că la începutul articolului, am menționat că semnătura este generată folosind cheia privată a unui expeditor și poate fi verificată folosind cheia publică a expeditorului. Ei bine, exact asta face clientul . Acesta parcurge lista CA-urilor de încredere și verifică dacă semnătura certificatului de server aparține unuia dintre CA-urile de încredere. Dacă o face, acceptă certificatul – și acesta este momentul în care lacătul devine verde .

Dar acesta este doar un prim pas, care nu are încă nimic de-a face cu securitatea. Oricine poate copia orice certificat de cheie publică, îl poate pune pe un server și îl poate prezenta unui client care se conectează, nu?

După ce clientul verifică certificatul serverului, acesta creează o cheie simetrică pentru a cripta comunicarea. Dar, așa cum am menționat la început, problema cheilor simetrice este că sunt vulnerabile la interceptarea în timpul transportului. La acest pas, clientul și serverul nu au un context criptografic comun. Deci clientul trimite cheia simetrică către server, dar mai întâi o criptează cu cheia publică a serverului. Apoi serverul îl primește și are nevoie de capacitatea de a-l decripta pentru a stabili o conexiune sigură.

Prin urmare, chiar dacă cineva ar prezenta un certificat de cheie publică furată , acesta este pasul în care ar eșua. O cheie privată validă legată de cheia publică a certificatului de server este esențială pentru a decripta cheia simetrică. Desigur, aceasta nu este o problemă pentru un server legitim, deoarece are cheia privată salvată în siguranță. Poate fi folosit pentru a decripta cheia simetrică și a cripta comunicarea ulterioară.

Deci, pentru a rezuma, o strângere de mână SSL este un proces în care sunt utilizate atât tipurile de criptografie simetrice, cât și asimetrice . La început, perechea de chei asimetrice inițiază conexiunea și oferă o modalitate sigură de deplasare a cheii simetrice. După cum am subliniat la început, operațiunile de criptare simetrică sunt mai rapide, așa că folosirea acesteia pentru întreaga comunicare după configurare este benefică. De asemenea, odată ce o conexiune securizată este stabilită, aceasta este reutilizată până la expirare, astfel încât configurarea cheii asimetrice nu se face înainte de fiecare solicitare a clientului.

De asemenea, merită menționat faptul că, în viața reală, certificatele nu sunt semnate direct de cele mai cunoscute CA de încredere (numite roots ). Totuși, CA rădăcină semnează certificate intermediare, care apoi semnează în cele din urmă certificatul serverului – creând astfel un lanț de certificate, pe care clientul care se conectează le verifică până când este îndeplinită o semnătură validă. Cu siguranță oferă o securitate mai bună – atunci când una dintre CA intermediare este compromisă, afectează mai puține persoane.

Validarea certificatului clientului

Acum, există un pas opțional pe care îl putem menționa pe scurt, deoarece avem toate cunoștințele necesare pentru a-l înțelege. Un server poate fi configurat să solicite și să valideze un certificat de client după stabilirea unei conexiuni securizate pentru a obține o securitate suplimentară.

Funcționează în același mod – dar de data aceasta, clientul își trimite certificatul , iar serverul parcurge lista lor de autorități de certificare de încredere și o verifică. De asemenea, este de remarcat faptul că serverul se află sub controlul dezvoltatorilor (opus unui client, adică un browser web sau un sistem de operare mobil), astfel încât dezvoltatorii backend pot modifica cu ușurință lista de certificate de încredere.

Rețelele corporative folosesc de obicei acest mecanism. Cel mai frecvent, certificatele client sunt generate de un sistem de management al dispozitivelor instalat pe dispozitivul angajatului și sunt semnate cu un certificat rădăcină generat de companie. Același certificat este adăugat și în mediul backend. În acest fel, backend-ul corporativ poate verifica cu ușurință certificatul atunci când clientul se conectează.

Să răsfoim soluțiile noastre de backend

Citeste mai mult

Acum, pentru a rezuma, să vedem o diagramă pentru întregul flux:

rezumat

Ai ajuns la finalul articolului! Sperăm că înțelegeți deja mecanismul de implementare a configurației de criptare în HTTPS și metodele de aplicare a proceselor de semnare și criptare.

Din moment ce știți cum funcționează lucrurile, cu siguranță ar trebui să vă simțiți mai încrezători în ceea ce privește criptarea datelor. Totuși, este esențial să rețineți că un lacăt verde în browser nu garantează încă siguranța . În contextul sensibil la securitate, ar trebui să examinați, de asemenea, certificatul îndeaproape. După cum se spune, prevenit este prearmat!