Ce este SLT, savepearlharbor

Informații generale despre TLS

După protocolul SSL a fost standardizat de IETF (Internet Engineering Task Force), a fost redenumit ca TLS. Prin urmare, deși numele SSL și TLS sunt interschimbabile, acestea sunt încă diferite, deoarece fiecare descrie o altă versiune de protocol.

După cum sa menționat deja, TLS a fost proiectat pentru a lucra la TCP, cu toate acestea, pentru a lucra cu protocoale Datagram, cum ar fi UDP (User Datagram Protocol), a fost dezvoltat o versiune specială a TLS, numit DTLS (Datagram Transport Layer Security).

Criptare, autentificare și integritate

Protocolul TLS este destinat să ofere trei servicii pentru toate aplicațiile care rulează pe el, și anume, criptare, autentificare și integritate. Punct de vedere tehnic, nu toate trei pot fi folosite, cu toate acestea, în practică, pentru a asigura securitatea, folosiți de obicei toate trei:

Pentru a stabili un canal de date criptografic securizat noduri de conexiune trebuie să cadă de acord asupra metodelor de criptare și cheile. protocolul TLS definesc în mod unic procedura, mai este discutat în paragraful TLS HANDSHAKE. Trebuie remarcat faptul că TLS folosește criptografia cu chei publice, care permite nodurilor să stabilească o cheie de criptare secretă partajată fără nici o cunoaștere prealabilă a reciproc.
Doar în cadrul procedurii TLS, este posibil să se stabilească adevărata identitate atât client și server. De exemplu, clientul poate fi sigur că serverul care furnizează informații privind contul bancar, banca este într-adevăr serverul. În schimb, serverul companiei poate fi sigur că clientul este conectat la acesta - a fost un angajat, nu o entitate terță parte (acest mecanism se numește lanț de încredere și vor fi discutate în secțiunea relevantă).

În cele din urmă, TLS asigură trimiterea fiecărui mesaj cu codul MAC (Message Cod de autentificare), creând un algoritm care - un one-way funcție hash criptografice (de fapt - o sumă de control), cheile care sunt cunoscute atât participanți de comunicare. De fiecare dată când trimiteți un mesaj, generat de MAC-valoare, care pot fi generate și receptor, asigură integritatea informațiilor și protecția împotriva spoofing.

Astfel, pe scurt considerat toate cele trei mecanisme care stau la baza TLS kriptobezopasnosti protocol.

TSL Handshake

Înainte de a începe schimbul de date prin intermediul TLS, clientul și serverul trebuie să cadă de acord asupra parametrilor de conexiune, și anume: versiunea de protocol utilizată, metoda de criptare, și să verifice certificatele, dacă este necesar. Schema începe compus numit TLS HANDSHAKE și prezentat mai jos:

Să examinăm în detaliu fiecare pas al procedurii:

Deoarece TLS rulează peste TCP, TCP-conexiune este setat să pornească între client și server.
După instalarea TCP, clientul trimite la caietul de sarcini de server în text simplu (de exemplu, versiunea de protocol, pe care el vrea să folosească metodele de criptare suportate, etc).
Serverul menține versiune a protocolului utilizat, selectați o metodă de criptare din lista furnizată, se atașează certificatul său, și trimite răspunsul la client (dacă se dorește, serverul poate solicita, de asemenea, un certificat de client).
de protocol și o versiune metodă de criptare în acest moment sunt considerate ca fiind aprobate, controalele client certificat trimise și inițiază fie RSA, sau schimbul de chei Diffie-Hellman, în funcție de setările.
Serverul procesează clientul pentru a trimite un mesaj, verifică MAC, și trimite clientului un mesaj final ( „terminat“) la client într-un format criptat.
Clientul decriptează mesajul primit, verifică MAC, și dacă totul este bine, atunci este stabilită conexiunea și începe schimbul de date de aplicație.

Este clar că stabilirea unei conexiuni TLS, în procesul de consumatoare generală, de lungă durată și de timp, astfel încât în standardul TLS, există câteva optimizări. În special, există o procedură numită „strângere de mână abreviat“, care permite utilizarea parametrilor convenite anterior pentru reducerea compusului (desigur, în cazul în care clientul și serverul este stabilit TLS-conexiune în trecut). Această procedură este discutată în detaliu în secțiunea „Reluarea sesiunii“.

De asemenea, există o extindere suplimentară a procedurii Handshake, care se numește TLS Start fals. Această extensie permite clientului și server pentru a începe schimbul de date criptate imediat după stabilirea metodei de criptare, care reduce mesajele de configurare a conexiunii per iterație. Acest lucru a fost spus în detaliu în paragraful „Start fals TLS“.

Protocol Key Exchange TLS

Din diferite motive istorice și comerciale, cel mai des utilizate în algoritmul de schimb al cheii TLS RSA: Clientul generează o cheie simetrică, criptează cu cheia publica a serverului si trimite-l la server. La rândul său, serverul pe cheia clientului este decriptate folosind cheia privată. După aceea, schimbul cheie este declarat finalizat. Acest algoritm are un dezavantaj: este o pereche de chei Open-privat este utilizat pentru a autentifica serverul. Prin urmare, în cazul în care un atacator obține acces la cheia privată a serverului, acesta poate decripta întreaga sesiune. Mai mult decât atât, atacatorul poate pur și simplu scrie întreaga sesiune este criptată versiune și apoi să ia o transcriere, atunci când posibilitatea de a obține cheia privată a serverului. În același timp, schimbul de chei Diffie-Hellman este mai protejat, astfel cum este cheia simetrică nu părăsește niciodată client sau server și, prin urmare, nu pot fi interceptate de către un atacator, chiar dacă el cunoaște cheia privată a serverului. Acest serviciu se bazează pe reducerea riscului de a compromite sesiunile anterioare: crearea unui nou una pentru fiecare sesiune nouă, așa-numitul „temporară“ cheie simetrică. Prin urmare, chiar și în cel mai rău caz (dacă un adversar cunoaște cheia privată a serverului), atacatorul poate primi doar cheile de la sesiunile viitoare, dar nu decripta înregistrate anterior.

În acest moment, toate browserele atunci când instalați conexiunile TLS dau preferință unei combinații de Diffie-Hellman, și utilizarea de chei temporare pentru a crește securitatea.

Trebuie remarcat din nou că cheia de criptare publică este utilizată numai în procedura TLS în timpul configurării inițiale a conexiunii. După configurarea tunelului vine în criptografie simetrică, și de comunicare în cadrul sesiunii curente sunt criptate chei simetrice instalate. Este necesar să se mărească viteza, ca criptografia cu chei publice necesită mult mai multă putere de procesare.

Reluarea unei sesiuni TLS

Așa cum am menționat anterior, procedura completă TLS este destul de consumatoare de timp și costisitoare din punct de vedere al costurilor de calcul. Prin urmare, a fost dezvoltat o procedură care vă permite să-și reia legătura întreruptă anterior, pe baza datelor deja configurate.

Având în vedere că prima versiune publică a protocolului (SSL 2.0), serverul în TLS (și anume raportul inițial ServerHello) poate genera și trimite un identificator de sesiune de 32-byte. Desigur, în acest caz, serverul stochează cache-ul de identificare și parametrii de sesiune generate pentru fiecare client. La rândul său, magazinele client identificatorul său trimis și-l includ (desigur, în cazul în care există) la mesajul original ClientHello. În cazul în care atât clientul, cât și serverul au ID-uri de sesiune identice, instalarea unei conexiuni comune are loc în baza unui algoritm simplificat prezentat în figură. Dacă nu, este nevoie de versiunea completă a TLS.

Procedura pentru reluarea sesiunii vă permite să săriți peste etapa de generare a unei chei simetrice, care îmbunătățește foarte mult conexiunea timpului de instalare, dar nu afectează siguranța sa, așa cum este utilizat datele neskomprometirovannye anterior din sesiunea anterioară.

Cu toate acestea, există o limitare practică: deoarece serverul trebuie să stocheze date cu privire la toate sesiunile deschise, acest lucru duce la o problemă cu resurse populare, care sunt solicitate în același timp mii și milioane de clienți.
Pentru a rezolva această problemă a fost dezvoltat mecanismul de «Sesiunea de bilete», care elimină necesitatea de a stoca date pentru fiecare client pe server. În cazul în care clientul în timpul conexiunii inițiale de instalare a subliniat că susține această tehnologie, serverul în timpul TLS trimite clientului o asa-numita Sesiunea de bilete - parametrii de sesiune, cheia privată de server criptat. Data viitoare reluarea sesiunii, clientul trimite cu ClientHello disponibile a sesiunii de bilete. Astfel, serverul este exonerat de necesitatea de a stoca date pentru fiecare conexiune, dar conexiunea este încă în siguranță, ca tichetul Session este criptat cu o cheie cunoscută numai la server.

TSL Start fals

Sesiunea de tehnologie de protocol reluarea crește, fără îndoială, productivitatea și reduce costurile de calcul, dar nu este aplicabilă în conexiunea inițială la server, sau în cazul în care sesiunea anterioară a expirat.
TLS Tehnologia False Start Pentru chiar mai mare performanta a fost dezvoltat este un protocol de extensie opțional, și vă permite să trimiteți date atunci când TLS finalizat doar parțial. schema de start fals detaliate TLS este prezentat mai jos:

Este important de notat faptul că TLS Start fals nu se schimba procedura TLS. Aceasta se bazează pe presupunerea că în momentul în care clientul și serverul este deja conștient de parametrii de conectare și cheile simetrice, datele aplicației să fi fost deja trimise, precum și toate verificările necesare pot fi efectuate în paralel. Ca rezultat, conexiunea este gata de a utiliza o iterație de mesaje înainte.

TLS lanț de încredere

Autentificarea este o parte integrantă a fiecărei conexiuni TLS. Luați în considerare cel mai simplu proces de autentificare între Alice și Bob:

Atât Alice si Bob genera propriile lor chei publice și private.
Alice si Bob face schimb de chei publice.
Alice generează un mesaj, criptează cu cheia ei privată și trimite-l la Bob.
Bob a primit de la Alice foloseste cheia pentru a decripta mesajul și, astfel, valideaza mesajul primit.

Este clar că sistemul este construit pe încredere între Alice și Bob. Se presupune că schimbul de chei publice a avut loc, de exemplu, în persoană, și, prin urmare, Alice sigur pentru a obține cheia direct de la Bob și Bob, la rândul său, este sigur pentru a obține cheia publică a lui Alice.

Să presupunem acum că Alice primește un mesaj de la Charlie, cu care ea nu este familiar, dar care pretinde a fi prieteni cu Bob. Pentru a dovedi aceasta, Charlie a cerut în avans pentru a semna cheia publică propriul închis cheia publică a lui Bob, și atașează semnătura la mesajul lui Alice. Alice primele verificări semnătura lui Bob pe tasta Charlie (este capabil să facă, deoarece cheia publică a lui Bob să-l este deja cunoscut), este convins că Charlie este într-adevăr prietenul lui Bob, luând mesajul său și efectuează deja cunoscute controale de integritate, asigurându-vă că mesajul este într-adevăr de la Charlie :

Descrise în paragraful precedent este crearea unui „lanț de încredere“ (sau «lanț de încredere», dacă este în limba engleză).
În TLS, lanțul de încredere se bazează pe certificatele de autenticitate prevăzute de organismele speciale, numite autorități de certificare (CA - autorități de certificare). CAs Verificați și, dacă a fost emis, un certificat este compromis, certificatul este revocat.

Dintre certificatele emise este format deja considerat un lanț de încredere. Rădăcina este așa-numitul „certificat CA Root“ - un certificat semnat de un centru important, credibilitatea, care este de necontestat. În general, lanțul de încredere arată astfel:

Desigur, există cazuri când este necesar să se retragă certificatul eliberat sau pentru a anula (de exemplu, a fost compromisă cheia privată certificat a fost compromisă sau procedura de certificare întreg). Pentru a face acest lucru, autenticitatea certificatelor conțin instrucțiuni speciale cu privire la verificarea relevanței lor. Prin urmare, atunci când construirea unui lanț de încredere, este necesar să se verifice relevanța fiecărei unități de încredere.

Mecanismul acestui test este simplu și se bazează pe așa-numitul „Lista de revocare certificate» (CRL - «Certificat lista de revocare»). Fiecare din CA are lista, care este o simplă listă de numere de serie ale certificatelor revocate. Prin urmare, orice persoană care dorește să verifice autenticitatea certificatului, încărcați pur și simplu lista și se uită la ea verifică numărul certificatului. Dacă numărul este găsit - acest lucru înseamnă că certificatul este revocat.

Aici este evident există unele iraționalitate tehnică: pentru a verifica este necesar doar un singur certificat pentru a interoga întreaga listă de certificate revocate, ceea ce atrage după sine încetinirea. Pentru a combate acest mecanism a fost dezvoltat sub numele de „Certificatul Protocol de stare» (OCSP - Certificat Stare Protocol). Acesta permite verificarea stării certificatelor dinamic. Desigur, acest lucru reduce sarcina pe banda de rețea, dar în același timp dă naștere la mai multe probleme:

CAs trebuie să facă față cu sarcina în timp real;
CAs trebuie să asigure disponibilitatea acestora în orice moment;
Datorită în timp real interogări primesc informații despre CAs ce site-uri sunt vizitate de fiecare utilizator.

De fapt, în toate browserele moderne, ambele soluții (OCSP și CRL) se completează reciproc, în plus, de regulă, puteți seta starea preferată a politicii de validare certificat.

Astfel, acest articol se ocupă cu toate instrumentele-cheie oferite de protocolul TLS pentru a proteja datele. Pentru unii gag în Article'm pare rău, acesta costă scopul inițial al traducerii.

anterior ◈ următoarea