General

SSL (și succesorul său, TLS ) este un protocol care operează direct pe partea de sus a TCP (deși există și implementări pentru protocoale bazate pe datagramă, cum ar fi UDP). În acest fel, protocoalele de pe straturile superioare (cum ar fi HTTP) pot fi lăsate neschimbate în timp ce până la furnizarea unei conexiuni sigure. Sub stratul SSL, HTTP este identic cu HTTPS.

Când utilizați corect SSL / TLS, tot ce poate vedea un atacator pe cablu este IP-ul și portul la care sunteți conectat, aproximativ cât de multe date trimiteți , și ce criptare și compresie sunt utilizate. De asemenea, poate termina conexiunea, dar ambele părți vor ști că conexiunea a fost întreruptă de o terță parte.

În cazul utilizării obișnuite, atacatorul va putea, de asemenea, să-și dea seama la ce nume de gazdă te conectezi (dar nu și restul adresei URL): deși HTTPS în sine nu expune numele gazdei, browserul dvs. va trebui, de obicei, să facă mai întâi o cerere DNS pentru a afla la ce adresă IP să trimiteți solicitarea.

Mare -descrierea la nivel a protocolului

După crearea unei conexiuni TCP, strângerea de mână SSL este pornită de client. Clientul (care poate fi un browser, precum și orice alt program, cum ar fi Windows Update sau PuTTY) trimite o serie de specificații:

• care versiunea SSL / TLS rulează,
• ce ciphersuites vrea să utilizeze și
• ce metode de compresie pe care dorește să le utilizeze.

Serverul identifică cea mai înaltă versiune SSL / TLS acceptată atât de acesta, cât și de client, alege o serie de cifre dintr-una dintre opțiunile clientului (dacă acceptă una) și opțional alege o metodă de compresie.

După aceasta, configurarea de bază este finalizată, serverul trimite certificatul său. Acest certificat trebuie să aibă încredere fie clientul însuși, fie o parte în care clientul are încredere. De exemplu, dacă clientul are încredere în GeoTrust, atunci clientul poate avea încredere în certificatul de la Google.com deoarece GeoTrust semnat criptografic certificatul Google.

După ce a verificat certificatul și este sigur că acest server este cu adevărat cine pretinde că este (și nu un om în mijloc), se schimbă o cheie. Aceasta poate fi o cheie publică, o ” PreMasterSecret ” sau pur și simplu nimic, în funcție de ciphersuite-ul ales. Atât serverul, cât și clientul pot calcula acum cheia pentru criptare simetrică ^{care nu este PKE?} . Clientul îi spune serverului că de acum înainte, toate comunicațiile vor fi criptate, și trimite un mesaj criptat și autentificat către server.

Serverul verifică dacă MAC-ul (utilizat pentru autentificare) este corect și că mesajul poate fi decriptat corect. Apoi returnează un mesaj, pe care clientul îl verifică la fel de bine.

Strângerea de mână este terminată, iar cele două gazde pot comunica în siguranță. Pentru mai multe informații, consultați technet.microsoft.com/en-us/library/cc785811 și en.wikipedia .org / wiki / Secure_Sockets_Layer .

Pentru a închide conexiunea, este utilizată o „alertă” close_notify. Dacă un atacator încearcă să pună capăt conexiunii terminând conexiunea TCP (injectând un pachet FIN), ambele părți vor ști că conexiunea a fost terminată necorespunzător. Cu toate acestea, conexiunea nu poate fi compromisă, ci doar întreruptă.

Mai multe detalii

De ce puteți avea încredere în Google.com, având încredere în GeoTrust?

Un site web dorește să comunice în siguranță cu dvs. Pentru a-și demonstra identitatea și a vă asigura că nu este un atacator, trebuie să aveți cheia publică a serverului „s . Cu toate acestea, cu greu puteți stoca toate cheile din toate site-urile web de pe pământ, baza de date ar fi imensă, iar actualizările ar trebui să ruleze la fiecare oră!

Soluția la aceasta este Autoritățile de certificare sau CA pe scurt.Când ați instalat sistemul de operare sau browserul, probabil că a venit o listă de CA de încredere. Această listă poate fi modificată după bunul plac; puteți să eliminați în cine nu aveți încredere, să adăugați alții sau chiar să vă creați propria CA (deși veți fi singura care are încredere în această CA, deci nu este prea folosită pentru site-ul public). În această listă a CA, cheia publică a CA este, de asemenea, stocată.

Când serverul Google vă trimite certificatul, menționează, de asemenea, că este semnat de GeoTrust. Dacă aveți încredere în GeoTrust, puteți verifica (folosind cheia publică GeoTrust) că GeoTrust a semnat cu adevărat certificatul serverului. Pentru a semna singur un certificat, aveți nevoie de cheia privată, cunoscută doar de GeoTrust. În acest fel, un atacator nu poate semna el însuși un certificat și poate pretinde incorect că este Google.com. Când certificatul a fost modificat cu un singur bit, semnul va fi incorect și clientul îl va respinge.

Deci, dacă știu cheia publică, serverul poate dovediți identitatea?

Da. De obicei, cheia publică criptează și cheia privată decriptează. Criptați un mesaj cu cheia publică a serverului, trimiteți-l și, dacă serverul poate repeta mesajul original, a demonstrat că a primit cheia privată fără a dezvălui cheia.

Acesta este motivul pentru care este atât de important pentru a putea avea încredere în cheia publică: oricine poate genera o pereche de chei private / publice, de asemenea un atacator. Nu doriți să ajungeți să utilizați cheia publică a unui atacator!

Dacă una dintre CA-urile în care ai încredere este compromisă, un atacator poate folosi cheia privată furată pentru a semna un certificat pentru orice site web care le place. Când atacatorul poate trimite un certificat falsificat clientului dvs., semnat de el însuși cu cheia privată de la un CA în care aveți încredere, clientul dvs. nu știe că cheia publică este falsificată, semnată cu o cheie privată furată.

Dar un CA mă poate face să am încredere în orice server doresc!

Da, și de aici vine încrederea inch. Trebuie să aveți încredere în CA să nu facă certificate după bunul plac. Atunci când organizații precum Microsoft, Apple și Mozilla au încredere într-o CA, CA trebuie să aibă audituri; o altă organizație le verifică periodic pentru a se asigura că totul funcționează în continuare conform la reguli.

Eliberarea unui certificat se face dacă și numai dacă solicitantul înregistrării poate dovedi că deține domeniul pentru care este emis certificatul.

Ce este acest MAC pentru autentificarea mesajului?

Fiecare mesaj este semnat cu așa-numitul Cod de autentificare a mesajului sau MAC pe scurt. Dacă suntem de acord cu o cheie și un cifru de hashing, puteți verifica dacă mesajul meu provine de la mine și pot verifica dacă mesajul dvs. provine de la dvs.

De exemplu, cu cheia ” capsă corectă a bateriei calului ” și mesajul ” exemplu „, Pot calcula MAC ” 58393 „. Când vă trimit acest mesaj cu MAC (știți deja cheia), puteți efectua același calcul și potrivi MAC-ul calculat cu MAC-ul pe care l-am trimis.

Un atacator poate modifica mesajul dar nu știe cheia. El nu poate calcula MAC-ul corect și veți ști că mesajul nu este autentic.

Prin includerea unui număr de secvență atunci când calculați MAC-ul, puteți elimina reluarea atacuri . SSL face acest lucru.

Ați spus că clientul trimite o cheie, care este apoi utilizată pentru configurare criptare simetrică. Ce împiedică un atacator să o folosească?

Cheia publică a serverului o face. Deoarece am verificat că cheia publică aparține într-adevăr serverului și nimănui altcuiva, poate cripta cheia utilizând cheia publică. Când serverul primește acest lucru, îl poate decripta cu cheia privată. Când o primește oricine altcineva, nu o poate decripta.

Acesta este și motivul pentru care dimensiunea cheii contează: Cu cât este mai mare cheia publică și cea privată, cu atât este mai greu să sparg cheia pe care clientul o trimite serverului.

Cum se sparge SSL

În rezumat :

• Încercați dacă utilizatorul ignoră avertismentele de certificat;
• Aplicația poate încărca date din un canal necriptat (de exemplu, HTTP), care poate fi modificat;
• O pagină de autentificare neprotejată care se trimite la HTTPS poate fi modificată astfel încât să se trimită la HTTP;
• Aplicațiile neperectate pot fi vulnerabil pentru exploatări precum BEAST și CRIME;
• Recurgeți la alte metode de succes h ca atac fizic;
• Exploatați canale laterale , cum ar fi lungimea mesajului și timpul luat pentru a forma mesajul;
• Așteptați atacuri cuantice .

Vezi și: O schemă cu numeroși vectori de atac împotriva SSL de Ivan Ristic ^(png)

În detaliu:

Nu există elemente simple și directe cale; SSL este sigur când este făcut corect. Un atacator poate încerca dacă utilizatorul ignoră avertismente privind certificatele , ceea ce ar rupe securitatea instantaneu. Când un utilizator face acest lucru, atacatorul nu are nevoie de o cheie privată de la o CA pentru a falsifica un certificat, el trebuie doar să trimită un certificat propriu.

O altă modalitate ar fi printr-un defect în aplicație (partea serverului sau clientului). Un exemplu ușor este în site-urile web: dacă una dintre resursele utilizate de site-ul web (cum ar fi o imagine sau un script) este încărcată prin HTTP, confidențialitatea nu mai poate fi garantată. Chiar dacă browserele nu trimiteți antetul HTTP Referer atunci când solicitați resurse non-securizate dintr-o pagină securizată ( sursă ), este încă posibil ca cineva care ascultă trafic să ghicească unde vă aflați „vizitez din; de exemplu, dacă știu că imaginile X, Y și Z sunt utilizate pe o singură pagină, pot ghici că vizitați acea pagină atunci când văd că browserul solicită aceste trei imagini simultan. În plus, la încărcarea Javascript, întreaga pagină poate fi compromisă. Un atacator poate executa orice script de pe pagină, modificând de exemplu către cine va merge tranzacția bancară.

Când se întâmplă acest lucru (o resursă este încărcată prin HTTP), browserul dă un avertisment cu conținut mixt: Chrome , Firefox , Internet Explorer 9

Un alt truc pentru HTTP este atunci când pagina de conectare nu este securizată și se trimite la o pagină https. ” Excelent, ” probabil că dezvoltatorul a crezut, ” acum salvăm încărcarea serverului și parola este încă trimisă criptată! ” Problema este sslstrip , un instrument care modifică pagina de conectare nesigură, astfel încât trimite undeva, astfel încât atacatorul să-l poată citi.

Au existat și diverse atacuri în ultimii ani, cum ar fi vulnerabilitate la renegocierea TLS , sslsniff , BEAST și foarte recent, INFRACȚIE . Totuși, toate browserele obișnuite sunt protejate împotriva tuturor acestor atacuri, astfel încât aceste vulnerabilități nu prezintă niciun risc dacă rulați un browser actualizat.

Nu în ultimul rând, puteți recurge la alte metode pentru a obține informațiile pe care SSL le refuză să le obțineți. Dacă puteți vedea și manipula deja conexiunea utilizatorului, este posibil să nu fie atât de greu să înlocuiți una dintre descărcările sale .exe cu un keylogger sau pur și simplu să atacați fizic acea persoană. Criptografia poate fi destul de sigură, dar oamenii iar eroarea umană este încă un factor slab. Potrivit acestei lucrări de Verizon , 10% din încălcările de date au implicat atacuri fizice (vezi pagina 3), deci ” Cu siguranță este ceva de reținut.

Comentarii

• Aș fi interesat de o explicație mai mică pentru ” o cheie este schimbată ” pentru cheia simetrică. Cum se întâmplă acest lucru că cineva cu un sniffer de pachete nu poate accesa.
• @Yehosef Întrebare bună! Am uitat să explic asta în răspunsul meu. Privind în jur, se pare că există de fapt o întrebare dedicată acestui lucru: security.stackexchange.com/q/6290/10863
• @ Iwazaru Toate CA fac acest lucru încă din prima zi. Scopul unui certificat este de a furniza cheia publică pentru un anumit domeniu, iar scopul semnării acestuia pentru a dovedi că este cu adevărat cheia potrivită pentru domeniu. Să ‘ s Encrypt face exact ceea ce ar trebui să facă: verificarea deținerii domeniului și semnarea certificatului (cu cheia dvs.) dacă îl puteți dovedi. Acum toți cei care au încredere în Let ‘ s Encrypt, care este practic fiecare browser, vor avea încredere în certificatul respectiv.
• Er, nr. TLS este într-adevăr implementat doar în partea de sus a TCP.
• Am găsit acest proces grafic SSL handshake , foarte clar.

Deoarece conceptul general de SSL a fost deja inclus în alte întrebări (de ex. acesta și acela ), de data aceasta voi merge pentru detalii. Detaliile sunt importante. Acest răspuns va fi oarecum detaliat.

Istoric

SSL este un protocol cu o istorie lungă și mai multe versiuni.Primele prototipuri au venit de la Netscape când dezvoltă primele versiuni ale browserului lor emblematic, Netscape Navigator (acest browser a eliminat Mozaic în primele timpuri ale Războaielor Browserului, care sunt încă în furie, deși cu noi concurenți). Versiunea 1 nu a fost făcută publică niciodată, deci nu știm cum arăta. Versiunea SSL 2 este descrisă într-o schiță care poate fi citită acolo ; are o serie de puncte slabe, unele dintre ele destul de grave, deci este depreciat și implementările SSL / TLS mai noi nu o acceptă (în timp ce mai vechi sunt dezactivate în mod implicit). Nu voi mai vorbi despre versiunea SSL 2, decât ca referință ocazională.

Versiunea 3 SSL (pe care o voi numi „SSLv3”) a fost un protocol îmbunătățit care funcționează și astăzi și este acceptat pe scară largă. Deși este încă o proprietate a Netscape Communications (sau oricine deține acest lucru în prezent), protocolul a fost publicat ca „RFC istoric” ( RFC 6101 ). Între timp, protocolul a fost standardizat, cu un nume nou pentru a evita problemele legale; noul nume este TLS .

Până acum au fost produse trei versiuni ale TLS, fiecare cu RFC dedicat: TLS 1.0 , TLS 1.1 și TLS 1.2 . Sunt foarte asemănătoare între ele și cu SSLv3, până la punctul în care o implementare poate suporta cu ușurință SSLv3 și toate cele trei versiuni TLS, cel puțin 95% din cod fiind comun. Totuși, pe plan intern, toate versiunile sunt desemnate printr-un număr de versiune cu formatul major.minor ; SSLv3 este apoi 3.0, în timp ce versiunile TLS sunt, respectiv, 3.1, 3.2 și 3.3. Astfel, nu este de mirare că TLS 1.0 este uneori numit SSL 3.1 (și nici nu este incorect). SSL 3.0 și TLS 1.0 diferă doar cu câteva detalii minuscule. TLS 1.1 și 1.2 nu sunt încă acceptate pe scară largă, deși există un impuls pentru asta, din cauza unor slăbiciuni posibile (a se vedea mai jos, pentru „atacul BEAST”). SSLv3 și TLS 1.0 sunt acceptate „peste tot” (chiar și IE 6.0 le cunoaște).

Context

SSL urmărește să ofere un tunel bidirecțional sigur pentru date arbitrare. Luați în considerare TCP , protocolul binecunoscut pentru trimiterea de date prin Internet. TCP funcționează prin „pachete” IP și oferă un tunel bidirecțional pentru octeți; funcționează pentru fiecare valoare de octeți și le trimite în două fluxuri care pot funcționa simultan. TCP se ocupă de munca grea de a împărți datele în pachete, de a le recunoaște, de a le reasambla înapoi în ordinea corectă, eliminând în același timp duplicatele și readucând pachetele pierdute. Din punctul de vedere al aplicației care utilizează TCP, există doar două fluxuri, iar pachetele sunt invizibile; în special, fluxurile nu sunt împărțite în „mesaje” (depinde de aplicație să își ia propriile reguli de codificare dacă dorește să aibă mesaje și tocmai asta este HTTP funcționează).

TCP este fiabil în prezența „accidentelor”, adică erori de transmisie datorate hardware-ului descuamat, congestiei rețelei, persoanelor cu smartphone-uri care ies din raza unei stații de bază date. , și alte evenimente non-malitioase. Cu toate acestea, o persoană prost intenționată („atacatorul”) cu un anumit acces la suportul de transport ar putea citi toate datele transmise și / sau le poate modifica în mod intenționat, iar TCP nu protejează împotriva acestora. SSL.

SSL presupune că funcționează pe un protocol asemănător TCP, care oferă un flux fiabil; SSL nu implementează reemiterea pachetelor pierdute și așa ceva. Atacatorul este ar trebui să fie la putere pentru a întrerupe complet comunicarea într-un mod inevitabil (de exemplu, el poate tăia cablurile), așa că treaba SSL este să:

• detectează modificări (atacatorul nu trebuie să poată modifica datele în tăcere );
• asigurați-vă confidențialitatea ( atacatorul nu trebuie să cunoască datele schimbate).

SSL îndeplinește aceste obiective într-o măsură mare (dar nu absolută).

Înregistrări

SSL este stratificat, iar stratul inferior este protocol de înregistrare . Orice date trimise într-un tunel SSL este împărțit în înregistrări . Prin cablu (soclul TCP subiacent sau suportul TCP), o înregistrare arată astfel:

HH V1:V2 L1:L2 data

unde:

• HH este un singur octet care indică tipul de date din înregistrare.Sunt definite patru tipuri: change_cipher_spec (20), alert (21), handshake (22) și application_data ( 23).
• V1: V2 este versiunea protocolului, pe doi octeți. Pentru toate versiunile definite în prezent, V1 are valoarea 0x03, în timp ce V2 are valoarea 0x00 pentru SSLv3, 0x01 pentru TLS 1.0, 0x02 pentru TLS 1.1 și 0x03 pentru TLS 1.2.
• L1: L2 este lungimea data, în octeți (convenția big-endian este folosit: lungimea este de 256 * L1 + L2). Lungimea totală a data nu poate depăși 18432 octeți, dar, în practică, nici măcar nu poate atinge acea valoare.

Deci, o înregistrare are o valoare de cinci- antet de octeți, urmat de cel mult 18 kB de date. data este locul în care se aplică criptarea simetrică și verificările de integritate. Atunci când este emisă o înregistrare, atât expeditorul, cât și destinatarul ar trebui să fie de acord asupra algoritmilor criptografici care se aplică în prezent și cu ce chei; acest acord se obține prin protocolul de strângere de mână, descris în secțiunea următoare. Compresia, dacă există, este aplicată și în acel moment.

În detalii complete, construirea unei înregistrări funcționează astfel:

• Inițial, există câțiva octeți de transferat ; acestea sunt date ale aplicației sau un alt tip de octeți. Această sarcină utilă constă în cel mult 16384 de octeți, dar posibil mai puțin (o sarcină utilă de lungime 0 este legală, dar se pare că Internet Explorer 6.0 nu-i place deloc ) .
• Sarcina utilă este apoi comprimată cu orice algoritm de compresie convenit în prezent. Compresia este de stare și, prin urmare, poate depinde de conținutul înregistrărilor anterioare. În practică, compresia este fie „nulă” (fără compresie deloc), fie „Deflate” ( RFC 3749 ), aceasta din urmă fiind prezentată curent, dar ferm, ieșirea ușă în contextul web, din cauza recentului atac CRIME . Compresia urmărește scurtarea datelor, dar trebuie neapărat să le extindă ușor în unele situații nefavorabile (datorită principiului pigeonhole ). SSL permite o extindere de cel mult 1024 de octeți. Desigur, compresia nulă nu se extinde niciodată (dar niciodată nu se scurtează niciodată); Deflate se va extinde cu cel mult 10 octeți dacă implementarea este bună.
• Sarcina utilă comprimată este apoi protejată împotriva modificărilor și criptată. Dacă algoritmii actuali de criptare și integritate sunt „nuli”, atunci acest pas este lipsit de operațiune. În caz contrar, se adaugă un MAC , apoi unele umpluturi (în funcție de algoritmul de criptare), iar rezultatul este criptat. Acești pași induc din nou o oarecare extindere, pe care standardul SSL o limitează la 1024 de octeți suplimentari (combinată cu expansiunea maximă de la pasul de compresie, aceasta ne aduce la 18432 de octeți, la care trebuie să adăugăm antetul de 5 octeți).

MAC este, de obicei, HMAC cu una dintre funcțiile hash obișnuite (în principal MD5, SHA-1 sau SHA-256) (cu SSLv3, acesta nu este „adevăratul” HMAC ci ceva foarte similar și, din câte știm, la fel de sigur ca HMAC). Criptarea va utiliza fie un cod de bloc în modul CBC , fie cifrul de flux RC4 . Rețineți că, în teorie, ar putea fi utilizate alte tipuri de moduri sau algoritmi, de exemplu, unul dintre aceste moduri inteligente care combină criptarea și verificările de integritate; există chiar unele RFC pentru asta . În practică, însă, implementările implementate nu știu încă de acestea, așa că fac HMAC și CBC. În mod crucial, MAC este mai întâi calculat și adăugat la date, iar rezultatul este criptat. Acesta este MAC-apoi-criptat și de fapt nu este o idee prea bună . MAC-ul este calculat pe concatenarea sarcinii utile (comprimate) și a unui număr de ordine, astfel încât un atacator harnic să nu schimbe înregistrări.

Handshake

handshake este un protocol care este redat în cadrul protocolului de înregistrare. Scopul său este de a stabili algoritmii și cheile care urmează să fie utilizate pentru înregistrări. Este format din mesaje . Fiecare mesaj de strângere de mână începe cu un antet de patru octeți, un octet care descrie tipul mesajului, apoi trei octeți pentru lungimea mesajului (convenție big-endian). Mesajele succesive de strângere de mână sunt apoi trimise cu înregistrări etichetate cu tipul „strângere de mână” (primul octet al antetului fiecărei înregistrări are valoarea 22).

Rețineți straturile: mesajele de strângere de mână, completate cu patru- antetul de octeți, sunt apoi trimise ca înregistrări și fiecare înregistrare și are propriul antet. Mai mult, mai multe mesaje de strângere de mână pot fi trimise în cadrul aceleiași înregistrări, iar un anumit mesaj de strângere de mână poate fi împărțit pe mai multe înregistrări.Din punctul de vedere al modulului care construiește mesajele de strângere de mână, „înregistrările” sunt doar un flux pe care pot fi trimiși octeți; nu este conștient de împărțirea efectivă a fluxului respectiv în înregistrări.

Strângere completă de mână

Inițial, clientul și serverul „sunt de acord” cu criptarea nulă, fără MAC și compresie nulă. Aceasta înseamnă că înregistrarea pe care o vor trimite mai întâi va fi trimisă ca text clar și neprotejat.

Primul mesaj al unei strângeri de mână este un ClientHello. Este mesajul prin care clientul își declară intenția de a face unele SSL. Rețineți că „clientul” este un rol simbolic; înseamnă „petrecerea care vorbește primul”. Se întâmplă că în contextul HTTPS, care este HTTP-în-SSL-în-TCP, toate cele trei straturi au o noțiune de „client” și „server” și toate sunt de acord (clientul TCP este și clientul SSL și clientul HTTP), dar „este o coincidență.

Mesajul ClientHello conține:

• protocolul maxim versiune pe care clientul dorește să o susțină;
• „clientul aleatoriu” (32 de octeți, din care 28 ar trebui să fie generați cu un generator de numere puternic criptografic);
• „ ID-ul sesiunii „(în cazul în care clientul dorește să reia o sesiune printr-o strângere de mână prescurtată, vezi mai jos);
• lista de” suite de cifrare „pe care clientul le cunoaște, ordonată după preferința clientului;
• lista algoritmilor de compresie pe care îi cunoaște clientul, ordonată în funcție de preferința clientului;
• unele extensii opționale.

A cipher suite este un identificator simbolic pe 16 biți pentru un set de criptografi algoritmi c. De exemplu, TLS_RSA_WITH_AES_128_CBC_SHA suita de cifrare are valoarea 0x002F și înseamnă că „înregistrările utilizează criptarea HMAC / SHA-1 și AES cu o cheie de 128 de biți, iar schimbul de chei se face prin criptare o cheie aleatorie cu cheia publică RSA a serverului.

Serverul răspunde la ClientHello cu un ServerHello care conține:

• versiunea de protocol pe care clientul și serverul o vor utiliza ;
• „server aleatoriu” (32 octeți, cu 28 octeți aleatori);
• ID-ul sesiunii pentru această conexiune;
• suita de cifrare care va fi utilizată;
• algoritmul de compresie care va fi utilizat;
• opțional, unele extensii.

Strângerea completă de mână arată astfel:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Această schemă a fost copiat fără rușine din RFC.)

Vedem ClientHello și ServerHello. Apoi, serverul trimite alte câteva mesaje, care depind de suita de cifrare și de un alt parametru rs:

• Certificat: certificatul serverului, care conține cheia sa publică. Mai multe despre asta mai jos. Acest mesaj este trimis aproape întotdeauna, cu excepția cazului în care suita de cifrare impune o strângere de mână fără certificat.
• ServerKeyExchange: câteva valori suplimentare pentru schimbul de chei, dacă ceea ce este în certificat nu este suficient. În special, suitele de cifrare „DHE” utilizează un schimb de chei efemer Diffie-Hellman , care necesită acel mesaj.
• CertificateRequest: un mesaj prin care se solicită ca clientul și să se identifice cu un certificat propriu. Acest mesaj conține lista numelor ancorelor de încredere (denumite și „certificate root”) pe care serverul le va utiliza pentru validarea certificatului client.
• ServerHelloDone: un mesaj de marcare (de lungime zero) care spune că serverul este terminat, iar clientul ar trebui să vorbească acum.

Clientul trebuie apoi să răspundă cu:

• Certificat: certificatul clientului, if serverul a solicitat unul. Există variații subtile între versiuni (cu SSLv3, clientul trebuie să omită acest mesaj dacă nu are un certificat; cu TLS 1.0+, în aceeași situație, trebuie să trimită un Certificate mesaj cu o listă goală de certificate).
• ClientKeyExchange: partea client a schimbului de chei real (de exemplu, unele valori aleatorii criptate cu cheia RSA a serverului).
• CertificateVerify: a semnătură digitală calculată de client peste toate mesajele de strângere de mână anterioare. Acest mesaj este trimis atunci când serverul a solicitat un certificat de client, iar clientul a respectat. Acesta este modul în care clientul demonstrează serverului că într-adevăr „deține” cheia publică care este codificată în certificatul trimis.

Apoi clientul trimite un ChangeCipherSpec mesaj, care nu este un mesaj de strângere de mână: are propriul tip de înregistrare, deci va fi trimis într-o înregistrare proprie.Conținutul său este pur simbolic (un singur octet de valoarea 1). Acest mesaj marchează punctul în care clientul trece la suita și cheile de cifrare nou negociate. Înregistrările ulterioare de la client vor fi apoi criptate.

Mesajul Finalizat este o sumă de verificare criptografică calculată peste toate mesajele de strângere de mână anterioare (atât de la client, cât și de la server). Deoarece este emis după ChangeCipherSpec, este acoperit și de verificarea integrității și de criptare. Când serverul primește acel mesaj și își verifică conținutul, obține o dovadă că într-adevăr a vorbit cu același client tot timpul. Acest mesaj protejează strângerea de mână de modificări (atacatorul nu poate modifica mesajele de strângere de mână și totuși poate primi mesajul Finished corect).

Serverul răspunde în cele din urmă cu propriul său ChangeCipherSpec apoi Finished. În acel moment, strângerea de mână este terminată, iar clientul și serverul pot face schimb de date ale aplicației (în înregistrări criptate etichetate ca atare).

De reținut: clientul sugerează , dar serverul alege . Suita de cifrare este în mâinile serverului. Serverele politicoase ar trebui să urmeze preferințele clientului (dacă este posibil), dar pot face altfel, iar unele chiar o fac (de exemplu, ca parte a protecției împotriva BEAST).

Handshake abreviat

În strângerea de mână completă, serverul trimite un „ID de sesiune” (adică o grămadă de până la 32 de octeți) către client. Mai târziu, clientul se poate întoarce și poate trimite același ID de sesiune ca parte a ClientHello. Aceasta înseamnă că clientul își amintește încă setul de cifre și cheile din strângerea de mână anterioară și ar dori să refolosească acești parametri. Dacă serverul și își amintește suita de cifrare și cheile, atunci copiază ID-ul sesiunii specifice în ServerHello și apoi urmează handshake prescurtat :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Handshake prescurtat este mai scurt: mai puține mesaje, nu afaceri de criptografie asimetrică și, cel mai important, latență redusă . Browserele web și serverele fac asta mult. Un browser Web tipic va deschide o conexiune SSL cu o strângere de mână completă, apoi va face strângeri de mână prescurtate pentru toate celelalte conexiuni la același server: celelalte conexiuni pe care le deschide în paralel, precum și conexiunile ulterioare la același server. Într-adevăr, serverele Web tipice vor închide conexiunile după 15 secunde de inactivitate, dar își vor aminti sesiunile (suita de cifrare și cheile) mult mai mult (posibil ore sau chiar zile).

Schimb de chei

Există mai mulți algoritmi de schimb de chei pe care SSL le poate utiliza. Acest lucru este specificat de suita de cifrare; fiecare algoritm de schimb de chei funcționează cu anumite tipuri de chei publice de server. Cei mai comuni algoritmi de schimb de chei sunt:

• RSA: cheia serverului este de tip RSA. Clientul generează o valoare aleatorie („ secret pre-master „de 48 de octeți, din care 46 sunt aleatorii) și îl criptează cu cheia publică a serverului. Nu există ServerKeyExchange.
• DHE_RSA: cheia serverului este de tip RSA, dar utilizată numai pentru semnătură. Schimbul real de chei folosește Diffie-Hellman. Serverul trimite un mesaj ServerKeyExchange care conține parametrii DH (modul, generator) și o cheie publică DH recent generată; în plus, serverul semnează acest mesaj. Clientul va răspunde cu un mesaj ClientKeyExchange care conține, de asemenea, o cheie publică DH recent generată. DH produce „secretul pre-master” „.
• DHE_DSS: cum ar fi DHE_RSA, dar serverul are o cheie DSS („ DSS ”este, de asemenea, cunoscut ca „DSA” ). DSS este un algoritm numai pentru semnături.

Algoritmii de schimb de chei mai puțin utilizați includ:

• DH: cheia serverului este de tip Diffie-Hellman (vorbim despre un certificat care conține un Tasta DH). Acest lucru a fost „popular” într-un mod administrativ (guvernul federal american a mandatat utilizarea acestuia) când brevetul RSA era încă activ (acest lucru a fost în secolul anterior). În ciuda forței birocratice, nu a fost niciodată la fel de răspândită ca RSA.
• DH_anon: la fel ca suitele DHE, dar fără semnătura de pe server. Aceasta este o suită de cifre fără certificat. Prin construcție, este vulnerabil la atacuri Man-in-the-Middle , astfel foarte rar activat deloc.
• PSK: cheie pre-partajată suite de cifrare. Schimbul de chei numai simetric, bazat pe un secret comun prestabilit.
• SRP: aplicarea protocolului SRP care este un Protocol de autentificare a parolei . Clientul și serverul se autentifică reciproc în ceea ce privește un secret partajat, care poate fi o parolă cu entropie redusă (în timp ce PSK necesită un secret partajat cu entropie ridicată). Foarte ingenios. Nu este încă acceptat pe scară largă.
• O cheie RSA efemeră: cum ar fi DHE, dar cu o pereche de chei RSA recent generată. Deoarece generarea cheilor RSA este costisitoare, aceasta nu este o opțiune populară și a fost specificată doar ca parte a suitelor de cifrare „export” care respectă reglementările de export din criptografie din SUA anterioare anului 2000 (adică chei RSA de cel mult 512 biți). Nimeni nu face asta în zilele noastre.
• Variante ale algoritmilor DH* cu curbe eliptice . Foarte la modă. Ar trebui să devină obișnuit în viitor.

Certificate și autentificare

Certificatele digitale sunt nave pentru chei asimetrice. Acestea sunt destinate să rezolve distribuția cheii. Anume, clientul dorește să utilizeze cheia publică a serverului. Atacatorul va încerca să facă clientul să utilizeze cheia publică atacatorul ”s . Deci, clientul trebuie să aibă o modalitate de a se asigura că folosește cheia potrivită.

SSL ar trebui să utilizeze X.509 . Acesta este un standard pentru certificate. Fiecare certificat este semnat de către o Autoritate de certificare . Ideea este că clientul cunoaște în mod inerent cheile publice ale unei mână de CA (acestea sunt „ancorele de încredere” sau „certificatele rădăcină”). Cu aceste chei, clientul poate verifica semnătura calculată de o CA printr-un certificat care a fost emis către server. Acest proces poate fi extins recursiv: o CA poate emite un certificat pentru o altă CA (adică semnează structura certificatului care conține celălalt nume și cheie ale CA). Un lanț de certificate care începe cu o CA rădăcină și se termină cu certificatul serverului, cu certificate CA intermediare între ele, fiecare certificat fiind semnat relativ la cheia publică care este codificată în certificatul anterior, este numit, fără imagini, un lanț de certificate .

Deci, clientul ar trebui să facă următoarele:

• Obțineți un lanț de certificate care se termină cu certificatul serverului. Mesajul Certificate de pe server ar trebui să conțină, exact, un astfel de lanț.
• Validați lanțul, adică verificând toate semnături și nume și diferiții biți X.509. De asemenea, clientul ar trebui să verifice starea revocării a tuturor certificatelor din lanț, care este complexă și grea (browserele web o fac acum, mai mult sau mai puțin, dar este o dezvoltare recentă).
• Verificați dacă numele serverului intenționat este într-adevăr scris în certificatul serverului. Deoarece clientul nu vrea doar să utilizeze o cheie publică validată, de asemenea, dorește să utilizeze cheia publică a unui anumit server . Consultați RFC 2818 pentru detalii despre cum se face acest lucru într-un context HTTPS .

Modelul de certificare cu certificate X.509 a fost adesea criticat, nu chiar din motive tehnice, ci mai degrabă din motive politico-economice. Acesta concentrează puterea de validare în mâinile câtorva jucători. , care nu sunt neapărat bine intenționați sau cel puțin nu întotdeauna competenți . Din când în când, sunt publicate propuneri pentru alte sisteme (de ex. Convergență sau

După prezentarea lungă a SSL în răspunsul anterior , să mergem cu lucrurile distractive, și anume:

Atacuri pe SSL

Au existat multe atacuri pe SSL, unele bazându-se pe erori de implementare, altele pe adevărate slăbiciuni ale protocolului.

Trebuie să ne amintim că, deși SSL este unul dintre cele mai atacate protocoale (deoarece are un profil foarte ridicat: o aplicație de succes pentru SSL arată foarte frumos în rezumatul unui articol de cercetare), SSL este, de asemenea, unul dintre cele mai reparate protocoale.Acesta trebuie considerat a fi robust tocmai pentru că toate modalitățile cunoscute de a ataca protocoalele de transport au fost încercate pe SSL, iar SSL a fost reparat acolo unde este cazul.

Redarea versiunii

În primele zile ale SSLv3, SSLv2 era încă utilizat pe scară largă și, prin urmare, clienții trimiteau în mod obișnuit compatibil SSLv2 ClientHello mesaje, care pur și simplu indicau că SSLv3 a fost acceptat, de asemenea; serverul ar lua apoi indiciu și va răspunde în dialect SSLv3 + (pentru detalii, consultați Anexa E din RFC 2246 ). Întrucât SSLv2 avea puncte slabe, era în interesul atacatorului să aranjeze ca un client și un server, știind ambele SSLv3, să vorbească totuși folosind SSLv2. Aceasta se numește un atac de revenire la versiune . Conceptul se extinde formal și la versiunile ulterioare.

Au fost adăugate programe pentru a detecta încercările de revenire. Pentru revenirile la back-to-SSLv2, un client care știe SSLv3 + ar trebui să utilizeze o umplutură specială pentru pasul de criptare RSA (SSLv2 acceptă doar schimbul de chei bazat pe RSA): în PKCS # 1 , datele care urmează să fie criptate ar trebui să fie umplute cu un număr de octeți aleatori; un client conștient de SSLv3 ar trebui apoi să seteze fiecare dintre ultimii opt octeți de umplere la valoarea fixă 0x03. Serverul verifică apoi acești octeți; dacă se găsesc cele opt 0x03, atunci este probabil încercată o revenire înapoi, iar serverul respinge încercarea (un client numai SSLv2 are probabilitatea doar 255 ^-8 de a utiliza astfel de octeți de umplere din lipsa pură de noroc, așa că falsurile pozitive apar la o rată neglijabilă).

Pentru reveniri la o versiune veche de SSL / TLS, dar nu mai vechi de SSLv3, a fost adăugat un alt kludge: în secretul pre-master de 48 de octeți pe care clientul le criptează cu cheia RSA a serverului, primii doi octeți nu sunt aleatorii, dar ar trebui să fie egală cu „versiunea de protocol maxim acceptată” pe care clientul a scris-o prima dată în . Din păcate, unii clienți au greșit, iar acest kludge funcționează numai cu un schimb de chei bazat pe RSA, deci protecția împotriva revenirii este foarte limitată acolo. Din fericire, SSLv3 + are o altă protecție mult mai puternică împotriva rollbacks, care înseamnă că mesajele de strângere de mână sunt hash împreună când sunt construite mesajele Finished. protejează împotriva restituirilor, cu excepția cazului în care „vechea versiune” ar fi atât de complet slabă încât atacatorul ar putea rupe total criptarea înainte de sfârșitul strângerii de mână în sine. Acest lucru nu s-a întâmplat încă (SSLv3 este încă rezonabil de robust).

Suite de cifrare slabe

Unele suite standard de cifrare sunt în mod intenționat slabe într-un fel. Există:

• unele suite de cifrare fără criptare deloc, doar verificarea integrității, de ex. TLS_RSA_WITH_NULL_SHA;
• unele suite de cifrare cu criptare pe 40 de biți, cum ar fi TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (suite de cifrare menite să respecte regulile stricte de export din SUA din secolul trecut – aceste reglementări au fost în mare parte ridicate la sfârșitul erei Bill Clinton);
• unele suite de cifrare cu criptare pe 56 de biți, cum ar fi TLS_RSA_WITH_DES_CBC_SHA. DES-ul pe 56 de biți se poate rupe cu tehnologia existentă , dar asta este încă puțin dificil pentru un amator (chiar și un student plictisit cu acces la câteva sute de mașini universitare) ), așa că tind să calific DES-ul pe 56 de biți drept „putere medie”.

Aceasta deschide drumul către o variantă a atacurilor de revenire a versiunii, în care atacatorul forțează clientul și serverul să fie de acord pe o suită de cifrare slabă, ideea fiind că atacatorul modifică lista suitelor de cifrare anunțate de client. Acest lucru este funcțional pentru atacator dacă suita de cifrare selectată este atât de slabă încât o poate rupe pentru a recomputa un aparent corect Finished mesaj. De fapt, MAC-ul utilizat în SSLv3 + (chiar și atunci când se bazează pe MD5) este suficient de robust pentru a preveni acest lucru. Deci, nu există nicio grijă reală aici. De asemenea, părerea mea este că orice slăbiciune reală este aici este atunci când un client sau un server acceptă să folosească deloc o suită de cifrare slabă.

În mod implicit, browserele web moderne nu permit utilizarea unor astfel de suite de cifrare slabă.

Furt de chei private

Dacă o conexiune SSL utilizează schimbul de chei RSA, iar un atacator păstrează o copie a înregistrărilor și apoi mai târziu (eventual luni după aceea, eventual prin inspectarea tuturor copiilor de siguranță de pe discurile sau casetele aruncate) obține o copie a cheii private, atunci el poate dezlega strângerea de mână și decriptarea datelor.

Secretul de transmitere perfectă este despre a contracara acest „mai târziu”. O obțineți utilizând suitele de cifrare DHE. Cu o suită de cifrare DHE, cheia privată reală care ar putea fi utilizată pentru a dezlega strângerea de mână este cheia efemeră Diffie-Hellman, nu cheia privată RSA (sau DSS) a serverului.Fiind efemer, a existat doar în RAM și nu a fost niciodată scris pe hard disk; ca atare, ar trebui să fie mult mai rezistent la furt ulterior.

Deci, lecția este: de regulă, încercați să utilizați o suită de cifrare DHE, dacă este posibil. Ar trebui să vă păstrați în continuare copiile de rezervă și să nu lăsați cheia privată să se scurgă, dar, cel puțin, suitele DHE fac o astfel de scurgere puțin mai mică, mai ales dacă se întâmplă după sfârșitul duratei de viață a cheii (adică certificatul corespunzător nu este valabil mai mult).

Probleme de certificat

Întregul certificat este punct inflamat în SSL.

Din punct de vedere tehnic, SSL este destul de independent de X.509. Lanțurile de certificate sunt schimbate ca bloburi opace. La un moment dat, clientul trebuie să utilizeze cheia publică a serverului, dar clientul este liber să „cunoască” acea cheie în orice mod pe care îl consideră potrivit. În unele scenarii specifice în care poate fi utilizat SSL, clientul cunoaște deja serverul cheia publică (codată în cod) și doar ignoră certificatul trimis de server. Cu toate acestea, în cazul obișnuit al HTTPS, clientul face validarea lanțului de certificate al serverului așa cum este descris în X.509 ( citiți-o în detrimentul sănătății dvs.; ați fost avertizat).

Acest lucru produce un număr de vectori de atac, de exemplu:

• Validarea presupune verificarea faptului că certificatele sunt încă valabile la data curentă. Cum știe computerul client data curentă? Cu ceasul său intern și, eventual, vorbind cu servere NTP (în un mod destul de neprotejat!). Clientul ar putea fi oprit cu câteva minute, ore, zile, chiar și ani (l-am văzut) și, într-o anumită măsură, un atacator puternic l-ar putea forța jucând cu mesaje NTP. Acest lucru ar permite atacatorul să utilizeze certificate învechite care au fost revocate cu ani în urmă. Rețineți un fapt distractiv: SSL „client aleator” și „server aleator” ar trebui să conțină 28 de octeți aleatori și data și ora locală (peste 4 octeți). Această includere de timp a fost menit să facă parte dintr-o soluție împotriva atacurilor bazate pe timp. Nu sunt conștient de nicio implementare care să o verifice cu adevărat.

• Până în 2003, implementarea validării certificatelor în Internet Explorer / Windows nu a procesat extensia „Constrângeri de bază” corect. Efectul net a fost că oricine cu un certificat de 100 EUR ar putea acționa ca CA și ar putea emite „certificate” cu numele și cheile alese în mod arbitrar.

• X .509 include o funcție de limitare a daunelor numită revocare : este vorba despre publicarea unei liste de certificate alungate, care arată bine, criptografic vorbind, dar nu ar trebui să fie de încredere (de exemplu, cheia lor privată a fost furată sau conțin un nume eronat). Revocarea funcționează numai în măsura în care părțile implicate (adică browserele) acceptă descărcarea listelor de revocări gigantice (care pot avea o lungime de câțiva megaocteți!) Sau pentru a contacta serverele OCSP . Browserele moderne o fac acum, dar un pic cu reticență, și mulți vor accepta să se conecteze oricum dacă nu ar putea obține informații despre starea revocării în timp util (deoarece utilizatorul uman nu are răbdare). Situația generală se îmbunătățește de-a lungul anilor, dar destul de încet.

• Unele CA rădăcină au comis unele gafe în trecut (de exemplu, Comodo și DigiNotar). Acest lucru a dus la emiterea de certificate false (numele este www.microsoft.com, dar cheia privată nu este deloc în mâna Microsoft …). Aceste gafe au fost descoperite, iar certificatele au fost revocate, dar încă ridică câteva întrebări incomode (de exemplu, există alte CA care au avut astfel de probleme, dar nu le-au dezvăluit sau, și mai rău, nu le-au observat niciodată?).

X.509 este un ansamblu foarte complex de algoritmi, tehnologii, specificații și comitete și este foarte greu să se înțeleagă. Încercarea de a decoda certificatele X.509 „manual” într-un limbaj de programare neprotejat, cum ar fi C, este o modalitate ușoară de a obține depășiri de tampon.

Atacuri Bleichenbacher

Daniel Bleichenbacher a găsit în 1998 un atac frumos împotriva RSA. Când criptați o bucată de date cu RSA (așa cum se întâmplă pentru mesajul ClientKeyExchange din SSL), datele care urmează să fie criptate trebuie să fie umplute pentru ca pentru a face o secvență de octeți de aceeași lungime ca modulul RSA. Umplerea constă în cea mai mare parte din octeți aleatori, dar există un pic de structură (în special, primii doi octeți după umplere trebuie să fie 0x00 0x02).

După decriptare (pe server, atunci), umplutura trebuie să fie găsit și înlăturat. Se întâmplă că, la acel moment, când serverul a decriptat, dar a obținut o umplere nevalidă (0x00 0x02 octeți nu erau acolo), atunci a raportat-o cu un mesaj de alertă (conform specificației SSL), în timp ce o umplere validă a dus la serverul folosind valoarea aparent decriptată și continuând cu strângerea de mână.

Acest tip de lucru este cunoscut sub numele de oracle padding . Permite unui atacator să trimită o secvență arbitrară de octeți ca și cum ar fi un secret pre-master criptat și să știe dacă decriptarea acelei secvențe ar produce sau nu o umplere validă. Aceasta „este doar o informație de 1 biți, dar este suficient să recuperați cheia privată cu câteva milioane de cereri (cu șiruri„ criptate ”elaborate cu viclenie).

Soluție: atunci când decriptarea are ca rezultat un invalid padding, serverul continuă să folosească un secret aleatoriu de pre-master. Strângerea de mână va eșua ulterior, cu mesajele Finished. Toate implementările actuale ale SSL fac asta.

Oracolul de umplere se oprește

O altă zonă în care a fost găsit un oracol de umplere se află în se înregistrează singuri. Luați în considerare criptarea CBC și HMAC. Datele de criptat sunt mai întâi MAC, apoi rezultatul este criptat. Cu criptarea CBC, datele care trebuie criptate trebuie să aibă o lungime care este un multiplu al dimensiunii blocului (8 octeți pentru 3DES, 16 octeți pentru AES). Deci, se aplică o anumită umplere, cu o anumită structură.

În acel moment (atacul a fost descoperit de Vaudenay în 2002), când o implementare SSL prelucra o recepție înregistrare d, a returnat mesaje de alertă distincte pentru aceste două condiții:

• La decriptare, nu a fost găsită nicio structură de umplere validă.
• La decriptare, a fost găsit un padding valid, dar apoi MAC-ul a fost verificat și nu s-a potrivit.

Acesta este un oracle de padding și care poate fi folosit pentru a recupera unele date criptate. Este nevoie de un atacator activ, dar nu este atât de greu. Vaudenay a implementat-o și a fost extinsă la cazul în care o implementare SSL modificată a returnat același mesaj de alertă în ambele cazuri, dar a durat mai mult pentru a reveni în al doilea caz, din cauza timpului necesar pentru recomputarea MAC (o demonstrație frumoasă a un atac de sincronizare ).

Deoarece oamenii nu învață niciodată, implementarea Microsoft a SSL utilizată în ASP.NET a fost încă neadecvat începând cu 2010 (opt ani mai târziu!), când Rizzo și Duong au reimplementat atacul de la Vaudenay și au construit o demonstrație care a recuperat cookie-uri HTTP.

A se vedea această pagină pentru câteva indicații. Trebuie remarcat faptul că dacă SSL ar fi folosit encrypt-then-MAC , astfel de probleme ar fi fost evitate (înregistrările defecte ar fi fost respinse la nivel MAC, înainte chiar luând în considerare decriptarea).

BEAST

Atacul BEAST este din nou de la Duong și Rizzo și, din nou, este un remake al unui atac mai vechi (de la Philip Rogaway în 2002). Pentru a obține ideea, luați în considerare CBC . În acest mod de funcționare, fiecare bloc de date este mai întâi XORed cu rezultatul criptării blocului anterior; și acesta este rezultatul al XOR care este criptat. Acest lucru se face pentru a „randomiza” blocurile și pentru a evita scurgerile care se găsesc în modul ECB. Deoarece primul bloc nu are un bloc „anterior”, trebuie să existe un Vector de inițializare (IV), care joacă rolul blocului anterior pentru primul bloc.

Se pare că, dacă un atacator poate controla o parte din datele care urmează să fie criptate și, de asemenea, poate prezice IV-ul care va fi utilizat, atunci poate transforma mașina de criptare într-o altă decriptare oracle și utilizați-l pentru a recupera alte date criptate (pe care atacatorul nu le alege). Cu toate acestea, în SSLv3 și TLS 1.0, atacatorul poate prezice IV pentru o înregistrare: este ultimul bloc al înregistrarea anterioară! Așadar, atacatorul trebuie să poată trimite unele date în flux, pentru a „împinge” datele țintă, într-un punct în care implementarea a construit și a trimis înregistrarea anterioară (de obicei, atunci când valorează 16 kB de date au fost acumulate), dar nu au început să construiască următorul.

TLS 1.1+ este protejat împotriva acestui lucru deoarece în TLS 1.1 (și versiunile ulterioare), se utilizează un IV aleatoriu pentru fiecare înregistrare. Pentru SSLv3 și TLS 1.0, o soluție este de a trimite înregistrări de lungime zero: adică înregistrări cu o sarcină utilă de lungime zero – dar cu un MAC și padding și criptare, iar MAC este calculat dintr-o cheie secretă și peste secvență număr, deci acesta joacă rolul unui generator de numere aleatorii. Din păcate, IE 6.0 se sufocă cu înregistrări de lungime zero. Alte strategii implică o împărțire 1 / n-1 (o înregistrare n octeți este trimisă ca două înregistrări, una cu un singur octet de sarcină utilă, cealaltă cu restul n-1 ).

O altă soluție este forțarea utilizării unei suite de cifrare non-CBC atunci când este posibil – serverul selectează o suită de cifrare bazată pe RC4 dacă există una în lista suitelor de cifrare trimise de client, chiar dacă clientul ar fi preferat o suită de cifrare bazată pe CBC. Acest instrument vă poate spune dacă un anumit server acționează așa.(Notă: BEAST este un atac asupra clientului , dar, selectând o suită de cifrare RC4, serverul poate proteja un client neglijent.)

Consultați această pagină pentru câteva indicații. În timp ce TLS 1.1 este din 2006, atacul BEAST poate forța furnizorii de browsere să actualizeze în cele din urmă.

CRIME

La fel ca pentru orice franciză de la Hollywood, Duong și Rizzo au publicat în 2012 continuarea continuării. CRIMENUL exploatează o scurgere care a fost teoretizată cu ani în urmă, dar a fost demonstrată doar în mod clar în demonstrația pe care au publicat-o recent. CRIME exploatează compresia, în aceeași configurare ca și atacul BEAST (atacatorul poate trimite anumite date într-o conexiune SSL, unde sunt trimise și date țintă interesante, cum ar fi un cookie). Aproximativ vorbind, atacatorul pune în datele sale o valoare potențială pentru șirul țintă și, dacă se potrivește, compresia face înregistrările rezultate mai scurte. Consultați această întrebare pentru o analiză (pre-cognitivă).

CRIMENEA este evitată neutilizând deloc compresie la nivel TLS, ceea ce este ce fac browserele acum. Internet Explorer și IIS nu au implementat niciodată compresia la nivel TLS în primul rând (pentru o dată, sloppiness a salvat ziua); Firefox și Chrome l-au implementat și dezactivat în această vară (au fost avertizați de Duong și Rizzo, care sunt destul de responsabili în activitatea lor).

CRIME arată de ce am scris, aproape de începutul Explicații SSL :

SSL îndeplinește aceste obiective într-o măsură mare (dar nu absolută).

Într-adevăr, criptarea scurge lungimea datelor criptate. Nu există o soluție bună cunoscută împotriva acestui lucru. Și numai lungimea poate dezvălui o mulțime de lucruri. De exemplu, atunci când observăm cu un monitor de rețea o conexiune SSL, putem detecta „strângerile de mână suplimentare” din flux (deoarece primul octet al fiecărei înregistrări identifică tipul de date din înregistrare și nu este criptat); cu lungimile înregistrărilor, este destul de ușor să vedeți dacă clientul a furnizat sau nu un certificat.

Poodle

( editați: această secțiune a fost adăugată în 2014-10-15)

Atacul „Pudel” exploatează un defect specific SSL 3.0 cu suite de cifrare bazate pe CBC. Se bazează pe o caracteristică adesea ignorată a SSL 3.0: majoritatea octeților de umplere sunt ignorate. În TLS 1.0, umplutura (octeți adăugați într-o înregistrare pentru a face lungimea compatibilă cu criptarea CBC, care procesează numai blocuri complete) este complet specificată; toți octeții trebuie să aibă o valoare specifică și destinatarul verifică că. În SSL 3.0, conținutul octetului de umplere este ignorat, ceea ce permite unui atacator să efectueze modificări care trec mai mult neobservate. Modificarea afectează doar datele neaplicative, dar poate fi utilizată ca oracol de decriptare într-un mod vag similar cu BEAST.

Mai multe detalii pot fi citite în răspuns .

Viitorul

Oamenii nu învață niciodată. Există multă presiune pentru a adăuga extensii inteligente la SSL din multe motive care arată întotdeauna bine la început, dar care pot induce probleme suplimentare.

Luați în considerare, de exemplu, SSL FalseStart . În principal, este vorba despre faptul că clientul își trimite datele aplicației imediat după ce a trimis mesajul Finished (într-o strângere de mână completă), fără a aștepta Finished mesaj de pe server. Acest lucru reduce latența, care este bună și bine intenționată. Cu toate acestea, schimbă situația de securitate: înainte de a primi mesajul Finished de pe server, acesta din urmă este autentificat doar implicit (clientul nu are încă dovezi că serverul intenționat a fost cu adevărat implicat la toate; știe doar că orice va trimite va putea fi citit doar de serverul dorit). Acest lucru poate avea impact; de exemplu, un atacator ar putea emula serverul până la acel moment și forța, de exemplu, clientul să utilizeze o suită de cifrare bazată pe CBC sau o compresie TLS. Prin urmare, dacă un client implementează FalseStart, atunci scade eficiența măsurilor de protecție împotriva BEAST și CRIME, așa cum ar putea fi aplicat în alt mod de către server.

(Google dezactivat FalseStart în această primăvară, aparent din cauza problemelor de compatibilitate cu unele servere. Oricum, „reducerea latenței cu 30%” părea ciudat, deoarece FalseStart ar avea o anumită influență doar asupra strângerilor de mână complete, nu a strângerilor de mână abreviate, așa că nu ” Nu credeți în aceste pretinse beneficii; nu la această mărime, cel puțin.)

Comentarii

• Cantitatea de efort depus pentru a furniza informații bune prin acest site este cu adevărat nebun și extrem de admirabil. Foarte apreciat.
• Consultați și tools.ietf.org / html / rfc7457