SSL ( Eng. Secure Sockets Layer - nivelul de socket securizate ) este un protocol criptografic care implică o conexiune mai sigură. Utilizează criptografia asimetrică pentru a autentifica cheile de schimb, criptarea simetrică pentru a păstra confidențialitatea, codurile de autentificare a mesajelor pentru integritatea mesajului. Protocolul a fost utilizat pe scară largă pentru mesageria instantanee și voce pe IP ( Voice over IP - VoIP ) în aplicații precum e-mail , Internet fax etc. În 2014, guvernul SUA a raportat o vulnerabilitate în versiunea actuală a protocolului [1] . SSL ar trebui să fie retras în favoarea TLS (consultați CVE-2014-3566).
SSL a fost dezvoltat inițial de Netscape Communications pentru a adăuga protocolul HTTPS browserului lor web Netscape Navigator . Ulterior, pe baza protocolului SSL 3.0, a fost dezvoltat și adoptat standardul RFC , care a primit numele TLS .
Protocolul SSL asigură o comunicare sigură prin următoarele două elemente:
SSL folosește criptografia asimetrică pentru a autentifica cheile de schimb, un cifru simetric pentru a menține confidențialitatea și coduri de autentificare a mesajelor pentru integritatea mesajului.
Protocolul SSL oferă un „canal securizat” care are trei proprietăți principale:
Avantajul SSL este că este independent de protocolul aplicației. Protocoalele aplicației ( HTTP , FTP , TELNET etc.) pot funcționa peste protocolul SSL într-un mod complet transparent, adică SSL poate negocia algoritmul de criptare și cheia de sesiune și poate autentifica serverul înainte ca aplicația să primească sau să transmită primul octet al mesajului.
Protocolul SSL a fost dezvoltat inițial de Netscape Communications . Versiunea 1.0 nu a fost niciodată lansată publicului. Versiunea 2.0 a fost lansată în februarie 1995, dar conținea multe defecte de securitate care au dus la dezvoltarea versiunii SSL 3.0 [2] . Versiunea SSL 3.0, lansată în 1996, a stat la baza creării TLS 1.0, un standard de protocol Internet Engineering Task Force ( IETF ) care a fost definit pentru prima dată în RFC 2246 în ianuarie 1999. Visa , Master Card , American Express și multe alte organizații sunt autorizate să utilizeze protocolul SSL în scopuri comerciale pe Internet. Astfel, SSL este extensibil în conformitate cu proiectul pentru a sprijini compatibilitatea înainte și înapoi și negocierea între conexiunile într-o rețea peer-to-peer. Din martie 2011, conform RFC 6176, clienții TLS nu trebuie să utilizeze protocolul SSL 2.0 atunci când solicită o conexiune la un server, iar serverele trebuie să respingă astfel de solicitări.
TLS 1.0 a fost definit pentru prima dată în RFC 2246 în ianuarie 1999 ca o actualizare la SSL 3.0. După cum se precizează în RFC, „diferențele dintre acest protocol și SSL 3.0 nu sunt critice, dar sunt semnificative pentru apariția incompatibilităților între TLS 1.0 și SSL 3.0”. TLS 1.0 include mijloace prin care implementarea unei conexiuni TLS la SSL 3.0 ar slăbi securitatea.
TLS 1.1 a fost introdus în RFC 4346 în aprilie 2006 [3] . Aceasta a fost o actualizare a TLS versiunea 1.0. Modificările semnificative ale acestei versiuni includ:
TLS 1.2 a fost anunțat în RFC 5246 în august 2008. Se bazează pe versiunea propusă anterior de TLS 1.1.
TLS 1.3 a fost recunoscut ca standard în RFC 8446 în august 2018.
SSL utilizează un mediu cu mai multe straturi pentru a asigura securitatea schimbului de informații. Confidențialitatea comunicării este prezentă datorită faptului că o conexiune securizată este deschisă doar utilizatorilor vizați.
Protocolul SSL se află între două protocoale: protocolul pe care îl folosește programul client (HTTP, FTP, LDAP, TELNET etc.) și protocolul de transport TCP/IP. SSL protejează datele acționând ca un filtru pentru ambele părți și le transmite stratului de transport [4] [5] .
Funcționarea protocolului poate fi împărțită în două niveluri:
Primul strat, la rândul său, este format din trei subprotocoale:
Protocolul de acordare a conexiunii este utilizat pentru a negocia datele de sesiune între client și server. Datele sesiunii includ:
Protocolul de acordare a conexiunii produce un lanț de schimb de date, care, la rândul său, începe autentificarea părților și convine asupra criptării, hashingului și compresiei. Următoarea etapă este autentificarea participanților, care se realizează și prin protocolul de confirmare a conexiunii.
Protocolul de modificare a parametrilor de criptare este utilizat pentru a modifica datele cheii (keyingmaterial) - informații care sunt utilizate pentru a crea chei de criptare. Protocolul constă dintr-un singur mesaj, în care serverul spune că expeditorul dorește să schimbe setul de chei.
Protocolul de avertizare conține un mesaj care indică părților o schimbare a stării sau o posibilă eroare. De obicei, un avertisment este trimis atunci când conexiunea este închisă și este primit un mesaj nevalid, mesajul nu poate fi decriptat sau utilizatorul anulează operațiunea.
Protocolul SSL utilizează certificate pentru a verifica dacă o cheie publică aparține proprietarului său real. Modalități de obținere a unui certificat SSL:
Certificat autosemnat - un certificat creat de utilizatorul însuși - în acest caz, emitentul certificatului este același cu proprietarul certificatului. Un certificat „alb” este un certificat care conține informații fictive folosite ca temporar pentru a configura SSL și a verifica funcționalitatea acestuia într-un mediu dat.
Printre certificatele SSL, există certificate validate pe domeniu și certificate de validare extinsă . Acesta din urmă asociază un nume de domeniu cu o persoană sau entitate reală.
Există 4 algoritmi principali de generare a cheilor: RSA , Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman
rsaCând o cheie RSA privată este „pierdută”, criptoanalistul care o primește are posibilitatea de a decripta toate mesajele trecute și viitoarele înregistrate. Implementarea schimbului de chei în RSA este unidirecțională: toate informațiile necesare pentru a forma o cheie simetrică, care este creată în timpul etapei de strângere de mână, sunt trimise la server și criptate cu cheia publică a serverului. Dezvăluirea cheii private face posibilă aflarea cheii simetrice a acestei sesiuni.
Diffie-HellmanMecanismul Fixed Diffie-Hellman folosește o cheie publică permanentă, care este înregistrată în certificatul serverului. Aceasta înseamnă, de asemenea, că la fiecare nouă conexiune, clientul oferă partea sa din cheie. După schimbul de chei, se formează o nouă cheie simetrică pentru a schimba informații pentru sesiunea curentă. Prin dezvăluirea cheii private a serverului, criptoanalistul poate decripta mesajele înregistrate anterior, precum și toate mesajele viitoare. Acest lucru este posibil de mecanismul în sine. Deoarece criptoanalistul cunoaște cheia privată a serverului, va putea afla cheia simetrică a fiecărei sesiuni și nici măcar faptul că mecanismul de generare a cheii este bidirecțional nu va ajuta.
Mecanismul Anonymous Diffie-Hellman nu oferă garanții de confidențialitate, deoarece datele sunt transmise necriptate.
Singura opțiune care garantează securitatea mesajelor trecute și viitoare este Ephemeral Diffie-Hellman . Diferența față de metodele discutate anterior este că, cu fiecare nouă conexiune, o cheie unică este generată de server și client. Astfel, chiar dacă criptoanalistul obține cheia privată actuală, va putea decripta doar sesiunea curentă, dar nu și sesiunile anterioare sau viitoare.
Există două modalități principale de criptare a datelor: criptare simetrică (cheie secretă partajată) și criptare asimetrică (pereche de chei publice/private).
SSL utilizează atât criptografia asimetrică, cât și simetrică.
Esența criptării asimetrice este că se utilizează o pereche de chei. Una dintre chei se numește publică (de regulă, este publicată în certificatul proprietarului însuși), iar a doua cheie se numește privată - este ținută secretă. Ambele chei sunt folosite în perechi: cheia publică este folosită pentru a cripta datele, iar cheia privată este folosită pentru a le decripta. Această relație vă permite să faceți două lucruri importante.
RSA este unul dintre cei mai folosiți algoritmi de criptare asimetrică.
Cu criptarea simetrică , aceeași cheie este utilizată atât pentru a cripta, cât și pentru a decripta datele. Dacă părțile doresc să facă schimb de mesaje criptate într-un mod sigur, atunci ambele părți trebuie să aibă aceleași chei simetrice. Acest tip de criptare este utilizat pentru cantități mari de date (deoarece criptarea simetrică este mai rapidă). Algoritmii utilizați în mod obișnuit sunt DES , 3-DES , RC2 , RC4 și AES .
Protocolul SSL utilizează criptarea cu chei publice pentru autentificarea reciprocă a clientului și a serverului (folosind tehnologia de semnătură digitală), precum și pentru a genera o cheie de sesiune, care, la rândul său, este utilizată de algoritmi de criptare simetrică mai rapidă pentru a cripta o cantitate mare de date. .
Valoarea hash este un identificator de mesaj, dimensiunea sa este mai mică decât dimensiunea mesajului original. Cei mai faimoși algoritmi hash sunt MD5 (Message Digest 5) care produce o valoare hash de 128 de biți, SHA-1 (Secure Hash Algorithm) care produce o valoare hash de 160 de biți, SHA-2 și SHA-3 . Rezultatul algoritmului de hashing este o valoare care este utilizată pentru a verifica integritatea transferului de date.
Protocolul de la nivelul stratului de înregistrare primește date criptate de la programul client și le transferă la stratul de transport. Protocolul de înregistrare preia datele, le împarte în blocuri și realizează criptarea (decriptarea) datelor. În același timp, informațiile asupra cărora au fost convenite în timpul confirmării datelor sunt utilizate în mod activ.
Protocolul SSL permite criptarea cheilor simetrice folosind fie cifruri bloc, fie cifruri flux . Cifrurile bloc sunt utilizate în mod obișnuit în practică. Principiul de funcționare al unui cifru bloc este de a mapa un bloc de text simplu în același bloc de text cifrat. Acest cifru poate fi reprezentat ca un tabel care conține 2.128 de linii, fiecare linie conținând un bloc de text simplu M și blocul de text cifrat corespunzător C. Există un tabel similar pentru fiecare cheie.
Criptarea poate fi reprezentată ca o funcție
C = E ( Cheie , M ), unde M este datele originale, Cheie este cheia de criptare, C este datele criptate.
De regulă, blocurile sunt mici (de obicei 16 octeți), așa că se pune întrebarea: cum să criptați un mesaj lung?
Primul mod pentru o astfel de criptare se numește ECB (Electronic Codebook) sau modul simplu de înlocuire. Esența sa este că împărțim mesajul original în blocuri (pentru aceiași 16 octeți) și criptăm fiecare bloc separat. Cu toate acestea, acest mod este rar folosit din cauza problemei păstrării caracteristicilor statistice ale textului sursă: 2 blocuri identice de text simplu după criptare se vor transforma în două blocuri identice de text cifrat.
Pentru a rezolva această problemă, a fost dezvoltat un al doilea mod - CBC (Cipher-block chaining). În acest caz, fiecare bloc de text cifrat nou este XORed cu rezultatul de criptare anterior. Primul bloc este XOR cu un vector de inițializare (Initialization Vector, IV). Totuși, toată teoria de mai sus este dezvoltată pentru un singur obiect mare, în timp ce SSL, fiind un protocol criptografic, trebuie să cripteze o serie de pachete. Într-o astfel de situație, există două moduri de a aplica CBC:
La proiectarea aplicațiilor, SSL este implementat „sub” orice alt protocol de nivel de aplicație, cum ar fi HTTP , FTP , SMTP , NNTP și XMPP , oferind astfel „transparență” utilizării acestuia. Din punct de vedere istoric, SSL a fost folosit în principal cu protocoale de transport fiabile, cum ar fi Transmission Control Protocol (TCP). Cu toate acestea, a fost implementat și cu protocoale de transport de datagrame precum User Datagram Protocol (UDP) și Datagram Control Protocol (DCCP), a căror utilizare a fost standardizată, dând naștere termenului Datagram Transport Layer Security (DTLS).
Utilizarea frecventă a protocolului SSL a dus la formarea protocolului HTTPS (Hypertext Transfer Protocol Secure), care acceptă criptarea. Datele care sunt transmise prin protocolul HTTPS sunt „împachetate” în protocolul criptografic SSL sau TLS , asigurând astfel protecția acestor date. Această metodă de protecție este utilizată pe scară largă în lumea Web pentru aplicații în care securitatea conexiunii este importantă, cum ar fi sistemele de plată. Spre deosebire de HTTP , HTTPS este implicit la portul TCP 443.
| Versiunea protocolului | Siguranță | Suport pentru site-ul web |
|---|---|---|
| SSL 2.0 | Nu | 4,9% |
| SSL 3.0 | Nu | 16,6% |
| TLS 1.0 | Poate | 94,7% |
| TLS 1.1 | da | 82,6% |
| TLS 1.2 | 85,5% |
De la începutul lui 2017, toate browserele web majore care acceptă SSL/TLS sunt:
| Browser | Platforme | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|---|
| Chrome 1-21 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) | da | Nu | Nu | Nu |
| Chrome 29-53 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | Da [7] | Da [7] | Da [8] | Nu |
| Chrome 58+ | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | da | da | da | da |
| Firefox 1-27 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Da [9] | Nu [10] | Nu [11] | Nu |
| Firefox 27-53 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | da | da | da | Nu |
| Firefox 54+ | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | da | da | da | da |
| IE6 | Windows XP) | da | Nu | Nu | Nu |
| IE 7 - 8 | Windows (XP, Vista) | da | Nu | Nu | Nu |
| IE 8 - 9 | Windows 7 | da | da | da | Nu |
| IE9 | Windows Vista | da | Nu | Nu | Nu |
| IE 10+ | Ferestre (7, 8) | da | da | da | Nu |
| Muchia 12-15 | Windows 10 | da | da | da | Nu |
| Opera 5-7 | Linux, Mac OS X, Windows | Da [12] | Nu | Nu | Nu |
| Opera 8-9 | Linux, Mac OS X, Windows | da | Da [13] | Nu | Nu |
| Opera 10+ | Linux, Mac OS X, Windows | da | da | da | Nu |
| Opera 44+ | Linux, Mac OS X, Windows | da | da | da | da |
| Safari 4 | Mac OS X, Windows (XP, Vista, 7), iOS 4.0 | da | Nu | Nu | Nu |
| Safari 5 | Mac OS X, Windows (XP, Vista, 7) | da | Nu | Nu | Nu |
| Safari 7-10 | iOS 5.0- | da | da | da | Nu |
Specificații:
Inițial, rețelele private virtuale ( VPN ) bazate pe SSL au fost dezvoltate ca o tehnologie complementară și alternativă de acces la distanță bazată pe VPN IPsec . Cu toate acestea, factori precum fiabilitatea suficientă și costul scăzut au făcut această tehnologie atractivă pentru organizațiile VPN. SSL este, de asemenea, utilizat pe scară largă în e-mail.
Cea mai comună implementare a SSL este pachetul criptografic open source OpenSSL , bazat pe SSLeay scris de Eric Young. Cea mai recentă versiune de OpenSSL acceptă SSLv3. Pachetul este conceput pentru a crea și gestiona diferite tipuri de certificate . Include, de asemenea, o bibliotecă pentru suport SSL de către diverse programe. Biblioteca este utilizată, de exemplu, de modulul SSL din serverul HTTP Apache comun .
Toate datele din SSL sunt trimise sub formă de înregistrări (înregistrări) - obiecte care constau dintr-un antet și o anumită cantitate de date. Fiecare antet de înregistrare conține 2 sau 3 octeți de cod de lungime. Dacă bitul cel mai semnificativ din primul octet al codului de lungime a înregistrării este 1, atunci înregistrarea nu are umplutură și lungimea totală a antetului este de 2 octeți, altfel înregistrarea conține o umplutură și lungimea totală a antetului este de 3 octeți. În cazul unui antet lung (3 octeți), al doilea cel mai semnificativ bit al primului octet are o semnificație specială. Dacă este egală cu 0 - înregistrarea este informațională, dacă este egală cu 1 - înregistrarea este o evadare de securitate. Codul lungimii înregistrării nu include numărul de octeți antet. Pentru un antet de 2 octeți, lungimea acestuia este calculată după cum urmează:
RECORD-LENGTH = ((octet[0] și 0x7F) << 8) | octet[1];
Aici byte[0] este primul octet primit și byte[1] este al doilea octet primit.
Pentru un antet de 3 octeți, lungimea înregistrării este calculată după cum urmează:
RECORD-LENGTH = ((octet[0] și 0x3F) <<8) | octet[1];
IS-ESCAPE = (octet[0] & 0x40) !=0;
PADDING = octet[2];
Valoarea PADDING specifică numărul de octeți adăugați de expeditor în înregistrarea originală. Datele de umplutură sunt utilizate pentru a face ca lungimea înregistrării să fie un multiplu al mărimii blocului de cifrare. Expeditorul adaugă PADDING după datele date și apoi le criptează pe toate, deoarece lungimea acestei matrice este un multiplu al mărimii blocului cifrului utilizat. Deoarece cantitatea de date transmise este cunoscută, antetul mesajului poate fi format ținând cont de cantitatea de PADDING . Destinatarul mesajului decriptează întreg câmpul de date și primește informațiile originale, apoi calculează valoarea reală a RECORD-LENGTH , în timp ce PADDING este eliminat din câmpul „date”.
Partea de date de înregistrare SSL constă din 3 componente:
MAC-DATA - codul de autentificare a mesajului
MAC-SIZE - funcția algoritmului utilizat pentru calcularea sumei hash
ACTUAL-DATA - datele efectiv transmise sau câmpul de date mesaj
PADDING-DATA - PADDING date (cu criptare bloc)
MAC-DATA = HASH [ SECRET , ACTUAL-DATA , PADDING-DATA , SEQUENCE-NUMBER ]
Aici, SECRET este transmis mai întâi funcției hash, urmat de ACTUAL-DATA și PADDING-DATA , urmat de SEQUENCE-NUMBER , un număr de secvență.
Valoarea SECRET depinde de cine trimite mesajul. Dacă clientul o face, atunci SECRET este egal cu CLIENT-WRITE-KEY . Dacă clientul primește mesajul, SECRET este egal cu CLIENT-READ-KEY .
Numărul de secvență este un cod de 32 de biți care este transmis funcției hash ca 4 octeți utilizând ordinea rețelei de la mare la scăzut. Numărul de ordine este contorul pentru server sau client. Pentru fiecare sens de transmisie se foloseste o pereche de contoare - pentru expeditor si pentru destinatar; de fiecare dată când este trimis un mesaj, contorul crește cu 1.
Receptorul mesajului folosește valoarea așteptată a numărului de secvență pentru a trimite MAC (tipul hash este determinat de parametrul CIPHER-CHOICE ). Valoarea MAC-DATA calculată trebuie să se potrivească cu valoarea transmisă. Dacă comparația eșuează, mesajul este considerat corupt, rezultând o eroare care provoacă închiderea conexiunii.
Verificarea finală a potrivirii este efectuată atunci când este utilizat un cifr de bloc. Cantitatea de date din mesaj ( RECORD-LENGTH ) trebuie să fie un multiplu al mărimii blocului de cifrare. Dacă această condiție nu este îndeplinită, mesajul este considerat corupt, rezultând o deconectare.
Pentru un antet de 2 octeți, lungimea maximă a mesajului este de 32767 de octeți, pentru un antet de 3 octeți este de 16383 de octeți. Mesajele de protocol de conversație SSL trebuie să corespundă înregistrărilor unice de protocol SSL, iar mesajele de protocol de aplicație pot ocupa mai multe înregistrări SSL.
Protocolul de conversație SSL conține 2 faze principale.
Faza 1Prima fază este folosită pentru a stabili un canal de comunicare confidențial.
Această fază inițializează conexiunea atunci când ambii colegi fac schimb de mesaje „bună ziua”. Clientul trimite un mesaj CLIENT-HELLO . Serverul primește acest mesaj, îl procesează și trimite înapoi un mesaj SERVER-HELLO .
În acest moment, atât serverul, cât și clientul au suficiente informații pentru a ști dacă este necesară o nouă cheie principală. Dacă cheia nu este necesară, serverul și clientul trec la faza 2.
Când trebuie creată o nouă cheie principală , mesajul SERVER-HELLO al serverului conține deja suficiente date pentru ca clientul să genereze o cheie principală . Aceste date includ certificatul semnat de server, o listă de cifruri de bază și un ID de conexiune (un număr aleatoriu generat de server care este utilizat pe parcursul sesiunii). După ce clientul generează o cheie principală , acesta trimite serverului un mesaj CLIENT-MASTER-KEY sau un mesaj de eroare atunci când clientul și serverul nu se pot pune de acord asupra unui cifr de bază.
După determinarea cheii principale , serverul trimite clientului un mesaj SERVER-VERIFY , care autentifică serverul.
Faza 2 se numește faza de autentificare. Deoarece serverul este deja autentificat în prima fază, clientul este autentificat în a doua fază. Serverul trimite o cerere clientului, iar dacă clientul are informațiile necesare, trimite un răspuns pozitiv, dacă nu, un mesaj de eroare. Când un peer a autentificat un alt peer, acesta trimite un mesaj finalizat . În cazul unui client, mesajul CLIENT-FINISHED conține o formă criptată a CONNECTION-ID pe care serverul trebuie să o verifice. Dacă verificarea nu a reușit, serverul trimite un mesaj de EROARE .
Când unul dintre colegii a trimis un mesaj terminat , trebuie să accepte mesaje până când primește un mesaj finalizat de la celălalt peer și numai atunci când ambii colegi au trimis și primit mesaje terminate se va termina protocolul de conversație SSL. Din acest moment, protocolul de aplicare începe să funcționeze.
Mai jos sunt câteva opțiuni pentru schimbul de mesaje în cadrul protocolului de conversație SSL. Clientul este C , serverul este S. „{smth}key” înseamnă că „smth” este criptat cu o cheie.
În absența unui ID de sesiune| client-bună ziua | C®S: | challenge, cipher_specs |
| server-bună ziua | S ® C: | id-conexiune,certificat_server,specificații_cifrare |
| client-cheie-master | C®S: | {master_key}server_public_key |
| client-finish | C®S: | {connection-id}client_write_key |
| server-verify | S ® C: | {challenge}server_write_key |
| server-finish | S ® C: | {new_session_id}server_write_key |
| client-bună ziua | C®S: | challenge, session_id, cipher_specs |
| server-bună ziua | S ® C: | connection-id, session_id_hit |
| client-finish | C®S: | {connection-id}client_write_key |
| server-verify | S ® C: | {challenge}server_write_key |
| server-finish | S ® C: | {session_id}server_write_key |
| client-bună ziua | C®S: | challenge, session_id, cipher_specs |
| server-bună ziua | S ® C: | connection-id, session_id_hit |
| client-finish | C®S: | {connection-id}client_write_key |
| server-verify | S ® C: | {challenge}server_write_key |
| Cerere-certificat | S ® C: | {auth_type ,challenge'}server_write_key |
| certificat de client | C®S: | {cert_type,client_cert,response_data}client_write_key |
| server-finish | S ® C: | {new_session_id}server_write_key |
SSL acceptă 3 tipuri de autentificare:
Dacă serverul este autentificat, atunci mesajul său de certificare trebuie să furnizeze lanțul de certificare corect care să conducă la un CA acceptabil. Mai simplu spus, serverul autentificat trebuie să furnizeze clientului un certificat valid. Fiecare parte este responsabilă pentru verificarea faptului că certificatul celeilalte părți nu a expirat sau a fost încă revocat. Ori de câte ori serverul se autentifică, canalul este rezistent (securizat) la o încercare de a intercepta date între serverul web și browser, dar o sesiune complet anonimă este în mod inerent vulnerabilă la un astfel de atac. Serverul anonim nu poate autentifica clientul. Scopul principal al procesului de schimb de chei este de a crea un secret client (pre_master_secret) cunoscut doar de client și server. Secretul (pre_master_secret) este folosit pentru a crea secretul partajat (master_secret). Secretul partajat este necesar pentru a crea un mesaj pentru a verifica certificatul, cheile de criptare, secretul MAC (cod de autentificare a mesajului) și mesajul terminat. Prin trimiterea mesajului finalizat, părțile indică faptul că cunosc secretul corect (pre_master_secret).
O sesiune complet anonimă poate fi stabilită utilizând algoritmul RSA sau Diffie-Hellman pentru a genera cheile de schimb. În cazul utilizării RSA , clientul criptează secretul (pre_master_secret) folosind cheia publică a serverului necertificat. Clientul învață cheia publică din mesajul de schimb de chei de la server. Rezultatul este trimis într-un mesaj de schimb de chei de la client. Deoarece interceptorul nu cunoaște cheia privată a serverului, va fi imposibil pentru acesta să decripteze secretul (pre_master_secret). Când se utilizează algoritmul Diffie-Hellman , parametrii publici ai serverului sunt conținuți într-un mesaj de schimb de chei de la server și sunt trimiși către client într-un mesaj de schimb de chei. Un interceptor care nu cunoaște valorile private nu va putea găsi secretul (pre_master_secret).
În acest caz, schimbul de chei și autentificarea serverului pot fi combinate. Cheia publică poate fi, de asemenea, conținută în certificatul serverului sau poate fi utilizată o cheie RSA temporară , care este trimisă în mesajul de schimb de chei de la server. Când este utilizată o cheie RSA temporară, mesajele de schimb sunt semnate de certificatul RSA sau DSS al serverului (???). Semnătura conține valoarea curentă a mesajului Client_Hello.random, astfel încât semnăturile vechi și cheile temporare vechi nu pot fi repetate. Serverul poate folosi cheia temporară RSA o singură dată pentru a crea o sesiune. După verificarea certificatului serverului, clientul criptează secretul (pre_master_secret) folosind cheia publică a serverului. După decodarea cu succes a secretului (pre_master_secret), este generat un mesaj „terminat”, demonstrând astfel serverului că cunoaște cheia privată corespunzătoare certificatului serverului.
Când RSA este utilizat pentru schimbul de chei, mesajul de verificare a certificatului clientului este utilizat pentru autentificarea clientului. Clientul semnează valoarea calculată din master_secret și din toate mesajele de protocol de handshake precedente. Aceste mesaje de strângere de mână conțin un certificat de server care se potrivește cu semnătura serverului cu un mesaj Server_Hello.random care se potrivește cu semnătura mesajului curent de strângere de mână (???).
În acest caz, serverul poate suporta, de asemenea, un algoritm Diffie-Hellman specific pentru parametri sau poate folosi mesaje de schimb de chei de la server pentru a trimite un set de parametri temporari semnat cu certificate DSS sau RSA. Parametrii temporari sunt indexați cu un mesaj hello.random înainte de semnare pentru a preveni un atacator să repete parametrii vechi. În ambele cazuri, clientul poate verifica certificatul sau semnătura pentru a se asigura că parametrii aparțin serverului.
Dacă clientul are un certificat care conține parametrii algoritmului Diffie-Hellman , atunci certificatul conține și informațiile necesare pentru a finaliza schimbul de chei. În acest caz, clientul și serverul vor trebui să genereze aceleași rezultate Diffie-Hellman (pre_master_secret) de fiecare dată când stabilesc o conexiune. Pentru a preveni stocarea secretului (pre_master_secret) în memoria computerului mai mult decât este necesar, secretul ar trebui convertit în secretul partajat (master_secret) cât mai repede posibil. Setările clientului trebuie să fie compatibile cu cele acceptate de server pentru ca schimbul de chei să funcționeze.
Protocolul Record Layer este un protocol stratificat. La fiecare nivel, mesajele includ câmpuri pentru lungime, descriere și validare. Protocolul de scriere primește mesajele care urmează să fie transmise, fragmentează datele în blocuri gestionabile, comprimă inteligent datele folosind un MAC (cod de autentificare a mesajelor), criptează și transmite rezultatul. Decriptează datele primite, verifică, despachetează, colectează și livrează la nivelurile superioare ale clientului.
Există patru protocoale de înregistrare:
Dacă o implementare SSL primește un tip de intrare pe care nu îl cunoaște, atunci acea intrare este pur și simplu ignorată. Orice protocol creat pentru a fi utilizat împreună cu SSL trebuie să fie bine gândit, deoarece va trebui să facă față atacurilor asupra acestuia. Rețineți că, din cauza tipului și lungimii înregistrării, protocolul nu este protejat prin criptare. Trebuie avut grijă pentru a minimiza traficul.
Un client și un server SSL sunt de acord să stabilească o conexiune folosind o procedură de strângere de mână. În timpul strângerii de mână, clientul și serverul convin asupra diferiților parametri care vor fi utilizați pentru a securiza conexiunea:
Acest lucru finalizează strângerea de mână și începe o conexiune sigură, care este criptată și decriptată folosind datele cheii. Dacă oricare dintre cele de mai sus nu reușește, atunci strângerea de mână SSL a eșuat și conexiunea nu este creată.
Există un protocol de modificare a parametrilor de criptare pentru a semnala trecerea la modul de criptare. Protocolul conține un singur mesaj care este criptat și comprimat pe conexiunea stabilită în prezent. Mesajul este format dintr-un singur bit cu valoarea 1.
struct { enum { change_cipher_spec ( 1 ), ( 255 ) } tip ; } ChangeCipherSpec ;Un mesaj de modificare a cifrului este trimis de către client și server pentru a notifica partea care primește faptul că scrierile ulterioare vor fi protejate conform noului CipherSpec și cheilor negociate. Acceptarea acestui mesaj determină receptorul să instruiască stratul de scriere să copieze imediat starea de citire în așteptare în starea de citire curentă. Imediat după trimiterea acestui mesaj, expeditorul trebuie să instruiască stratul de scriere să schimbe modul de scriere înapoi în modul de scriere curent. Mesajul de schimbare a cifrului este trimis în timpul strângerii de mână, după ce parametrii de securitate au fost transferați, dar înainte ca mesajul „terminat” să fie trimis.
Unul dintre tipurile de validare acceptate în protocolul SSL de scriere este protocolul de alarmă. Mesajul de alarmă transmite dificultățile întâlnite în mesaj și o descriere a alarmei. Un mesaj de alarmă de nivel critic întrerupe imediat conexiunea. În acest caz, alte conexiuni corespunzătoare sesiunii pot continua, dar identificatorul de sesiune trebuie invalidat. Ca și alte mesaje, mesajul de alarmă este criptat și comprimat de îndată ce este indicată starea curentă a conexiunii.
Mesajul aplicației de date funcționează la nivel de înregistrare. Este fragmentat, comprimat și criptat pe baza stării curente a conexiunii. Mesajele sunt considerate transparente pentru stratul de înregistrare.
Există o serie de atacuri care pot fi făcute împotriva protocolului SSL. Cu toate acestea, SSL este rezistent la aceste atacuri, cu condiția ca utilizatorul să folosească doar servere de încredere pentru a procesa informații. SSL 2.0 este vulnerabil în unele situații [23] :
SSL 2.0 este dezactivat implicit în browserele care încep cu Internet Explorer 7 [24] , Mozilla Firefox 2 [25] , Opera 9.5 [26] și Safari .
Pe 14 octombrie 2014 a fost identificată o vulnerabilitate CVE-2014-3566, numită POODLE (Padding Oracle On Downgraded Legacy Encryption). Această vulnerabilitate permite unui atacator să efectueze un atac Man-in-the-Middle asupra unei conexiuni criptate folosind SSL 3.0. Vulnerabilitatea POODLE este o vulnerabilitate în protocol și nu în nici una dintre implementările acestuia, astfel încât toate conexiunile criptate cu SSL v3 sunt afectate de aceasta.
Există și alte puncte slabe în SSL 3.0. De exemplu, jumătate din cheia principală care este setată depinde în întregime de funcția hash MD5, care nu este rezistentă la coliziuni și, prin urmare, nu este considerată sigură [27] .
Acest tip de atac este efectuat atunci când atacatorul are o idee despre ce tip de mesaje sunt trimise.
Un criptoanalist poate forma o bază de date în care cheile sunt șiruri de text simplu criptate. Pe baza bazei de date create, puteți determina cheia de sesiune corespunzătoare unui anumit bloc de date.
În general, astfel de atacuri sunt posibile pentru SSL. Dar SSL încearcă să contracareze aceste atacuri folosind chei de sesiune mari - clientul generează o cheie care este mai lungă decât este permisă de restricțiile de export, o parte din care este trimisă la server în text clar, iar restul este combinată cu partea secretă pentru a obține o cheie suficient de lungă (de exemplu, 128 de biți, așa cum este cerut de RC4). Modul de a bloca atacurile de text simplu este de a face cantitatea de text necesară inacceptabil de mare. Fiecare bit adăugat la lungimea cheii de sesiune dublează dimensiunea dicționarului. Folosirea unei chei de sesiune de 128 de biți face ca dimensiunea dicționarului să depășească cu mult posibilitățile tehnice moderne (soluția ar necesita un număr de atomi care nu se găsește în întregul univers). Un alt mod prin care SSL poate contracara acest atac este prin utilizarea lungimii maxime posibile a cheilor (în cazul non-export). Consecința acestui lucru este că cea mai simplă și ieftină metodă de atac este un atac frontal al cheii, dar pentru o cheie de 128 de biți, costul dezvăluirii acesteia poate fi considerat infinit.
Reflection AttackAtacatorul înregistrează sesiunea de comunicare dintre server și client. Mai târziu, încearcă să stabilească o conexiune cu serverul prin redarea mesajelor înregistrate de client. Dar SSL respinge acest atac cu un identificator unic de conexiune (IC) special. Desigur, teoretic, o terță parte nu poate prezice IS deoarece se bazează pe un set de evenimente aleatorii. Cu toate acestea, un atacator cu resurse mari ar putea înregistra un număr mare de sesiuni și ar putea încerca să preia sesiunea „corectă” pe baza nonce -ului pe care serverul l-a trimis în mesajul Server_Hello . Dar non -urile SSL au o lungime de cel puțin 128 de biți, ceea ce înseamnă că un atacator trebuie să scrie 264 de non -uri pentru a avea 50% șanse de a ghici. Dar 2 64 este un număr suficient de mare pentru a face aceste atacuri lipsite de sens.
Atacul protocolului de strângere de mânăUn atacator poate încerca să influențeze schimbul de strângere de mână, astfel încât părțile să aleagă diferiți algoritmi de criptare, și nu pe cei pe care îi aleg de obicei. Deoarece multe implementări acceptă criptarea exportată, iar unele chiar acceptă criptarea 0 sau MAC, aceste atacuri sunt de mare interes.
Pentru un astfel de atac, un atacator trebuie să falsifice rapid unul sau mai multe mesaje de strângere de mână. Dacă se întâmplă acest lucru, clientul și serverul vor calcula diferite valori hash pentru mesajul de strângere de mână. Ca urmare, părțile nu vor accepta mesaje „ terminate ” una de la cealaltă . Fără a cunoaște secretul, atacatorul nu va putea remedia mesajul terminat , astfel încât atacul poate fi detectat.
Hacking conexiuni SSL în interiorul centrului de dateCel mai notoriu incident de piratare în masă a informațiilor protejate prin protocoale SSL a fost efectuat de agenții FBI folosind sistemele Carnivore și NarusInsight , ceea ce a dus la un proces din partea organizației pentru drepturile omului Electronic Frontier Foundation împotriva AT&T, care a instalat aceste complexe pentru a sparge criptografic. informatii protejate.
În ciuda protestului public ridicat din Statele Unite ale acestui caz și a anchetei la nivelul Comitetului Constituțional al Camerei Reprezentanților, nu a existat nicio piratare tehnologică a protocolului SSL de către agenții FBI . Carnivore și NarusInsight au fost instalate chiar în centrul de date , unde existau servere care efectuează conexiuni SSL cu clienți la distanță. NarusInsight a recuperat complet informațiile criptate ascultând nu o conexiune SSL, ci traficul intern între serverele de aplicații din cadrul centrului de date însuși, după ce datele primite prin SSL au fost decriptate chiar de server, care le-a primit de la utilizatori externi.
Totuși, acest incident a arătat că SSL nu poate fi un mijloc de încredere de protecție criptografică a datelor serverului de pe Internet, deoarece serviciile speciale pot instala sisteme de ascultare precum NarusInsight sau SORM-2 [28] în centrul de date. Orice tip de criptografie, care implică faptul că cheile pentru cifruri se află la serverul destinatarului din centrul de date, este spart automat de către sniffer -ii serviciilor de informații prin injectarea lor în destinatar însuși. Mai mult, datele sunt complet reconstruite conform procedurilor care sunt reglementate în prezent și actelor legislative, cum ar fi „ Patriot Act ”. Mai mult, aceste acte legislative interzic, până la urmărirea penală a proprietarilor de centre de date, eliminarea sniffer-urilor serviciului de informații din partea internă a serverelor destinatare. Cu aceste sisteme în vigoare, SSL poate asigura doar o conexiune între doi utilizatori de pe Internet, nu o conexiune SSL la un site Web extern.
Atacul BEASTPe 23 septembrie 2011, cercetătorii thailandezi Duong și Giuliano Rizzo, folosind un applet Java, au demonstrat o „dovadă de concept” numită Beast („Browser Exploit Against SSL/TLS”) indicând o vulnerabilitate în TLS 1.0 [29] [30] . Anterior, această vulnerabilitate, care a fost descoperită inițial de Phillip Rogaway [31] în 2002, era practic imposibil de demonstrat de către cineva. Vulnerabilitatea TLS 1.1 a fost raportată în 2006.
Atacul se bazează pe mai multe ipoteze, dar, după cum s-a dovedit, este foarte posibil să le implementăm. În primul rând, criptoanalistul trebuie să poată intercepta traficul transmis de browser . În al doilea rând, este necesar să forțați cumva utilizatorul să transfere date prin același canal de comunicare securizat . Să se stabilească o conexiune sigură între computerele lui Bob ( B ) și Alice ( A ). Să presupunem că al-lea bloc al mesajului care a venit la noi conține informații secrete (de exemplu, o parolă).
C i = E ( Cheie , M i xor C i-1 ), unde C i este blocul criptat, M i este textul secret
Să presupunem că parola A este P . Putem verifica dacă presupunerea noastră este corectă:
Deci, am reușit să interceptăm vectorul de inițializare, care este folosit pentru a cripta primul bloc al următorului mesaj, dar acesta este și ultimul bloc al mesajului anterior (în formă criptată) - IV . Am interceptat și C i-1 . Folosind aceste date, formăm un mesaj astfel încât primul bloc să devină egal cu următorul:
M1 = C i- 1 xor IV xor P
Dacă criptoanalistul poate transmite mesajul pe același canal securizat, atunci primul bloc al noului mesaj va arăta astfel:
C 1 = E ( Cheie , M 1 xor IV ) = E ( Cheie , ( C i-1 xor IV xor P ) xor P ) xor IV ) = E ( Cheie , ( C i-1 xor P )) = C i
Rezultă că dacă P = M , atunci primul bloc criptat al noului mesaj C 1 va fi egal cu C i interceptat anterior .
În practică, apare o problemă: blocul M are 16 octeți, chiar dacă îi cunoaștem pe toți, cu excepția a doi octeți, avem nevoie de 2-15 încercări pentru a ghici restul. Dacă nu știm nimic?
De aici concluzia că această practică poate funcționa dacă criptoanalistul are un număr limitat de ipoteze despre valoarea lui M , sau mai degrabă majoritatea conținutului acestui bloc. Următoarea presupunere este că criptoanalistul poate controla locația datelor în bloc, de exemplu știind că parola are n caractere. Știind acest lucru, criptoanalistul aranjează parola în așa fel încât doar 1 caracter să intre în primul bloc, iar restul (n-1) în următorul - adică primii 15 octeți conțin date cunoscute. Și pentru a ghici un personaj, un atacator va avea nevoie de 256 de încercări în cel mai rău caz.
Vulnerabilitatea era cunoscută mult mai devreme, dar dezvoltatorii utilitarului sunt primii care au reușit să implementeze toate condițiile pentru acest atac. Și anume:
Iată o listă cu diferite tehnologii și pluginuri de browser care pot efectua injecția de agent în browserul victimei: API-ul Javascript XMLHttpRequest, API-ul HTML5 WebSocket, API-ul Flash URLRequest, API-ul Java Applet URLConnection și API-ul Silverlight WebClient.
Atacul RC4În 2013, a avut loc o conferință în Singapore, unde profesorul Dan Bernstein a prezentat o nouă tehnică de cracare a protocoalelor SSL/TLS folosind cifrul RC4, care a fost propusă în 2011 ca o apărare împotriva BEAST. O vulnerabilitate găsită în RC4 este legată de lipsa aleatoriei în fluxul de biți care a amestecat mesajul. După ce a transmis de mai multe ori același mesaj, a fost dezvăluit un număr suficient de modele repetate pentru a restabili textul original. Pentru un atac, o cantitate imensă de date va trebui să fie condusă prin cifr. În implementarea prezentată, hacking-ul a durat până la 32 de ore, dar posibilitatea de optimizare a procesului nu a fost exclusă. Dar acest atac este greu de implementat în practică. Creatorii susțin că sunt necesare 256 de texte cifrate pentru a recupera 80 de octeți din 256 .
Dezvăluirea cifrurilorDupă cum știți, SSL depinde de diferiți parametri criptografici. Criptarea cheii publice RSA este necesară pentru transferul cheii și autentificarea server/client. Cu toate acestea, diverși algoritmi criptografici sunt utilizați ca cifră. Astfel, dacă se efectuează un atac cu succes asupra acestor algoritmi, atunci SSL nu mai poate fi considerat sigur. Un atac asupra anumitor sesiuni de comunicare se face prin înregistrarea sesiunii, iar apoi, în timp, se selectează cheia de sesiune sau cheia RSA.
Atacul omului din mijlocCunoscut și ca atac MitM (Man-in-the-Middle). Implica participarea a trei părți: serverul, clientul și atacatorul între ele. În această situație, un atacator poate intercepta toate mesajele care urmează în ambele direcții și le poate înlocui. Atacatorul pare să fie serverul clientului și clientul serverului. În cazul schimbului de chei Diffie-Hellman, acest atac este eficient, deoarece integritatea informațiilor primite și sursa acesteia nu pot fi verificate. Cu toate acestea, un astfel de atac nu este posibil folosind protocolul SSL [32] , deoarece certificatele autentificate de o autoritate de certificare [33] sunt folosite pentru autentificarea sursei (de obicei serverul) .
Atacul va avea succes dacă:
Acest tip de atac poate fi găsit în organizațiile mari care folosesc firewall -ul Microsoft Forefront TMG sau serverul proxy Blue Coat Proxy SG . În acest caz, „intrusul” este situat la marginea rețelei organizației și înlocuiește certificatul original cu al său. Acest atac devine posibil datorită capacității de a specifica serverul proxy în sine ca o autoritate de certificare de încredere (fie ca rădăcină, fie ca copil al rădăcinii corporative). De obicei, o astfel de procedură de implementare este transparentă pentru utilizator datorită muncii utilizatorilor corporativi în mediul Active Directory. Acest instrument poate fi folosit atât pentru a controla informațiile transmise, cât și pentru a fura datele personale transmise folosind o conexiune HTTPS securizată.
Cea mai controversată problemă este conștientizarea utilizatorului cu privire la posibilitatea interceptării datelor, deoarece în cazul înlocuirii unui certificat rădăcină nu vor fi afișate mesaje de securitate, iar utilizatorul se va aștepta la confidențialitatea datelor transmise.
În plus, atunci când utilizați Forefront TMG ca proxy SSL, există posibilitatea unui al doilea atac MitM pe partea de Internet, deoarece certificatul original nu va fi transferat utilizatorului, iar Forefront TMG poate fi configurat să accepte și apoi să se înlocuiască pe sine. -certificate semnate sau revocate. Pentru a vă proteja împotriva unui astfel de atac, este necesar să interziceți complet lucrul cu servere web ale căror certificate conțin erori, ceea ce va duce cu siguranță la incapacitatea de a lucra cu protocolul HTTPS cu multe site-uri.
Blue Coat Proxy SG este protejat de al doilea atac MitM: sistemul vă permite să configurați politica astfel încât în cazul unui certificat de server web neîncrezător, sistemul să emită și un certificat semnat nu de un lanț de încredere, ci de un auto temporar. -una semnata.
THC-SSL-DOSPe 24 octombrie 2011, The Hacker's Choice (THC) a lansat utilitarul THC-SSL-DOS, care poate fi folosit pentru a efectua atacuri DoS pe serverele SSL. Acest utilitar exploatează o vulnerabilitate în caracteristica de renegociere SSL, care a fost concepută inițial pentru a face SSL mai sigur. Revalidarea permite serverului să creeze o nouă cheie privată printr-o conexiune SSL existentă. Această caracteristică este activată implicit pe majoritatea serverelor. Stabilirea unei conexiuni securizate, precum și efectuarea revalidării SSL, necesită de câteva ori mai multe resurse pe partea serverului decât pe partea clientului, adică dacă clientul trimite multe cereri de revalidare SSL, acest lucru epuizează resursele de sistem ale serverului.
Potrivit unui participant THC, un atac de succes necesită un laptop cu utilitarul instalat și acces la Internet. Programul a fost publicat în domeniul public, deoarece omologul său a apărut în rețea în urmă cu câteva luni. De asemenea, potrivit dezvoltatorilor, un atac poate fi efectuat chiar dacă serverul nu acceptă funcția de revalidare, deși acest lucru va necesita modificarea metodei de atac. În acest caz, sunt stabilite multe conexiuni TCP pentru noul handshake SSL, dar sunt necesari mai mulți roboți pentru un atac eficient.
Ca o apărare, unii dezvoltatori de software recomandă stabilirea unor reguli specifice pentru a termina o conexiune cu un client care efectuează o operațiune de revalidare de mai mult de un anumit număr de ori pe secundă.
În 2009, la o conferință Black Hat din Washington DC, Moxie Marlinspike, un hacker independent, a demonstrat un nou instrument , SSLstrip, care poate extrage informații importante, păcălindu-i pe utilizatori să creadă că se află pe o pagină securizată atunci când nu sunt. Acest lucru poate fi realizat prin conversia paginilor în mod normal securizate prin SSL în omologii lor nesiguri, înșelând atât serverul, cât și clientul. Utilitarul funcționează deoarece multe site-uri care utilizează protecție SSL au o pagină de pornire nesigură. Ele criptează doar acele secțiuni în care sunt transmise informații importante. Și când utilizatorul face clic pe pagina de autorizare, utilitarul înlocuiește răspunsul site-ului prin schimbarea https în http. SSLstrip folosește următoarele tehnici: în primul rând, în rețeaua locală este instalat un server proxy care are un certificat valid - de aici utilizatorul continuă să vadă https în bara de adrese, în al doilea rând, se folosește o tehnică pentru a crea URL -uri lungi care conțin false '/ ' în bara de adrese - acest lucru este necesar pentru a evita conversia caracterelor de către browsere. Pentru a dovedi că sistemul a funcționat, Moxxi a rulat SSLstrip pe un server care deservește rețeaua Tor și, în 24 de ore, a scos 254 de parole de la utilizatorii Yahoo , Gmail , Ticketmaster, PayPal și LinkedIn .
În protocolul SSL, gestionarea erorilor este foarte simplă. Când este detectată o eroare, cel care a descoperit-o trimite un mesaj despre aceasta partenerului său. Erorile fatale necesită ca serverul și clientul să închidă conexiunea [35] . Protocolul SSL definește următoarele erori:
| Protocoale de bază TCP /IP pe straturi ale modelului OSI | |
|---|---|
| Fizic | |
| canalizat | |
| reţea | |
| Transport | |
| sesiune | |
| Reprezentare | |
| Aplicat | |
| Altele aplicate | |
| Lista de porturi TCP și UDP | |
| Mecanisme de securitate pe internet | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Criptare și filtrare a traficului |
| ||||||||||||||
| Autentificare | |||||||||||||||
| Protecția computerului |
| ||||||||||||||
| Securitatea telefoniei IP |
| ||||||||||||||
| Anonimizarea traficului | |||||||||||||||
| Securitate wireless | |||||||||||||||