Istoria completă a versiunilor SSL și TLS: Din 1994 până în prezent

Timp de peste trei decenii, protocoalele SSL și TLS au protejat miliarde de tranzacții online. Ceea ce a început ca un proiect ambițios de securitate al Netscape în 1994 a evoluat în standardele sofisticate de criptare de astăzi. Această istorie SSL cuprinde șase versiuni majore ale protocolului, nenumărate îmbunătățiri ale securității și o schimbare fundamentală în modul în care gândim securitatea web.

Înțelegerea versiunilor SSL/TLS nu înseamnă doar să știm ce protocoale sunt depreciate. Este vorba despre recunoașterea modului în care fiecare vulnerabilitate, atac și descoperire a modelat peisajul actual în care TLS 1.3 securizează 95% din traficul web criptat.

---

Tabla de conținut

1. Nașterea protocolului SSL la Netscape
2. SSL 3.0 – O reproiectare completă a protocolului
3. TLS 1.0 – Era standardizării IETF
4. TLS 1.1 și TLS 1.2 – îmbunătățiri incrementale ale securității
5. TLS 1.3 – Standardul modern de securitate
6. Concepții greșite frecvente cu privire la versiunile SSL/TLS
7. Rolul autorităților de certificare în evoluția SSL/TLS
8. Repere din industrie care au modelat adoptarea HTTPS
9. Vulnerabilități majore de securitate care au condus la evoluția protocoalelor
10. Viitorul protocoalelor SSL/TLS

---

---

Nașterea protocolului SSL la Netscape

SSL 1.0 – Prima tentativă nepublicată (1994)

Taher Elgamal, cercetătorul șef al Netscape, a conceput Secure Sockets Layer original în 1994. Însă SSL 1.0 nu a văzut niciodată lumina zilei. Cercetătorii în domeniul securității de la Netscape au descoperit defecte critice înainte de lansarea publică, vulnerabilități suficient de grave pentru a elimina întreaga versiune.

Lecția a fost clară: protocoalele criptografice trebuie revizuite amănunțit înainte de implementare. Acest eșec, deși frustrant, a stabilit un model de testare riguroasă care va defini dezvoltarea viitoare a SSL și TLS.

SSL 2.0 – Prima versiune publică (1995)

Când a apărut SSL? Răspunsul este februarie 1995, când Netscape a inclus SSL 2.0 cu Navigator 1.1. Această versiune SSL a introdus concepte fundamentale utilizate și astăzi: procesul de handshake SSLcertificatele digitaleX.509 și autentificarea serverului.

Însă SSL 2.0 avea probleme. Se baza pe MD5 pentru autentificarea mesajelor, folosea aceeași cheie pentru criptare și autentificare și nu avea protecție pentru handshake-ul în sine. Atacatorii puteau reduce conexiunile la o criptare mai slabă pe 40 de biți fără ca vreuna dintre părți să observe.

IETF a depreciat oficial SSL 2.0 în martie 2011 prin RFC 6176. Până atunci, majoritatea serverelor au trecut deja mai departe.

---

SSL 3.0 – O reproiectare completă a protocolului

Îmbunătățiri majore față de SSL 2.0 (1996)

Paul Kocher, Phil Karlton și Alan Freier au rescris complet protocolul SSL pentru versiunea 3.0, lansată în noiembrie 1996. Aceștia au separat stratul de transport al datelor de cel al mesajelor, au adăugat suport pentru schimbul de chei Diffie-Hellman și suitele de cifrare Fortezza și au implementat o criptare corespunzătoare pe 128 de biți.

SSL 3.0 a introdus, de asemenea, compresia înregistrărilor și o negociere mai flexibilă a suitei de cifre. IETF l-a documentat ulterior în RFC 6101, recunoscând importanța sa istorică. Timp de aproape două decenii, SSL 3.0 a servit ca opțiune de rezervă pentru sistemele tradiționale.

Vulnerabilitatea POODLE și deprecierea SSL 3.0

În octombrie 2014, echipa de securitate a Google a descoperit POODLE (Padding Oracle on Downgraded Legacy Encryption). Atacul a exploatat modul în care SSL 3.0 a gestionat paddingul în modul CBC (cipher block chaining). Atacatorii puteau decripta cookie-uri HTTP securizate prin forțarea browserelor să treacă de la TLS la SSL 3.0.

IETF a reacționat rapid, depreciind SSL 3.0 în iunie 2015 prin RFC 7568. Aceasta a marcat sfârșitul erei SSL. Când oamenii întreabă care este„cea mai recentă versiune SSL„, răspunsul este SSL 3.0, deoarece SSL în sine nu a mai fost actualizat niciodată. Torța a trecut la Transport Layer Security.

---

TLS 1.0 – Era standardizării IETF

Tranziția de la SSL la TLS (1999)

La sfârșitul anilor 1990, IETF dorea să standardizeze protocoalele de securitate ale internetului. Tim Dierks și Christopher Allen au condus efortul de a transforma SSL într-un standard deschis. Microsoft și Netscape au negociat denumirea – TransportLayer Security a fost compromisul care a rămas.

TLS 1.0, publicat ca RFC 2246 în ianuarie 1999, era în esență SSL 3.1 cu un nume nou. Diferențele erau minore, dar suficient de semnificative pentru a rupe compatibilitatea. Nu se puteau combina clienți SSL 3.0 cu servere TLS 1.0 fără o implementare atentă.

Principalele diferențe față de SSL 3.0

TLS 1.0 a actualizat criptografia de bază. Acesta a înlocuit codul de autentificare a mesajelor (MAC) personalizat al SSL cu HMAC, standardizat de criptografi. Funcția de derivare a cheii a fost modificată pentru a preveni anumite atacuri teoretice. Sistemul de alertă a fost extins cu coduri de eroare mai specifice.

TLS 1.0 a necesitat, de asemenea, suport pentru suitele de cifre DSS/DH, oferind implementărilor mai multă flexibilitate. Aceste schimbări par mici, dar reflectă o trecere de la dezvoltarea proprietară la standardizarea orientată către comunitate. IETF controla acum evoluția protocolului.

---

TLS 1.1 și TLS 1.2 – îmbunătățiri incrementale ale securității

Protecția TLS 1.1 împotriva atacurilor CBC (2006)

Lansat în aprilie 2006 prin RFC 4346, TLS 1.1 a abordat vulnerabilități CBC specifice. Cea mai importantă schimbare? Vectorii de inițializare (IV) expliciți au înlocuit IV impliciți. Acest lucru a împiedicat atacatorii să prezică IV-ul și să exploateze înlănțuirea blocurilor de cifru.

TLS 1.1 a îmbunătățit, de asemenea, gestionarea erorilor pentru înregistrările completate. În loc să dezvăluie erori specifice de umplere, a returnat o alertă generică bad_record_mac. Aceste modificări au protejat împotriva BEAST (Browser Exploit Against SSL/TLS), descoperit ani mai târziu, în 2011.

Au fost înființate registre ale parametrilor IANA, ceea ce a permis o mai bună organizare a gestionării suitelor de cifrare. Însă adoptarea a fost lentă. Multe organizații au renunțat complet la TLS 1.1, așteptând îmbunătățirile mai substanțiale ale TLS 1.2.

TLS 1.2 Flexibilitate sporită (2008)

Când a fost lansat TLS 1.2? August 2008, prin RFC 5246. Această actualizare a adus cele mai importante schimbări de la SSL 3.0. Protocolul a trecut de la combinațiile MD5/SHA-1 codificate la funcții pseudorandomice (PRF) specificate pentru suita de cifrare. SHA-256 a devenit noul standard.

TLS 1.2 a introdus moduri de cifrare autentificate cu date suplimentare (AEAD), inclusiv AES-GCM și ChaCha20-Poly1305. Aceasta a oferit implementărilor flexibilitate în alegerea algoritmilor de hash și de semnătură. Această adaptabilitate s-a dovedit esențială pe măsură ce standardele criptografice au evoluat.

Protocolul continuă să fie utilizat pe scară largă și în prezent. Aproximativ 95,8% din site-urile web încă acceptă TLS 1.2, adesea în paralel cu TLS 1.3. În martie 2021, IETF a depreciat împreună TLS 1.0 și 1.1 prin RFC 8996, făcând din TLS 1.2 standardul minim acceptabil.

---

---

TLS 1.3 – Standardul modern de securitate

Cinci ani în dezvoltare (2018)

TLS 1.3 a avut nevoie de un deceniu pentru a ajunge. IETF a publicat RFC 8446 în august 2018, după 28 de proiecte și o colaborare extinsă. Simplitatea și performanța au condus la reproiectare. Grupul de lucru a eliminat caracteristicile moștenite, a simplificat handshake-ul și a eliminat clase întregi de vulnerabilități.

Google, Mozilla, Microsoft și Apple au adăugat rapid suport. Până în 2019, toate browserele majore puteau negocia conexiuni TLS 1.3. Cloudflare și alți furnizori CDN au activat-o implicit. Cea mai recentă versiune TLS nu a îmbunătățit doar securitatea, ci a făcut conexiunile criptate mai rapide.

Îmbunătățiri revoluționare ale securității

TLS 1.3 a eliminat tot ce era stricat sau slăbit. SHA-1, MD5, RC4, DES și suitele de cifruri 3DES? Au dispărut. Schimbul static de chei RSA și Diffie-Hellman? Eliminate. Protocolul necesită acum secretul perfect de transmitere folosind Diffie-Hellman efemer pentru toate conexiunile.

Handhake-ul s-a schimbat fundamental. Fiecare mesaj după ServerHello este criptat, ascunzând negocierea de ochii curioșilor. Funcția de derivare a cheii a trecut la funcția HKDF (Extract-and-Expand) bazată pe HMAC, oferind garanții criptografice mai bune.

TLS 1.3 a introdus, de asemenea, modul 0-RTT (zero round-trip time). Clienții pot trimite date criptate în primul mesaj către serverele contactate anterior, eliminând latența handshake-ului. Mașina de stare simplificată a făcut implementările mai puțin predispuse la erori. ECC a fost introdus în specificațiile de bază împreună cu noi algoritmi de semnătură, precum RSA-PSS.

Adoptarea actuală și coexistența

Care este cea mai recentă versiune TLS? TLS 1.3 deține acest titlu. Dar TLS 1.2 nu va dispărea prea curând. Organizațiile au nevoie de timp pentru a actualiza serverele, a testa compatibilitatea și a actualiza software-ul clienților. Majoritatea site-urilor preocupate de securitate suportă acum ambele soluții, permițând clienților să aleagă cea mai bună opțiune disponibilă.

Coexistența funcționează bine. Serverele negociază cea mai înaltă versiune acceptată reciproc. Clienții care nu pot gestiona TLS 1.3 revin la TLS 1.2. Această abordare de migrare treptată previne dezastrele de compatibilitate care au afectat tranzițiile anterioare.

---

Concepții greșite frecvente cu privire la versiunile SSL/TLS

De ce nu există TLS 2.0

Care este data lansării TLS 2.0? Nu există niciunul. TLS 2.0 nu există și nu va exista niciodată. IETF utilizează versiuni incrementale: TLS 1.0, 1.1, 1.2, 1.3. Următoarea versiune, dacă va apărea, va fi TLS 1.4 sau posibil TLS 2.0, dar trecerea directă la „TLS 2.0” după SSL 3.0 ar fi provocat o confuzie masivă.

Oamenii se așteaptă adesea ca protocoalele să utilizeze numere de versiune majore (precum software-ul care trece de la versiunea 1 la versiunea 2). Dar protocoalele criptografice evoluează mai conservator, fiecare versiune bazându-se pe cea anterioară.

Terminologie SSL vs. TLS

Cereți un „certificat SSL” și veți primi un certificat care funcționează cu TLS 1.2 și TLS 1.3. Industria încă folosește „SSL” în marketing pentru că este familiar. Chiar dacă versiunea actuală a SSL este inexistentă din punct de vedere tehnic (SSL s-a încheiat la versiunea 3.0), termenul a rămas.

Autoritățile de certificare precum DigiCert și Sectigo vând „certificate SSL” care utilizează exclusiv protocoalele TLS. Este derutant, dar inofensiv. Nu uitați: când cineva menționează SSL în 2026, aproape sigur se referă la TLS.

---

Rolul autorităților de certificare în evoluția SSL/TLS

Tipuri de validare Dezvoltare

Primele certificate SSL erau scumpe și lente. Validarea afacerilor necesita zile sau săptămâni de verificare manuală. În 2002, GeoTrust a introdus Validarea domeniului, automatizând procesul prin verificarea proprietății domeniului prin e-mail sau înregistrări DNS.

CertificateleExtended Validation au apărut în 2007, promițând cea mai mare siguranță cu bare de adrese verzi în browsere. Let’s Encrypt a fost lansat în 2015, oferind certificate gratuite de validare a domeniului prin emitere automată. Cloudflare a urmat cu propriul său program de certificate gratuite. Aceste schimbări au democratizat HTTPS, făcând criptarea accesibilă site-urilor web mici.

Reducerea perioadei de valabilitate a certificatului

Perioadele de valabilitate a certificatelor au continuat să scadă. Cerințele de bază au redus valabilitatea maximă de la cinci ani la trei ani în 2015. Doi ani a devenit limita în 2018. Safari de la Apple a impus un maxim de un an în 2020, forțând alte browsere să urmeze.

În prezent, industria se îndreaptă către un ciclu de viață și mai scurt al certificatelor. Forumul CA/Browser a definit o reducere clară a perioadelor de valabilitate a certificatelor: 200 de zile începând cu 15 martie 2026,100 de zile începând cu 15 martie 2027 și doar 47 de zile până la 15 martie 2029.

Această schimbare face ca gestionarea manuală a certificatelor să devină nepractică, împingând organizațiile către soluții automatizate precum Certificate-as-a-Service (CaaS) bazate pe ACME, în care validarea, emiterea și reînnoirea sunt gestionate automat.

---

Repere din industrie care au modelat adoptarea HTTPS

Impulsul HTTPS al Google

În august 2014, Google a anunțat HTTPS ca un semnal de clasificare. Această decizie unică a schimbat istoria SSL. Webmasterii care au ignorat criptarea au avut brusc motive de afaceri să le pese. Până în 2016, jumătate din traficul web era criptat.

Chrome 68 a făcut pasul următor în iulie 2018, marcând toate site-urile HTTP ca „Nu este sigur.” Avertismentul a apărut în bara de adrese pentru fiecare pagină necriptată. Astăzi, peste 95% din traficul web utilizează HTTPS. Google a transformat criptarea dintr-o bună practică de securitate într-o cerință de afaceri.

Evoluția indicatorilor de securitate ai browserului

Mai țineți minte bara de adrese verde a Extended Validation? A dispărut. Chrome a eliminat-o în 2020, după ce cercetările au arătat că utilizatorii nu o observau sau nu o înțelegeau. Pictograma lacătului dispare, înlocuită de indicatori neutri care normalizează HTTPS în loc să îl recompenseze.

Chrome 69 a eliminat textul „Secure”, lăsând doar lacătul. Browserele actuale se concentrează pe avertizarea cu privire la conexiunile nesigure, mai degrabă decât pe lăudarea celor sigure. Mesajul: HTTPS este așteptarea implicită, nu ceva special.

---

Vulnerabilități majore de securitate care au condus la evoluția protocoalelor

Atacuri notabile asupra SSL/TLS

POODLE a afectat SSL 3.0 în 2014, exploatând vulnerabilitățile padding oracle în modul CBC. Atacatorii puteau decripta cookie-urile securizate prin retrogradarea conexiunilor și modificarea repetată a textului cifrat. Atacul a ucis SSL 3.0 în câteva luni.

BEAST a vizat TLS 1.0 în 2011, folosind o slăbiciune CBC similară. Atacatorii puteau decripta cookie-urile HTTPS prin injectarea de cod pe partea clientului și observarea răspunsurilor criptate. Soluția a necesitat implementarea de IV-uri explicite în TLS 1.1.

BREACH a abuzat de compresia HTTP în 2013. Atacul nu a vizat protocolul TLS în sine, dar a arătat modul în care deciziile la nivelul aplicațiilor afectează securitatea. Heartbleed, descoperit în 2014, a expus un defect critic al OpenSSL care a permis scurgerea cheilor private și a datelor utilizatorilor.

Lecții învățate

Fiecare vulnerabilitate a demonstrat același lucru: compatibilitatea retroactivă este periculoasă. Menținerea în viață a protocoalelor vechi pentru sistemele tradiționale creează vectori de atac. Industria a învățat să deprecieze agresiv și să forțeze actualizările.

Și cercetătorii în domeniul securității au dreptul la recunoaștere. Dezvăluirea publică a vulnerabilităților a accelerat îmbunătățirile. Fără POODLE, SSL 3.0 ar putea fi încă ascuns în configurațiile serverelor de astăzi.

---

Viitorul protocoalelor SSL/TLS

Criptografia post-cuantum

Calculatoarele cuantice amenință algoritmii de criptare actuali. RSA și criptografia cu curbă eliptică ar putea deveni depășite odată ce mașinile cuantice vor atinge o scară suficientă. NIST standardizează algoritmi post-cuantici concepuți pentru a rezista atacurilor cuantice.

TLS va avea nevoie de actualizări pentru a suporta acești algoritmi rezistenți la cuantică. Tranziția nu va fi ușoară, criptografia post-cuantică utilizează chei mai mari și abordări matematice diferite. Dar evoluția protocolului care ne-a adus de la SSL 2.0 la TLS 1.3 a demonstrat că comunitatea poate face față tranzițiilor majore.

Tehnologii emergente

DTLS (Datagram Transport Layer Security) extinde TLS la conexiunile UDP. QUIC, dezvoltat de Google și standardizat de IETF, integrează criptarea direct în stratul de transport. Aceste protocoale se bazează pe bazele criptografice ale TLS, adaptându-se în același timp la diferite cazuri de utilizare.

Alternative bazate pe Blockchain, precum Remme, experimentează PKI distribuit. Autoritățile de certificare continuă să evolueze, automatizând mai multe procese și suportând perioade de valabilitate mai scurte. Ce urmează după TLS 1.3? Probabil îmbunătățiri incrementale, mai degrabă decât o reproiectare completă. TLS 1.3 a făcut majoritatea lucrurilor bine.

---

Rămâneți la curent cu certificatele SSL Dragon pregătite pentru TLS 1.3

Înțelegerea evoluției protocoalelor este un lucru. Implementarea standardelor moderne de criptare este altceva. SSL Dragon oferă certificate digitale pe deplin compatibile cu TLS 1.3 și TLS 1.2, suportând cele mai recente protocoale criptografice și suite de cifre.

Oferim emitere rapidă, criptare puternică și 99,99% încredere în browser prin parteneriate cu autorități de certificare de top, inclusiv DigiCert, Sectigo și GeoTrust. Soluțiile noastre automatizate de gestionare a certificatelor vă ajută să gestionați ciclurile de viață viitoare de 47 de zile fără probleme de reînnoire manuală.

Migrați de la protocoale depreciate? Echipa noastră de asistență dedicată vă ghidează pe parcursul tranziției. Fiecare achiziție include o garanție de returnare a banilor de 25 de zile. Explorați portofoliul nostru de certificate astăzi și asigurați-vă infrastructura cu cea mai recentă versiune TLS.