Robert Heaton

HTTPS este pur și simplu protocolul HTTP standard acoperit cu un strat generos de bunătate de criptare SSL/TLS. Cu excepția cazului în care ceva merge groaznic de prost (și se poate întâmpla), acesta împiedică persoane precum infamul Eve să vizualizeze sau să modifice cererile care alcătuiesc experiența dvs. de navigare; este ceea ce vă păstrează parolele, comunicațiile și detaliile cărților de credit în siguranță pe firul dintre calculatorul dvs. și serverele către care doriți să trimiteți aceste date. În timp ce micul lacăt verde și literele „https” din bara de adrese nu înseamnă că nu există încă o frânghie amplă atât pentru dvs. cât și pentru site-ul web pe care îl vizualizați pentru a vă spânzura în altă parte, acestea vă ajută cel puțin să comunicați în siguranță în timp ce faceți acest lucru.

Ce este HTTPS și ce face?

HTTPS ia bine-cunoscutul și înțelesul protocol HTTP și, pur și simplu, suprapune un strat de criptare SSL/TLS (denumit în continuare simplu „SSL”). Serverele și clienții continuă să își vorbească între ei exact același HTTP, dar printr-o conexiune SSL securizată care criptează și decriptează cererile și răspunsurile lor. Stratul SSL are 2 scopuri principale:

• Verificarea faptului că vorbiți direct cu serverul cu care credeți că vorbiți
• Asigurarea faptului că numai serverul poate citi ceea ce îi trimiteți și numai dumneavoastră puteți citi ceea ce acesta vă trimite înapoi

Partea foarte, foarte inteligentă este că oricine poate intercepta fiecare dintre mesajele pe care le schimbați cu un server, inclusiv cele în care vă puneți de acord cu privire la cheia și strategia de criptare pe care trebuie să le folosiți, și totuși nu poate citi niciuna dintre datele reale pe care le trimiteți.

Cum se stabilește o conexiune SSL

O conexiune SSL între un client și un server este stabilită printr-o strângere de mână, ale cărei obiective sunt:

• Să convingă clientul că vorbește cu serverul potrivit (și, opțional, invers)
• Pentru ca părțile să fi convenit asupra unei „suite de cifrare”, care include algoritmul de criptare pe care îl vor utiliza pentru a face schimb de date
• Pentru ca părțile să fi convenit asupra oricăror chei necesare pentru acest algoritm

După ce conexiunea este stabilită, ambele părți pot utiliza algoritmul și cheile convenite pentru a-și trimite mesaje în siguranță una alteia. Vom împărți handshake-ul în 3 faze principale – Hello, Certificate Exchange și Key Exchange.

1. Hello – Handshake-ul începe cu trimiterea de către client a unui mesaj ClientHello. Acesta conține toate informațiile de care serverul are nevoie pentru a se conecta la client prin SSL, inclusiv diferitele suite de cifrare și versiunea SSL maximă pe care o suportă. Serverul răspunde cu un mesaj ServerHello, care conține informații similare cerute de client, inclusiv o decizie bazată pe preferințele clientului cu privire la suita de cifru și versiunea de SSL care vor fi folosite.

2. Schimb de certificate – Acum că a fost stabilit contactul, serverul trebuie să își dovedească identitatea față de client. Acest lucru se realizează cu ajutorul certificatului său SSL, care este foarte puțin asemănător cu pașaportul său. Un certificat SSL conține diverse date, inclusiv numele proprietarului, proprietatea (de exemplu, domeniul) la care este atașat, cheia publică a certificatului, semnătura digitală și informații despre datele de valabilitate ale certificatului. Clientul verifică fie că are încredere implicită în certificat, fie că acesta este verificat și de încredere de către una dintre cele câteva autorități de certificare (CA) în care are, de asemenea, încredere implicită. Mai multe despre acest aspect în scurt timp. Rețineți că serverului i se permite, de asemenea, să solicite un certificat pentru a dovedi identitatea clientului, dar acest lucru se întâmplă, de obicei, numai în cazul aplicațiilor foarte sensibile.

3. Schimbul de chei – Criptarea datelor reale ale mesajelor schimbate de către client și server se va face cu ajutorul unui algoritm simetric, a cărui natură exactă a fost deja convenită în timpul fazei Hello. Un algoritm simetric utilizează o singură cheie atât pentru criptare, cât și pentru decriptare, spre deosebire de algoritmii asimetrici, care necesită o pereche de chei publice/private. Ambele părți trebuie să cadă de acord asupra acestei chei unice, simetrice, un proces care se realizează în siguranță folosind criptarea asimetrică și cheile publice/private ale serverului.

Clientul generează o cheie aleatorie care va fi utilizată pentru algoritmul principal, simetric. Acesta o criptează folosind un algoritm asupra căruia s-a convenit, de asemenea, în timpul fazei Hello, și cheia publică a serverului (care se găsește pe certificatul SSL al acestuia). Acesta trimite această cheie criptată serverului, unde este decriptată cu ajutorul cheii private a serverului, iar părțile interesante ale schimbului de semnături sunt finalizate. Părțile sunt suficient de mulțumite de faptul că vorbesc cu persoana potrivită și că au convenit în secret asupra unei chei de criptare simetrică a datelor pe care urmează să și le trimită reciproc. Cererile și răspunsurile HTTP pot fi acum trimise prin formarea unui mesaj în text clar, apoi criptarea și trimiterea acestuia. Cealaltă parte este singura care știe cum să decripteze acest mesaj și, astfel, atacatorii Man In The Middle nu pot citi sau modifica cererile pe care le-ar putea intercepta.

Certificate

La nivelul cel mai de bază, un certificat SSL este pur și simplu un fișier text și oricine are un editor de text poate crea unul. De fapt, puteți crea în mod trivial un certificat care să pretindă că sunteți Google Inc. și că controlați domeniul gmail.com. Dacă aceasta ar fi toată povestea, atunci SSL ar fi o glumă; verificarea identității ar consta, în esență, în faptul că clientul ar întreba serverul „Sunteți Google?”, serverul ar răspunde „Da, sigur, iată o bucată de hârtie pe care scrie „Eu sunt Google””, iar clientul ar spune „Bine, minunat, iată toate datele mele”. Magia care previne această farsă se află în semnătura digitală, care permite unei părți să verifice dacă bucata de hârtie a altei părți este într-adevăr legală.

Există 2 motive rezonabile pentru care ați putea avea încredere într-un certificat:

• Dacă se află pe o listă de certificate în care aveți încredere implicită
• Dacă este capabil să dovedească faptul că este de încredere de către controlorul unuia dintre certificatele de pe lista de mai sus

Primul criteriu este ușor de verificat. Browserul dvs. are o listă preinstalată de certificate SSL de încredere de la autoritățile de certificare (CA) pe care o puteți vizualiza, adăuga și elimina. Aceste certificate sunt controlate de un grup centralizat de organizații (în teorie și, în general, în practică) extrem de sigure, fiabile și demne de încredere, precum Symantec, Comodo și GoDaddy. Dacă un server prezintă un certificat din această listă, atunci știți că puteți avea încredere în el.

Cel de-al doilea criteriu este mult mai dificil. Este ușor pentru un server să spună „er da, numele meu este er, Microsoft, tu ai încredere în Symantec și er, ei au încredere totală în mine, așa că totul este în regulă”. Un client oarecum inteligent ar putea apoi să se ducă și să întrebe Symantec „Am aici un Microsoft care spune că aveți încredere în ei, este adevărat?”. Dar chiar dacă Symantec spune „da, îi cunoaștem, Microsoft sunt legitimi”, tot nu știi dacă serverul care pretinde a fi Microsoft este de fapt Microsoft sau ceva mult mai rău. Aici intervin semnăturile digitale.

3.2 Semnături digitale

După cum am menționat deja, certificatele SSL au asociată o pereche de chei publice/private. Cheia publică este distribuită ca parte a certificatului, iar cheia privată este păstrată incredibil de bine păzită. Această pereche de chei asimetrice este utilizată în cadrul handshake-ului SSL pentru a schimba o altă cheie pentru ca ambele părți să cripteze și decripteze datele în mod simetric. Clientul folosește cheia publică a serverului pentru a cripta cheia simetrică și a o trimite în siguranță către server, iar serverul folosește cheia sa privată pentru a o decripta. Oricine poate cripta folosind cheia publică, dar numai serverul poate decripta folosind cheia privată.

Opusul este valabil pentru o semnătură digitală. Un certificat poate fi „semnat” de o altă autoritate, prin care autoritatea declară efectiv că „am verificat că operatorul acestui certificat controlează, de asemenea, proprietatea (domeniul) menționată pe certificat”. În acest caz, autoritatea utilizează cheia sa privată pentru a cripta (în linii mari) conținutul certificatului, iar acest text cifrat este atașat la certificat ca semnătură digitală. Oricine poate decripta această semnătură folosind cheia publică a autorității și poate verifica dacă rezultă valoarea decriptată așteptată. Dar numai autoritatea poate cripta conținutul cu ajutorul cheii private și, prin urmare, numai autoritatea poate crea de fapt o semnătură validă în primul rând.

Așa că, dacă apare un server care pretinde că are un certificat pentru Microsoft.com care este semnat de Symantec (sau de o altă autoritate de certificare), browserul dvs. nu trebuie să îl creadă pe cuvânt. Dacă este legitim, Symantec își va fi folosit cheia privată (ultrasecretă) pentru a genera semnătura digitală a certificatului SSL al serverului și, prin urmare, browserul dvs. poate folosi cheia publică (ultra-publică) a acestuia pentru a verifica dacă această semnătură este valabilă. Symantec va fi luat măsuri pentru a se asigura că organizația pentru care semnează deține cu adevărat Microsoft.com și, astfel, având în vedere că clientul dvs. are încredere în Symantec, poate fi sigur că vorbește cu adevărat cu Microsoft Inc.

3.3 Autofirmare

Rețineți că toate certificatele CA rădăcină sunt „autofirmate”, ceea ce înseamnă că semnătura digitală este generată folosind propria cheie privată a certificatului. Nu există nimic intrinsec special în legătură cu certificatul unei CA rădăcină – puteți genera propriul certificat autofirmat și îl puteți utiliza pentru a semna alte certificate, dacă doriți. Dar, din moment ce certificatul dvs. aleatoriu nu este preîncărcat ca AC în niciun browser, nicăieri, niciunul dintre ele nu va avea încredere în dvs. pentru a vă semna nici propriul certificat, nici alte certificate. Practic, spuneți „er, da, sunt în totalitate Microsoft, iată un certificat oficial de identitate emis și semnat de mine însumi”, iar toate browserele care funcționează în mod corespunzător vor afișa un mesaj de eroare foarte înfricoșător ca răspuns la acreditările dvs. dubioase.

Aceasta pune o povară enormă asupra tuturor editorilor de browsere și sisteme de operare pentru a avea încredere doar în CA-urile rădăcină curate, deoarece acestea sunt organizațiile în care utilizatorii lor sfârșesc prin a avea încredere pentru a verifica site-urile web și a păstra certificatele în siguranță. Aceasta nu este o sarcină ușoară.

3.4 În ce aveți încredere?

Este interesant de observat că, din punct de vedere tehnic, clientul dumneavoastră nu încearcă să verifice dacă ar trebui sau nu să aibă încredere în partea care i-a trimis un certificat, ci dacă ar trebui să aibă încredere în cheia publică conținută în certificat. Certificatele SSL sunt complet deschise și publice, astfel încât orice atacator ar putea lua certificatul Microsoft, ar putea intercepta cererea unui client către Microsoft.com și i-ar putea prezenta certificatul legitim. Clientul ar accepta acest lucru și ar începe bucuros strângerea de mână. Cu toate acestea, atunci când clientul criptează cheia care va fi utilizată pentru criptarea efectivă a datelor, o va face utilizând cheia publică reală a Microsoft din acest certificat real. Din moment ce atacatorul nu are cheia privată Microsoft pentru a o decripta, acesta este blocat. Chiar dacă strângerea de mână este finalizată, tot nu va putea decripta cheia și, prin urmare, nu va putea decripta niciuna dintre datele pe care i le trimite clientul. Ordinea se menține atâta timp cât atacatorul nu controlează cheia privată a unui certificat de încredere. Dacă clientul este cumva păcălit să aibă încredere într-un certificat și o cheie publică a căror cheie privată este controlată de un atacator, încep problemele.

4.1 Poate o cafenea să monitorizeze traficul meu HTTPS prin rețeaua lor?

Nu. Magia criptografiei cu cheie publică înseamnă că un atacator poate urmări fiecare octet de date schimbat între clientul dvs. și server și totuși nu are nicio idee despre ceea ce vă spuneți unul altuia, dincolo de cantitatea aproximativă de date pe care o schimbați. Cu toate acestea, traficul HTTP normal este în continuare foarte vulnerabil pe o rețea wi-fi nesigură, iar un site web nesigur poate fi victima oricărui număr de soluții care te păcălesc cumva să trimiți traficul HTTPS fie peste HTTP simplu, fie către un loc complet greșit. De exemplu, chiar dacă un formular de autentificare trimite o combinație nume de utilizator/parolă prin HTTPS, dacă formularul în sine este încărcat în mod nesigur prin HTTP, atunci un atacator ar putea intercepta HTML-ul formularului în drumul său către mașina dvs. și să-l modifice pentru a trimite detaliile de autentificare către propriul endpoint.

4.2 Poate compania mea să monitorizeze traficul meu HTTPS prin rețeaua lor?

Dacă folosiți, de asemenea, o mașină controlată de companie, atunci da. Amintiți-vă că la rădăcina fiecărui lanț de încredere se află o CA de încredere implicită și că o listă a acestor autorități este stocată în browserul dvs. Compania dvs. ar putea să se folosească de accesul lor la mașina dvs. pentru a adăuga propriul certificat auto-semnat la această listă de autorități de certificare. Astfel, ar putea intercepta toate cererile dumneavoastră HTTPS, prezentând certificate care pretind că reprezintă site-ul web corespunzător, semnate de CA-ul lor fals și, prin urmare, de încredere neîndoielnică pentru browserul dumneavoastră. Având în vedere că ați putea cripta toate cererile HTTPS utilizând cheia publică a certificatului lor fals, aceștia ar putea utiliza cheia privată corespunzătoare pentru a decripta și inspecta (chiar modifica) cererea dvs. și apoi ar putea să o trimită la locul destinat. Probabil că nu o fac. Dar ar putea.

În mod întâmplător, acesta este, de asemenea, modul în care se utilizează un proxy pentru a inspecta și modifica solicitările HTTPS, altfel inaccesibile, făcute de o aplicație iPhone.

4.3 Deci, ce s-a întâmplat cu Lavabit și FBI?

Lavabit a fost furnizorul de e-mail super-securizat al lui Edward Snowden în timpul nebuniei scurgerilor de informații NSA din 2013. După cum am văzut, niciun fel de hacking standard nu a putut permite FBI-ului să vadă orice date pe drumul dintre Lavabit și clienții săi. Fără cheia privată a certificatului SSL Lavabit, agenția a fost dată peste cap. Cu toate acestea, un judecător util din SUA i-a spus fondatorului Lavabit, Ladar Levison, că trebuie să predea această cheie, dându-i efectiv FBI-ului mână liberă să cotrobăie în trafic după bunul său plac. Levison a făcut o încercare curajoasă de a trage de timp, predând cheia de 2.560 de caractere în 11 pagini tipărite cu caractere de 4 puncte, dar a fost lovit de un ordin prin care i se cerea să predea cheia într-un format util sau să se confrunte cu o amendă de 5.000 de dolari pe zi până când o va face.

După ce s-a conformat, GoDaddy, CA-ul Lavabit, a revocat certificatul, după ce l-a considerat (corect) compromis. Acest lucru a adăugat certificatul Lavabit la o listă de revocare a certificatelor (Certificate Revocation List – CRL), o listă de certificate discreditate în care clienții nu ar mai trebui să aibă încredere pentru a asigura o conexiune sigură. Certificatele compromise, autofirmate sau care nu sunt demne de încredere determină browserele să afișeze un mare mesaj de eroare roșu și fie să descurajeze, fie să interzică în mod categoric acțiunile ulterioare ale utilizatorului. Din nefericire, browserele vor continua să aibă încredere într-un certificat stricat până când vor extrage cele mai noi actualizări din CRL, un proces care se pare că este imperfect în practică.

Concluzie

HTTPS nu este de neînvins, iar protocolul SSL trebuie să evolueze în mod constant, pe măsură ce sunt descoperite și zdrobite noi atacuri împotriva sa. Cu toate acestea, este totuși o modalitate impresionant de robustă de a transmite date secrete fără să te intereseze cine îți vede mesajele. Există, bineînțeles, multe detalii de implementare care nu sunt menționate aici, cum ar fi formatul și ordinea exactă a mesajelor de strângere de mână, strângerile de mână prescurtate pentru a prelua sesiunile recente fără a fi nevoie să se renegocieze cheile și suitele de cifrare, precum și numeroasele opțiuni de criptare diferite disponibile în fiecare etapă. Principalul lucru pe care trebuie să-l rețineți este că, deși HTTPS păstrează datele în siguranță pe fir până la destinație, nu vă protejează în niciun fel (în calitate de utilizator sau dezvoltator) împotriva XSS, a scurgerilor de date sau a oricăror alte lucruri care se întâmplă în timpul nopții. Bucurați-vă că vă apără, dar rămâneți vigilenți. În nemuritoarele cuvinte ale lui Will Smith, „Mergeți în umbră, mișcați-vă în tăcere, păziți-vă de violența extraterestră.”

Dacă v-a plăcut acest articol, probabil că vă va plăcea postarea mea care explică detaliile vulnerabilității FREAK din 2015 în SSL.