Autoritățile de certificare sunt una dintre cele mai importante pietre de temelie pentru securitatea pe Internet. O autoritate de certificare este cineva în care toți au încredere, la început, când nimeni nu are încredere în nimeni altcineva. Este apoi treaba acestei autorități de certificare (a.k.a. CA) să se asigure că încrederea este stabilită între servere și clienți înainte ca aceștia să stabilească o comunicare pe Internet. o CA este importantă nu numai pentru HTTPS folosit de browsere și aplicații web, ci și pentru e-mailuri criptate, actualizări software semnate, VPN-uri și multe, multe altele. Vom lua exemplul prototipic al HTTPS și vom învăța despre CA, în acest context particular. Deși puteți extrapola rezultatul la orice altă suită software.
Internetul este un canal de comunicare de neîncredere. Când trimiteți sau primiți informații de pe un site HTTP vechi http://www.example.com în browserul dumneavoastră, se pot întâmpla o mulțime de lucruri la jumătatea drumului pachetelor.
- Un actor rău poate intercepta comunicarea, poate copia datele pentru el însuși, înainte de a le retrimite din nou pe canal către dumneavoastră sau către serverul cu care vorbeați. Fără ca niciuna dintre părți să știe, informațiile sunt compromise. Trebuie să ne asigurăm că comunicarea este privată.
- Un actor rău poate modifica informația în timp ce este trimisă pe canal. Bob ar fi putut trimite un mesaj „x”, dar Alice ar primi „y” de la Bob, deoarece un actor rău a interceptat mesajul și l-a modificat. Cu alte cuvinte, integritatea mesajului este compromisă.
- În cele din urmă, și cel mai important, trebuie să ne asigurăm că persoana cu care vorbim este într-adevăr cine spune că este. Revenind la domeniul exemplu.com. Cum putem să ne asigurăm că serverul care ne-a răspuns este într-adevăr deținătorul de drept al www.example.com? În orice punct al rețelei dumneavoastră, puteți fi direcționat greșit către un alt server. Un DNS undeva este responsabil pentru convertirea unui nume de domeniu, cum ar fi www.example.com, într-o adresă IP pe internetul public. Dar browserul dvs. nu are nicio modalitate de a verifica dacă DNS-ul a tradus adresa IP.
Primele două probleme pot fi rezolvate prin criptarea mesajului înainte ca acesta să fie trimis pe internet către server. Adică prin trecerea la HTTPS. Cu toate acestea, ultima problemă, problema identității, este cea în care intră în joc o autoritate de certificare.
Inițierea sesiunilor HTTP criptate
Principala problemă a comunicării criptate pe un canal nesigur este „Cum o începem?”
Primul pas ar implica ca cele două părți, browserul dumneavoastră și serverul, să facă schimb de chei de criptare care să fie schimbate pe canalul nesigur. Dacă nu sunteți familiarizați cu termenul de chei, gândiți-vă la ele ca la o parolă foarte lungă generată la întâmplare cu care datele dvs. vor fi criptate înainte de a fi trimise pe canalul nesigur.
Ei bine, dacă cheile sunt trimise pe un canal nesigur, oricine poate asculta pe acesta și poate compromite securitatea sesiunii dvs. HTTPS în viitor. În plus, cum putem avea încredere că cheia trimisă de un server care pretinde că este www.example.com este într-adevăr proprietarul real al acelui nume de domeniu? Putem avea o comunicare criptată cu o parte rău intenționată care se deghizează în site legitim și nu putem face diferența.
Așa că, problema asigurării identității este importantă dacă dorim să asigurăm un schimb de chei securizat.
Autorități de certificare
Poate că ați auzit de LetsEncrypt, DigiCert, Comodo și alte câteva servicii care oferă certificate TLS pentru numele dumneavoastră de domeniu. Îl puteți alege pe cel care se potrivește nevoilor dumneavoastră. Acum, persoana/organizația care deține domeniul trebuie să dovedească în vreun fel autorității de certificare că într-adevăr deține controlul asupra domeniului. Acest lucru se poate face fie prin crearea unei înregistrări DNS cu o valoare unică în ea, așa cum solicită autoritatea de certificare, fie prin adăugarea unui fișier pe serverul dvs. web, cu un conținut specificat de autoritatea de certificare, iar autoritatea de certificare poate citi acest fișier și poate confirma că sunteți un proprietar valid al domeniului.
Apoi negociați un certificat TLS cu autoritatea de certificare, iar acest lucru are ca rezultat o cheie privată și un certificat TLS public emis pentru domeniul dvs. Mesajele criptate de cheia dvs. privată pot fi apoi decriptate de certificatul public și viceversa. Acest lucru este cunoscut sub numele de criptare asimetrică
Furnizoarele client, cum ar fi Firefox și Chrome (uneori chiar și sistemul de operare) au cunoștințe despre autoritățile de certificare. Aceste informații sunt integrate în browser/dispozitiv încă de la început (adică atunci când sunt instalate), astfel încât acestea știu că pot avea încredere în anumite autorități de certificare. Acum, atunci când încearcă să se conecteze la www.example.com prin HTTPS și vede un certificat emis, de exemplu, de DigiCert, browserul poate verifica acest lucru folosind cheile stocate la nivel local. De fapt, mai sunt câțiva pași intermediari, dar aceasta este o bună prezentare simplificată a ceea ce se întâmplă.
Acum că certificatul furnizat de www.example.com poate fi de încredere, acesta este folosit pentru a negocia o cheie de criptare simetrică unică, care este folosită între client și server pentru restul sesiunii lor. În criptarea simetrică, o singură cheie este folosită atât pentru criptare, cât și pentru decriptare și este, de obicei, mult mai rapidă decât omologul său asimetric.
Nuanțe
Dacă ideea de TLS și de securitate pe internet vă atrage, puteți aprofunda acest subiect, cercetând LetsEncrypt și CA-ul lor TLS gratuit. Există mult mai multe minuțiozități decât cele menționate mai sus în toată această întreagă învălmășeală.