Te-ai întrebat vreodată care e diferența între comunicarea HTTP și HTTPS?

Multă lume face confuzii când vine vorba de acest concept și consideră de exemplu că dacă un site funcționează pe HTTPS, datele provenite din descărcarea de fișiere de pe site-ul respectiv sunt verificate de viruși sau alte forme de malware.

Total greșit, comunicarea prin HTTPS doar asigură secretizarea datelor transmise.

Iată cum face asta.

Ce trebuie să știi în primul rând e că toată comunicarea HTTPS se realizează printr-un protocol denumit TLS - Transport Layer Security, care a înlocuit bătrânul SSL (Secure Socket Layer), despre care e posibil să mai auzi, pentru că cei 2 sunt folosiți interschimbabil, dar nu sunt chiar unul și același lucru.

Clientul (de exemplu browser-ul) începe tot acest proces prin transmiterea unui mesaj serverului care urmează să fie accesat.

Schema TLS Handshake

1. Client Hello

Mesaj care poartă denumirea de “Client Hello”.

Prin intermediul acestui mesaj, clientul trimite de asemenea și versiunile de TLS pe care clientul le suportă cât și o secvență de caractere aleatorii care poartă denumirea de “Client Random”.

Versiunile de TLS reprezintă colecții de algoritmi care pot fi folosiți pentru encriptare.

2. Server Hello

Serverul răspunde la acest mesaj printr-un similar “Server Hello”.

Mesaj care conține la rândul lui o altă secvență de caractere aleatorii care de data asta poartă denumirea de “Server Random”, dar și versiunea de TLS aleasă din cele transmise de client ca fiind disponibile, cât și certificatul TLS.

Acest certificat TLS vine împreună cu ceea ce poartă numele de “cheie publică”.

Pe lângă cheia publică, serverul deține și o cheie privată pe care nu o împărtășește cu nimeni. Aceste 2 chei sunt folosite pentru criptare asimetrică, adică ce poate fi criptat cu cheia publică, nu poate fi decriptat decât cu cheia privată.

3. Verificarea certificatului TLS de către client

Certificatul TLS e un soi de semnătură digitală emisă de un al 3-lea actor în tot acest proces, care poartă denumirea de Certificate Authority (sau autoritate emitentă).

Clientul cere verificarea acestui certificat la autoritatea emitentă pentru a se asigura că serverul care răspunde este exact cel al domeniului pe care clientul încearcă să-l acceseze și comunicarea nu a fost interceptată de altcineva care pretinde să fie domeniul vizat.

Pentru că da, există posibilitatea asta, ca tu ca și utilizator să încerci să accesezi un site, să spunem: developmentfactory.ro, dar serverul care să răspundă să fie un impostor care interceptează comunicarea.

Astfel prin verificarea certificatului, se atestă de către o terță parte că a fost emis de către deținătorul domeniului developmentfactory.ro și server-ul care tocmai a răspuns nu este un impostor.

4. Generarea secvenței “premaster secret”

Clientul generează o altă secvență de caractere aleatoare denumită “premaster secret”, pe care o criptează folosind cheia publică din certificat și algoritmul (cipher suite) dedus din versiunea de TLS aleasă în pasul 2 și o trimite către server. Ține minte, doar serverul poate acum să decripteze mesajul ăsta, pentru că deține cheia privată.

5. Generarea cheii de sesiune (session key)

După trimiterea secvenței “premaster secret”, ambele părți vor folosi 3 elemente pentru generarea unei chei de sesiune: client random, server random și premaster secret.

Fiecare parte, atât serverul cât și clientul vor genera cheia de sesiune individual și ar trebui să ajungă la același rezultat.

Începând cu acest pas, toate mesajele transmise de la client la server și invers, vor fi criptate cu această cheie de sesiune, deținută astfel în mod secret în ambele părți.

Comunicarea va trece practic de la criptare asimetrică, așa cum se face inițial, folosind cheile publică/privată ale serverului, la criptare simetrică, însemnând că ambele părți folosesc aceeași cheie pentru criptare și decriptare a mesajelor.

TLS Session Key Generation

Importanța HTTPS

Acum poate te întrebi de ce s-a ajuns la un proces atât de complicat pentru inițializarea procesului de comunicare între un client (sau browser, dar nu obligatoriu) și server.

Ei bine, așa cum ziceam și în introducere HTTPS a apărut cu scopul secretizării datelor transmise.

Gândește-te că în momentul în care te conectezi în contul tău de la bancă, vei trimite de pe PC-ul sau telefonul tău credențialele tale de conectare: user și parolă.

Într-un scenariu non-https, transmiterea acestor date se va face în clar, și oricine interceptează această comunicare îți poate citi atât numele de cont cât și parola folosită fără niciun fel de problemă.

De-asta ideal e să nu mai folosești site-uri sau aplicații web care nu au trecut încă pe HTTPS, decât dacă știi în mod cert că nu vei transmite niciun fel de date sensibile în respectiva interacțiune.

Da, mai sunt încă site-uri care nu folosesc HTTPS sau au certificatele expirate (vezi site-uri ale instituțiilor de stat).

Pentru că acel certificat emis de server are o anume valabilitate, dacă nu este reînnoită, validitatea certificatului nu mai poate fi verificată de către autoritatea emitentă.

Spre norocul nostru, browserele moderne afișează erori extrem de evidente în cazurile astea, ba chiar încearcă să-ți restricționeze accesul atunci când e cazul. Pentru ca tu să fii cât mai puțin expus la astfel de situații.

Dacă vrei să înveți programare și nu știi de unde să începi

C# Masterclass s-ar putea să fie o alegere bună pentru tine. Cursul are peste 30 de ore de conținut și cuprinde toate noțiunile de care are nevoie un începător pentru a-și construi propriile aplicații de la zero, cât și pentru a trece de orice interviu tehnic.