SSL (Secure Socket Layer), numit şi TLS (Transport Socket Layer), este un protocol care permite ca două aplicaţii să comunice într-un mod securizat. În cazul transmiterii datelor pe Web – Serverul comunică cu Clientul prin protocolul HTTPS şi nu HTTP.
Cum funcţionează SSL?
Deobicei datele circula de la Client spre Server şi vice-versa în mod text şi pot fi citite şi modificate de oricine poate prelua comunicarea dintre Client şi Server. Pentru ca acest lucru să nu se întâmple, protocolul SSL criptează informaţia care circulă prin canalele din internet şi verifică dacă proprietarul serverului este cel real. În modul acesta, clientul poate fi sigur că s-a logat pe site-ul băncii sale şi nu a trimis datele spre un alt server care ar putea să profite de datele contului său.
Modelul SSL foloseşte tehnica de “public/private key encryption”. O cheie publică este un string compus din litere şi cifre care se foloseşte la criptarea mesajelor astfel, încât numai proprietarul cheii publice îl poate citi. Acest mesaj, însă, poate fi descifrat doar dacă a fost criptat cu o cheie privată. Cheile funcţionează şi pe invers: mesajele criptate cu o cheie privată pot fi decriptate cu o cheie publică.
SSL Handshake: Identitate şi securitate
Spre exemplu Maria doreşte să îşi acceseze contul bancar de pe www.bancamariei.ro. Browser-ul Mariei începe o conecţiune HTTPS cu serverul www.bancamariei.ro şi transmite acestuia un string generat aleator pe care îl vom numi “noroc”.
Serverul www.bancamariei.ro va începe conecţiunea cu Maria şi va trimite browser-ului ei două lucruri: cheia sa publică criptată într-un certificat SSL şi “noroc” criptat cu cheia sa privată.
Serverul www.bancamariei.ro va începe conecţiunea cu Maria şi va trimite browser-ului ei două lucruri: cheia sa publică criptată într-un certificat SSL şi “noroc” criptat cu cheia sa privată.
Browser-ul Mariei va decripta mesajul de “noroc” cu cheia publică primită de la server. Dacă mesajul decriptat este identic cu cel transmis de Maria mai înainte spre server – atunci serverul sigur este www.bancamariei.ro , căci numai cheia privată de pe server poate cripta mesajul în aşa fel încât să poată fi decriptat cu cheia publică.
Să presupunem că Ion este un administrator de reţea şi monitorizează această comunicare de pe Internet. Până acum el a putut prelua din discuţia Client – Server cheia publică a băncii şi mesajul “noroc” a Mariei. Dar el nu are cheia privată a serverului, astfel, el nu poate cripta mesajul ca să îl trimită clientului. Deci, Ion nu poate să o păcălească pe Maria.
Problema identităţii
Dar ce s-ar fi putut întâmpla dacă Ion intervenea din start în discuţia dintre Maria şi bancă? Ce se întâmplă dacă browser-ul Mariei ar fi discutat de la început cu serverul fals al lui Ion? În cazul acesta Ion ar fi putut genera cheia sa privată pentru a cripta mesajul “noroc” şi păcăli browser-ul Mariei că PC-ul lui este banca. Nu e bine!
Pentru aceasta, comunicare prin SSL dintre Client şi Server nu se rezumă doar la cheia publică. Cheia publică face parte dintr-un certificat SSL, emis de către o companie autorizată, în care browser-ul Mariei are încredere. După instalarea browser-ului pe calculatorul Mariei acesta deja conţine cheile publice a diverse companii autorizate ca GoDaddy, VeriSign şi Thawte ce emit certificate SSL. Companiile care doresc să deţină o conexiune securizată cu clienţii trebuie să cumpere un certificat SSL de la una dintre companiile autorizate de mai sus.
Certificatul SSL se compune din cheia publică a băncii şi un bloc de date ce pot identifica banca, criptate cu cheia privată a emiţătorului de certificate.
Certificatul SSL se compune din cheia publică a băncii şi un bloc de date ce pot identifica banca, criptate cu cheia privată a emiţătorului de certificate.
Când serverul băncii trimite certificatul spre browser-ul Mariei, acesta decriptează certificatul cu cheia publică a emiţătorului de certificate. Dacă certificatul este fals – decriptarea eşuiază. Dacă certificatul este valid – în datele decriptate apare cheia publică a băncii şi informaţia despre bancă. Dacă prin informaţia despre bancă nu e inclusă şi adresa băncii (www.bancamariei.ro) - Maria primeşte un mesaj de eroare şi conecţiunea se întrerupe.
Să ne întoarcem la Ion. Poate acesta să se dea drept Bancamariei? Nu, deoarece nu are cheia privată a emiţătorului de certificate pentru a cripta certificatul SSL.
După verificarea certificatului, comunicare dintre Maria şi bancă poate continua.
După verificarea certificatului, comunicare dintre Maria şi bancă poate continua.
După Handshake: criptare simetrică chei
Browser-ul Mariei şi serverul băncii ar putea comunica şi mai departe prin schimb de certificate, însă aceasta necesită prea multe calcule şi resurse pe serverul băncii şi ar putea încetini mult conecţiunea cu banca la un moment dat dacă sunt logaţi prea mulţi clienţi simultan.
Pentru aceasta browser-ul Mariei, după ce a verificat identitatea băncii, transmite băncii o cheie de criptare “simetrică” (pe care o va folosi şi Clientul şi Serverul de acum încolo) şi un algoritm nou de criptare serverului. Această modalitate de criptare este mai simplă şi va cripta datele mult mai uşor pe tot parcursul comunicării Client – Server.
Dar ce face Ion? El poate vedea cheia “simetrică” şi tipul algoritmului transmis către server de către browser-ul Mariei? Da, însă cheia “simetrică” încă este criptată cu cheia publică a băncii şi nu poate fi decriptată decât de către bancă cu cheia sa privată.
Dar ce face Ion? El poate vedea cheia “simetrică” şi tipul algoritmului transmis către server de către browser-ul Mariei? Da, însă cheia “simetrică” încă este criptată cu cheia publică a băncii şi nu poate fi decriptată decât de către bancă cu cheia sa privată.
Acum Maria şi banca comunică cu ajutorul unei chei simetrice pe care o cunosc numai ei. Această cheie se mai numeşte “master secret”.
Tot procesul de autentificare şi comunicare este schiţat în imaginea de mai jos (click pentru a o mări):
Apache şi OpenSSL
Pentru Apache se poate instala modulul OpenSSL care funcţionează fără a cumpăra neapărat un certificat SSL. Cu OpenSSL se pot genera certificate proprii, însă, aceste certificate nu sunt autorizate de nici o companie. În acest caz browser-ul clientului îl va întreba pe acesta dacă vrea sau nu să accepte un certificat de comunicare ne semnat de o companie autorizată. Clientul ar putea renunţa la vizitarea paginii dacă nu cunoaşte deţinătorul certificatului.
Resurse SSL
http://www.debianadmin.com/install-and-configure-apache2-with-php5-and-ssl-support-in-debian-etch.html
De aici se pot cumpăra certificate SSL:
Postări
