TLS

TLS ( English  transport layer security  - Transport Layer Security Protocol [1] ), ca și predecesorul său SSL ( English  secure sockets layer  - a layer of secure sockets), sunt protocoale criptografice care asigură transferul securizat de date între nodurile de pe Internet [2] . TLS și SSL utilizează criptarea asimetrică pentru autentificare, criptarea simetrică pentru confidențialitate și coduri de autentificare a mesajelor pentru a păstra integritatea mesajului.

Acest protocol este utilizat pe scară largă în aplicații de internet , cum ar fi browsere web , e- mail , mesagerie instantanee și Voice over IP (VoIP) .

Protocolul TLS se bazează pe specificația protocolului SSL versiunea 3.0 dezvoltată de Netscape Communications [3] . Standardul TLS este acum dezvoltat de IETF . Ultima actualizare a protocolului a fost în RFC 5246 (august 2008) și RFC 6176 (martie 2011).

Descriere

TLS permite aplicațiilor client-server să comunice printr-o rețea în așa fel încât să nu aibă loc sniff-ul de pachete și accesul neautorizat .

Deoarece majoritatea protocoalelor de comunicație pot fi utilizate cu sau fără TLS (sau SSL), atunci când stabiliți o conexiune, trebuie să spuneți în mod explicit serverului dacă clientul dorește să stabilească TLS. Acest lucru poate fi realizat fie prin utilizarea unui număr de port uniform pe care conexiunea este întotdeauna stabilită folosind TLS (cum ar fi portul 443 pentru HTTPS ), fie prin utilizarea unui port personalizat și a unei comenzi speciale de la partea client la server pentru a comuta conexiunea la TLS folosind mecanisme speciale de protocol (cum ar fi STARTTLS pentru protocoalele de e-mail ). Odată ce clientul și serverul au convenit să utilizeze TLS, trebuie să stabilească o conexiune sigură. Acest lucru se face folosind o procedură de strângere de mână [4] [5] . În timpul acestui proces, clientul și serverul convin asupra diferiților parametri necesari pentru a stabili o conexiune sigură.

Principalii pași în procedura de creare a unei sesiuni de comunicare sigură:

Acest lucru completează procesul de strângere de mână. Se stabilește o conexiune securizată între client și server, datele transmise prin aceasta sunt criptate și decriptate folosind un criptosistem simetric până la finalizarea conexiunii.

Dacă întâmpinați probleme cu unii dintre pașii de mai sus, strângerea de mână poate eșua și este posibil să nu fie stabilită o conexiune sigură.

Istoric și versiuni

Protocoale SSL și TLS
Protocol Data publicării Stat
SSL 1.0 nepublicat nepublicat
SSL 2.0 1995 Învechit în 2011 ( RFC 6176 )
SSL 3.0 1996 Învechit în 2015 ( RFC 7568 )
TLS 1.0 1999 Învechit în 2020 [6]
TLS 1.1 2006 Învechit în 2020 [6]
TLS 1.2 2008
TLS 1.3 2018

Primele încercări de implementare a socket-urilor de rețea criptate au fost făcute în 1993 [7] . Protocoalele SSL originale au fost dezvoltate de Netscape: versiunea 1.0 nu a fost publicată din cauza unui număr de neajunsuri, versiunea 2.0 a fost introdusă în 1995 și înlocuită cu versiunea 3.0 în 1996 [8] . SSL 3.0 a fost o revizuire completă a protocolului de către Paul Kocher și colaboratorii Netscape Phil Karlton și Alan Freier, cu contribuția Consensus Development. Versiunile ulterioare de SSL și TLS se bazează pe SSL 3.0. O versiune preliminară a standardului din 1996 a fost publicată ca RFC 6101 de către IETF . Utilizarea SSL 2.0 a fost retrasă în 2011 odată cu lansarea RFC 6176 . În 2014, a fost propus un atac POODLE împotriva cifrurilor bloc SSL 3.0 , iar singurul cifr de flux acceptat, RC4 , a avut alte probleme de securitate pe măsură ce a fost utilizat [9] . În iunie 2015, SSL 3.0 a fost depreciat ( RFC 7568 ).

TLS 1.0 a apărut în 1999 ca o actualizare la SSL 3.0 și este descris în RFC 2246 . În 2018, PCI DSS a îndemnat corporațiile să renunțe la TLS 1.0 [10] , iar în octombrie 2018, cei mai mari jucători de pe piața browserelor și sistemelor de operare ( Apple , Google, Microsoft , Mozilla ) au anunțat că vor înceta să mai accepte versiunile TLS 1.0 și 1.1 în martie 2020 [6] .

TLS 1.1 a fost descris în RFC 4346 în aprilie 2006 [11] . El a adăugat la TLS 1.0 o serie de protecții împotriva atacurilor asupra modurilor de criptare CBC și a erorilor de umplutură cu dimensiunea blocurilor , a început să utilizeze un vector de inițializare explicit și înregistrarea codurilor numerice pentru parametrii în IANA [12] .

TLS 1.2 a apărut în august 2008 ca o actualizare la versiunea 1.1, descrisă în RFC 5246 . Funcțiile hash criptografice învechite MD5 și SHA-1 au fost interzise (înlocuite cu SHA-256), a fost îmbunătățit mecanismul de acordare a listelor de metode acceptate de către părți, au fost introduse metodele AEAD ( GCM și CCM pentru AES ) [13] .

În martie 2011, RFC 6176 a interzis compatibilitatea cu versiunile mai vechi de SSL în toate protocoalele TLS.

Cea mai nouă actualizare a fost TLS 1.3, descrisă în august 2018 în RFC 8446 . Această versiune a separat procesele de acord cheie, autentificare și suită de criptare; curbele eliptice slabe și rare, hashurile MD5 și SHA-224 sunt interzise; introducerea semnăturii digitale obligatorii; implementat HKDF și sistem DH semi-efemer. În locul mecanismului de reînnoire, s-au folosit PSK și sistemul de acreditări, procesele de conectare (1-RTT și 0-RTT) au fost accelerate și s-a postulat secretul perfect înainte pentru cheile de sesiune prin protocoalele de generare DH și ECDH. Opțiuni învechite și nesigure precum compresia datelor , renegocierea, cifrurile fără autentificarea mesajelor (adică modurile non - AEAD ), metode non-secrete pentru obținerea cheilor de sesiune (RSA, DH static, grupuri DHE), mesaje auxiliare (Change Cipher Spec, HELLO , câmpul lungime AD). S-a încheiat compatibilitatea cu SSL sau RC4. Au apărut cifrurile de flux ChaCha20 cu codul MAC Poly1305 , semnături Ed25519 și Ed448, protocoalele de schimb de chei x25519 și x448 .

Suportul pentru TLS 1.3 a apărut în Mozilla Network Security Services (NSS) în februarie 2017 (inclus în Firefox 60) [14] [15] . Google Chrome a suportat TLS 1.3 pentru o vreme în 2017, dar l-a dezactivat în favoarea Blue Coat web prox [16] . OpenSSL a adăugat această versiune în versiunea 1.1.1 din septembrie 2018 [17] . Electronic Frontier Foundation a cerut TLS 1.3 și a avertizat împotriva confuziei cu protocolul cleptografic similar hibrid ETS sau eTLS (a omis în mod intenționat caracteristici importante de securitate din TLS 1.3) [18] .

Securitate

TLS are multe măsuri de securitate:

Vulnerabilitatea protocolului TLS 1.0, care a fost considerat teoretic, a fost demonstrată la conferința Ekoparty din septembrie 2011. Demo-ul a inclus decriptarea cookie -urilor utilizate pentru autentificarea utilizatorului [19] .

O vulnerabilitate în faza de reconectare, descoperită în august 2009, a permis unui criptoanalist capabil să spargă o conexiune https să adauge propriile cereri la mesajele trimise de la client către server [20] . Deoarece criptoanalistul nu poate decripta comunicațiile server-client, acest tip de atac diferă de atacul standard man-in-the-middle . Dacă utilizatorul nu acordă atenție indicației browserului că sesiunea este securizată (de obicei o pictogramă de lacăt), vulnerabilitatea poate fi folosită pentru un atac de tip man-in-the-middle [21] . Pentru a elimina această vulnerabilitate, s-a propus atât pe partea de client, cât și pe partea de server să se adauge informații despre conexiunea anterioară și să se verifice când este reluată conexiunea. Acesta a fost introdus în RFC 5746 și este implementat și în versiunile recente ale OpenSSL [22] și alte biblioteci [23] [24] .

Există, de asemenea, opțiuni de atac bazate direct pe implementarea software a protocolului, și nu pe algoritmul acestuia [25] .

Procedura de strângere de mână în TLS în detaliu

Conform protocolului TLS, aplicațiile fac schimb de înregistrări care încapsulează (stochează în sine) informațiile care trebuie transmise. Fiecare dintre intrările poate fi comprimată, completată, criptată sau identificată printr-un MAC (Message Authentication Code) în funcție de starea curentă a conexiunii (starea protocolului). Fiecare intrare în TLS conține următoarele câmpuri: Tip de conținut (definește tipul de conținut al intrării), Versiune (un câmp care indică versiunea protocolului TLS) și Lungime (un câmp care indică lungimea pachetului).

Când conexiunea tocmai este stabilită, interacțiunea trece prin protocolul de strângere de mână TLS, al cărui tip de conținut este 22.

Strângere de mână simplă în TLS

Următorul este un exemplu simplu de configurare a conexiunii în care serverul (dar nu clientul) este autentificat prin certificatul său.

  1. Faza de negociere:
    • Clientul trimite un mesaj ClientHello care indică cea mai recentă versiune a protocolului TLS acceptat, un număr aleatoriu și o listă de suite de criptare acceptate (metode de criptare, suite de criptare în engleză) potrivite pentru lucrul cu TLS;
    • Serverul răspunde cu un mesaj ServerHello care conține: versiunea protocolului selectată de server, un număr aleator generat de server, o suită de criptare selectată din lista furnizată de client;
    • Serverul trimite un mesaj Certificat care conține certificatul digital al serverului (în funcție de algoritmul de criptare, acest pas poate fi omis);
    • Dacă datele transmise de server nu sunt suficiente pentru a genera o cheie secretă simetrică partajată în cadrul pachetului de criptare selectat, serverul trimite un mesaj ServerKeyExchange care conține datele necesare. De exemplu, în ServerKeyExchange este transmisă partea de server a schimbului pentru protocolul Diffie-Hellman;
    • Serverul trimite un mesaj ServerHelloDone care identifică sfârșitul primei runde de stabilire a conexiunii;
    • Clientul răspunde cu un mesaj ClientKeyExchange care conține partea client a protocolului Diffie-Hellman sau un secret ( PreMasterSecret ) criptat cu cheia publică din certificatul serverului ;
    • Clientul și serverul, folosind cheia PreMasterSecret și numere generate aleatoriu, calculează un secret partajat. Toate celelalte informații cheie de sesiune vor fi derivate din secretul partajat;
  2. Clientul trimite un mesaj ChangeCipherSpec indicând că toate informațiile ulterioare vor fi criptate folosind algoritmul de strângere de mână, folosind secretul partajat. Acesta este un mesaj la nivel de înregistrare și, prin urmare, are tipul 20, nu 22;
    • Clientul trimite un mesaj Finished care conține hash-ul și MAC-ul generat din mesajele anterioare de handshake;
    • Serverul încearcă să decripteze mesajul Terminat al clientului și să verifice hash-ul și MAC. Dacă procesul de decriptare sau verificare eșuează, strângerea de mână este considerată un eșec și conexiunea trebuie încheiată;
  3. Serverul trimite un ChangeCipherSpec și un mesaj criptat Finished, iar clientul face, la rândul său, decriptarea și validarea.

Din acest moment se consideră finalizată confirmarea comunicării, se stabilește protocolul. Tot conținutul pachetului ulterior vine cu tipul 23 și toate datele vor fi criptate.

Strângere de mână cu autentificarea clientului

Acest exemplu arată autentificarea completă a clientului (în plus față de autentificarea serverului ca în exemplul anterior) folosind schimbul de certificate între server și client.

  1. Faza de negociere:
    • Clientul trimite un mesaj ClientHello care indică cea mai recentă versiune a protocolului TLS acceptat, un număr aleatoriu și o listă de metode de criptare și compresie acceptate potrivite pentru lucrul cu TLS;
    • Serverul raspunde cu un mesaj ServerHello care contine: versiunea protocolului aleasa de server, un numar aleator trimis de client, un algoritm de criptare si compresie adecvat din lista furnizata de client;
    • Serverul trimite un mesaj Certificat care conține certificatul digital al serverului (în funcție de algoritmul de criptare, acest pas poate fi omis);
    • Serverul trimite un mesaj CertificateRequest care conține o cerere de certificat de client pentru autentificare reciprocă;
    • Clientul trimite un mesaj de certificat care conține certificatul digital al clientului;
    • Serverul trimite un mesaj ServerHelloDone care identifică sfârșitul strângerii de mână;
    • Clientul răspunde cu un mesaj ClientKeyExchange care conține cheia publică PreMasterSecret sau nimic (din nou depinde de algoritmul de criptare);
    • Clientul și serverul, folosind cheia PreMasterSecret și numere generate aleatoriu, calculează o cheie secretă partajată. Toate celelalte informații despre cheie vor fi obținute din cheia secretă partajată (și valori aleatorii generate de client și server);
  2. Clientul trimite un mesaj ChangeCipherSpec indicând că toate informațiile ulterioare vor fi criptate folosind algoritmul de strângere de mână, folosind secretul partajat. Acestea sunt mesaje la nivel de înregistrare și, prin urmare, sunt de tip 20, nu 22;
    • Clientul trimite un mesaj Finished care conține hash-ul și MAC-ul generat din mesajele anterioare de handshake;
    • Serverul încearcă să decripteze mesajul Terminat al clientului și să verifice hash-ul și MAC. Dacă procesul de decriptare sau verificare eșuează, strângerea de mână este considerată un eșec și conexiunea trebuie încheiată.
  3. Serverul trimite un ChangeCipherSpec și un mesaj criptat Finished, iar clientul face, la rândul său, decriptarea și validarea.

Din acest moment se consideră finalizată confirmarea comunicării, se stabilește protocolul. Tot conținutul pachetului ulterior vine cu tipul 23 și toate datele vor fi criptate.

Reluarea unei conexiuni TLS

Algoritmii de criptare asimetrici utilizați pentru a genera cheia de sesiune sunt de obicei scumpi în ceea ce privește puterea de calcul. Pentru a evita repetarea lor atunci când conexiunea este reluată, TLS creează o etichetă specială de strângere de mână care este utilizată pentru a relua conexiunea. În acest caz, în timpul unei strângeri de mână obișnuite, clientul adaugă la mesajul ClientHello identificatorul sesiunii anterioare . Clientul asociază id-ul de sesiune cu adresa IP a serverului și portul TCP, astfel încât la conectarea la server să poată fi utilizați toți parametrii conexiunii anterioare. Serverul potrivește id-ul sesiunii anterioare cu parametrii de conexiune, cum ar fi algoritmul de criptare utilizat și secretul principal. Ambele părți trebuie să aibă același secret principal, altfel conexiunea va eșua. Acest lucru împiedică un criptoanalist să folosească ID-ul sesiunii pentru a obține acces neautorizat. Secvențele numerice aleatorii din mesajele ClientHello și ServerHello asigură că cheia de sesiune generată este diferită de cheia de sesiune a conexiunii anterioare. În RFC, acest tip de strângere de mână se numește shorthand .

  1. Faza de negociere: [26]
    • Clientul trimite un mesaj ClientHello care indică cea mai recentă versiune a protocolului TLS acceptat, un număr aleatoriu și o listă de metode de criptare și compresie acceptate potrivite pentru lucrul cu TLS; ID-ul sesiunii conexiunii anterioare este de asemenea adăugat la mesaj .
    • Serverul răspunde cu un mesaj ServerHello care conține: versiunea protocolului aleasă de server, un număr aleator trimis de client, un algoritm de criptare și compresie adecvat din lista furnizată de client. Dacă serverul știe id-ul sesiunii , atunci adaugă același id-ul sesiunii la mesajul ServerHello . Acesta este un semnal către client că poate fi folosită reluarea sesiunii anterioare. Dacă serverul nu recunoaște ID-ul sesiunii , atunci adaugă o altă valoare mesajului ServerHello în loc de ID-ul sesiunii . Pentru client, aceasta înseamnă că conexiunea reluată nu poate fi utilizată. Astfel, serverul și clientul trebuie să aibă același master secret și numere aleatorii pentru a genera o cheie de sesiune;
  2. Serverul trimite un mesaj ChangeCipherSpec indicând că toate informațiile ulterioare vor fi criptate folosind algoritmul setat în timpul strângerii de mână folosind secretul partajat. Acestea sunt mesaje la nivel de înregistrare și, prin urmare, sunt de tip 20, nu 22;
    • Serverul trimite un mesaj criptat Finished care conține hash-ul și MAC-ul generat din mesajele anterioare de handshake;
    • Clientul încearcă să decripteze mesajul Terminat al serverului și să verifice hash-ul și MAC. Dacă procesul de decriptare sau verificare eșuează, strângerea de mână este considerată un eșec și conexiunea trebuie încheiată;
  3. Clientul trimite un mesaj ChangeCipherSpec indicând că toate informațiile ulterioare vor fi criptate folosind algoritmul de strângere de mână, folosind secretul partajat.
    • Clientul trimite mesajul criptat Terminat ;
    • Serverul încearcă în mod similar să decripteze mesajul Finished al clientului și să verifice hash-ul și MAC;
  4. Din acest moment se consideră finalizată confirmarea comunicării, se stabilește protocolul. Tot conținutul pachetului ulterior vine cu tipul 23 și toate datele vor fi criptate.

În plus față de beneficiile de performanță [27] , algoritmul de reluare a conexiunii poate fi folosit pentru a implementa single sign- on, deoarece este garantat că sesiunea originală, ca orice sesiune reluată, este inițiată de același client ( RFC 5077 ). Acest lucru este deosebit de important pentru implementarea protocolului FTPS , care altfel ar fi vulnerabil la un atac man-in-the-middle, în care un atacator ar putea intercepta conținutul datelor la reconectare [28] .

Mandate de sesiune

RFC 5077 extinde TLS prin utilizarea biletelor de sesiune în loc de ID-uri de sesiune .  Specifică modul de reluare a unei sesiuni TLS fără a necesita ID-ul sesiunii anterioare, a cărei stare este stocată pe serverul TLS.

Când se utilizează acreditările de sesiune, serverul TLS stochează starea sesiunii în biletul de sesiune și trimite biletul către clientul TLS pentru stocare. Clientul reia sesiunea TLS prin trimiterea unui bilet de sesiune către server, iar serverul reia sesiunea TLS în funcție de parametrii specifici de sesiune stocați în biletul primit. Biletul de sesiune este criptat, autentificat la server în formă criptată, iar serverul verifică valabilitatea biletului înainte de a-i folosi conținutul.

Unul dintre punctele slabe ale acestei metode este că numai metoda AES128-CBC-SHA256 este întotdeauna utilizată pentru a cripta și autentifica acreditările de sesiune transmise, indiferent de parametrii TLS aleși și utilizați pentru conexiunea TLS în sine [29] . Aceasta înseamnă că informațiile despre sesiunea TLS (stocate în biletul de sesiune) nu sunt la fel de bine protejate ca în cadrul sesiunii TLS în sine. O preocupare deosebită este stocarea cheilor OpenSSL în contextul aplicației (SSL_CTX) pe durata de viață a aplicației, prevenind reintroducerea acestora din acreditările de sesiune AES128-CBC-SHA256 fără a reseta întregul context OpenSSL al aplicației (ceea ce este rar, eroare). predispus, și necesită adesea intervenție manuală).administrator) [30] [31] .

Crime și atacuri BREACH

Autorii atacului BEAST sunt, de asemenea, creatorii celui mai recent atac CRIME, care ar putea permite unui atacator să recupereze conținutul unui cookie web atunci când folosește compresia datelor împreună cu TLS. [32] [33] Când utilizați cookie -uri secrete de autentificare pentru a recupera conținutul , un atacator poate deturna sesiunea într-o sesiune web autentificată.

Algoritmi utilizați în TLS

Următorii algoritmi sunt disponibili în versiunea curentă a protocolului:

Algoritmii pot fi suplimentati in functie de versiunea protocolului. Înainte de TLS 1.2, erau disponibili și următorii algoritmi de criptare simetrică, dar au fost eliminați ca nesiguri: RC2 , IDEA , DES [34] .

Comparație cu colegii

Un domeniu de aplicare pentru o conexiune TLS este conectarea gazdelor într-o rețea privată virtuală . Pe lângă TLS, se pot folosi și suita de protocoale IPSec și conexiunea SSH . Fiecare dintre aceste abordări de implementare a unei rețele private virtuale are propriile avantaje și dezavantaje [35] .

  1. TLS/SSL
    • Avantaje:
      • Invizibil la protocoalele de nivel superior;
      • Popularitatea utilizării în conexiunile la Internet și aplicațiile de comerț electronic;
      • Lipsa unei conexiuni permanente între server și client;
      • Vă permite să creați un tunel pentru aplicațiile care utilizează TCP , cum ar fi e-mailul, instrumentele de programare etc.
    • Defecte:
      • Nu poate fi utilizat cu protocoale UDP și ICMP ;
      • Necesitatea de a urmări starea conexiunii;
      • Cerințe software suplimentare pentru suport TLS.
  2. IPsec
    • Avantaje:
      • Siguranța și securitatea protocolului de protecție a datelor a fost testată și dovedită de când protocolul a fost adoptat ca standard de internet;
      • Lucrul la nivelul superior al protocolului de rețea și criptarea datelor deasupra stratului de protocol de rețea.
    • Defecte:
      • Complexitatea implementării, creând potențialul de vulnerabilități;
      • Cerințe suplimentare pentru echipamentele de rețea (routere etc.);
      • Există multe implementări diferite care nu interacționează întotdeauna corect între ele.
  3. SSH
    • Avantaje:
      • Vă permite să creați un tunel pentru aplicații care utilizează TCP/IP , cum ar fi e-mail, instrumente de programare etc.;
      • Stratul de securitate este invizibil pentru utilizator.
    • Defecte:
      • Este dificil de utilizat în rețele cu multe gateway-uri, cum ar fi routere sau firewall -uri ;
      • Sarcina mare a traficului intranet;
      • Nu poate fi utilizat cu protocoalele UDP și ICMP .
      • Nu are un PKI (PKI bazat pe DNSSEC nu este utilizat pe scară largă).

CA

Certificatele TLS sunt emise de CA. Funcția centrelor de certificare este de a verifica utilizatorul și de a certifica autenticitatea resursei. Există mii de CA, dintre care unele au oferte gratuite.

Vezi și

Note

  1. ↑ STANDARD DE STAT STB 34.101.65-2014
  2. ↑ T. Dierks, E. Rescorla. Protocolul Transport Layer Security (TLS), versiunea 1.2 (august 2008). Arhivat din original pe 9 februarie 2012. ; STANDARD DE STAT STB 34.101.65-2014
  3. ↑ Protocolul SSL: Versiunea 3.0 Arhivat la 28 noiembrie 2011 la versiunea finală SSL 3.0 a Wayback Machine Netscape (18 noiembrie 1996)
  4. ↑ Prezentare generală a criptării SSL/TLS Microsoft TechNet . Actualizat la 31 iulie 2003.
  5. ↑ SSL/TLS în detaliu Microsoft TechNet . Actualizat la 31 iulie 2003.
  6. ↑ 1 2 3 Bright, Peter Apple, Google, Microsoft și Mozilla se unesc pentru a pune capăt TLS 1.0 (17 octombrie 2018). Consultat la 17 octombrie 2018. Arhivat din original la 17 octombrie 2018.
  7. ↑ Thomas YC Woo, Raghuram Bindignavle, Shaowen Su și Simon S. Lam , SNP: An interface for secure network programming Proceedings Conferința tehnică de vară USENIX, iunie 1994
  8. ↑ Oppliger, Rolf. Introducere // SSL și TLS: Teorie și practică  (neopr.) . — al 2-lea. — Casa Artech, 2016. - P. 13. - ISBN 978-1-60807-999-5 .
  9. ↑ POODLE: Vulnerabilitatea SSLv3 (CVE-2014-3566) . Data accesului: 21 octombrie 2014. Arhivat din original pe 5 decembrie 2014.
  10. ↑ Laura K. Gray. Modificarea datei pentru migrarea de la SSL și TLS timpuriu . Blogul Consiliului pentru standardele de securitate pentru industria cardurilor de plată (18 decembrie 2015). Consultat la 5 aprilie 2018. Arhivat din original la 20 decembrie 2015.
  11. ↑ Protocolul TLS (Transport Layer Security) Versiunea 1.1 (aprilie 2006). Arhivat din original pe 24 decembrie 2017.
  12. ↑ Linii directoare pentru selecția, configurarea și utilizarea implementărilor de securitate a stratului de transport (TLS) 67. Institutul Național de Standarde și Tehnologie (aprilie 2014). Preluat la 7 mai 2014. Arhivat din original la 8 mai 2014.
  13. ↑ „Terminat” secțiunea 7.4.9. RFC 5246 .
  14. ↑ Note de lansare NSS 3.29 . Mozilla Developer Network (februarie 2017). Arhivat din original pe 22 februarie 2017.
  15. ↑ Firefox-Note (60.0  ) . Mozilla . Preluat la 10 mai 2018. Arhivat din original la 09 mai 2018.
  16. ↑ ProxySG, ASG și WSS vor întrerupe conexiunile SSL atunci când clienții care folosesc TLS 1.3 accesează site-uri folosind și TLS 1.3 . BlueTouch Online (16 mai 2017). Preluat la 11 septembrie 2017. Arhivat din original la 12 septembrie 2017.
  17. ↑ Este lansat OpenSSL 1.1.1 . Matt Caswell (11 septembrie 2018). Consultat la 19 decembrie 2018. Arhivat din original la 15 septembrie 2018.
  18. ↑ Hoffman-Andrews, Jacob ETS nu este TLS și nu ar trebui să-l  folosești . Electronic Frontier Foundation (26 februarie 2019). Preluat la 27 februarie 2019. Arhivat din original la 26 februarie 2019.
  19. ↑ Dan Goodin. Hackerii încalcă criptarea SSL folosită de milioane de site-uri . Registrul (19 septembrie 2011). Preluat la 7 decembrie 2011. Arhivat din original la 9 februarie 2012.
  20. ↑ Eric Rescorla. Înțelegerea atacului de renegociere TLS . Ghicirea educată (5 noiembrie 2009). Preluat la 7 decembrie 2011. Arhivat din original la 9 februarie 2012.
  21. ↑ McMillan, Robert . Security Pro spune că noul atac SSL poate afecta multe site-uri , PC World  (20 noiembrie 2009). Arhivat din original pe 19 ianuarie 2012. Preluat la 7 decembrie 2011.
  22. ↑ SSL_CTX_set_options SECURE_RENEGOTIATION (link descendent) . OpenSSL Docs (25 februarie 2010). Consultat la 7 decembrie 2010. Arhivat din original pe 9 februarie 2012. 
  23. ↑ GnuTLS 2.10.0 lansat . Note de lansare GnuTLS (25 iunie 2010). Preluat la 7 decembrie 2011. Arhivat din original la 9 februarie 2012.
  24. ↑ Note de lansare NSS 3.12.6 . Note de lansare a NSS (3 martie 2010). Preluat la 24 iulie 2011. Arhivat din original la 6 martie 2012.
  25. ↑ Diverse. Vulnerabilitatea IE SSL (link indisponibil) . Ghicirea educată (10 august 2002). Consultat la 7 decembrie 2010. Arhivat din original pe 9 februarie 2012. 
  26. ↑ http://www.ict.kth.se/courses/IK1550/Sample-papers/2G1305_Assignment_Asa_Pehrsson_050908.pdf Arhivat din original pe 9 februarie 2012. Figura 3
  27. ↑ A. Pehhrson. Impactul reluării sesiunii TLS asupra performanței HTTP (martie 2008). Arhivat din original pe 9 februarie 2012.
  28. ↑ vsftpd-2.1.0 lansat Arhivat 7 iulie 2012 la Wayback Machine Utilizând reluarea sesiunii TLS pentru autentificarea conexiunii de date FTPS. Consultat la 28.04.2009.
  29. ↑ Daignière, Florent TLS „Secretele”: Carte albă care prezintă implicațiile de securitate ale implementării biletelor de sesiune (RFC 5077) așa cum sunt implementate în OpenSSL (link nu este disponibil) . Matta Consulting Limited. Preluat la 7 august 2013. Arhivat din original la 6 august 2013. 
  30. ↑ Daignière, Florent TLS „Secretele”: Ceea ce toată lumea a uitat să vă spună... (downlink) . Matta Consulting Limited. Preluat la 7 august 2013. Arhivat din original la 5 august 2013. 
  31. ↑ Langley, Adam Cum să greșești secretul direct TLS . imperialviolet.org (27 iunie 2013). Data accesului: 31 ianuarie 2014. Arhivat din original la 8 august 2013.
  32. ↑ Dan Goodin. Crăpătura în baza de încredere a Internetului permite deturnarea sesiunii HTTPS . Ars Technica (13 septembrie 2012). Data accesului: 31 iulie 2013. Arhivat din original la 1 august 2013.
  33. ↑ CRIME Attack folosește raportul de compresie al solicitărilor TLS ca canal lateral pentru a deturna sesiunile securizate (13 septembrie 2012). Preluat: 13 septembrie 2012.
  34. ↑ Eric Rescorla. Actualizare  TLS 1.2 . 70 proceduri IETF. - „Alte modificări... S-au eliminat RC2, DES și IDEA.” Preluat la 3 ianuarie 2018. Arhivat din original la 28 martie 2016.
  35. ↑ OM Dahl. Limitări și diferențe ale utilizării IPsec, TLS/SSL sau SSH ca soluție VPN (octombrie 2004). Arhivat din original pe 9 februarie 2012.

Link -uri