TLS: Protokollen bag hvert hængelåsikon

SSL → TLS: den kronologiske historie

Netscape Communications byggede den første SSL-implementering i 1994 for at sikre online shopping i den helt nye Netscape Navigator-browser. SSL 1.0 blev aldrig offentligt udgivet, fordi det havde kritiske mangler. SSL 2.0 blev sendt i februar 1995, blev straks brudt, og SSL 3.0 fulgte i 1996 som en næsten total omskrivning.

I 1999 overtog IETF protokollen og omdøbte den til Transport Layer Security for at markere overgangen fra et Netscape-produkt til en åben standard. Versionshistorikken siden:

• TLS 1.0 (januar 1999, RFC 2246) - i det væsentlige SSL 3.1.
• TLS 1.1 (april 2006) - beskyttet mod eksplicit 4346, RFC46, RFC-angreb initialiseringsvektorer.
• TLS 1.2 (august 2008, RFC 5246) — tilføjede AEAD-cifre, SHA-256, konfigurerbare signaturalgoritmer. Domineret i et årti.
• TLS 1.3 (august 2018, RFC 8446) — større redesign. Fjernet legacy cruft, påbudt fremadrettet hemmeligholdelse, skåret forsinkelse på håndtryk.

SSL 3.0 blev formelt forældet i juni 2015 (RFC 7568) efter POODLE. TLS 1.0 og 1.1 blev udfaset i marts 2021 (RFC 8996). I 2026 bør moderne servere afvise alt under TLS 1.2 og foretrække TLS 1.3.

Sådan fungerer håndtrykket faktisk

Hver TLS-forbindelse starter med et håndtryk, der gør tre ting: enig om en chifferpakke, bevis serverens øvrige del af nøglen, og deri session.

TLS 1.2-håndtryk (det klassiske flow)

1. ClientHello: klienten sender understøttede TLS-versioner, krypteringspakker og et tilfældigt nummer.
2. Xver9H38XPLZer én server, en serverpakke sender sit tilfældige nummer.
3. Certificate: Serveren sender sin X.509 certifikatkæde, så klienten kan bekræfte identiteten.
4. ServerKeyExchange: serveren sender sin Diffie-Hellman offentlige nøgle (for ephemeral) exchange).
5. ClientKeyExchange: klienten sender sin offentlige DH-nøgle. Begge sider udleder nu den samme fælles hemmelighed.
6. Finished: Begge sider bekræfter håndtrykket ved at sende en MAC over hele transskriptionen.

TDet er to hele rundrejser, før den første applikationsbyte kan flyde. På et 100ms-latency-link spiser hver ny HTTPS-forbindelse 200ms, før noget egentligt indhold flyttes.

TLS 1.3-håndtryk (det moderne flow)

TLS 1.3 kollapser håndtrykket til én rundtur i det fælles case:

1. ClientHello: inkluderer klientens offentlige DH-nøgle for hver krypteringsgruppe, som klienten understøtter.
2. ServerHello + alt andet: serveren vælger en offentlig gruppe, sender sin DH-nøgle, certifikaterer den i én flight.
3. Client validerer og svarer med sin egen Finished.

Én rundtur, to flyvninger. Med genoptagelse af sessionen (0-RTT) kan klienten endda begynde at sende data med sin første besked - på bekostning af nogle videregående hemmeligholdelsesegenskaber for disse indledende data. Ud gik:

• Statisk RSA-nøgleudveksling (brød fremad hemmeligholdelse).
• CBC-mode-chiffer (sårbar over for BEAST og Lucky Thirteen).
• RC4-stream-ciffer (forlængst brudt). signaturer.
• Renegotiation (erstattet af post-handshake auth).
• Compression (CRIME class of attacks).
• Custom Diffie-Hellman parametre (Logjam fix).
XPLZher0 suite listen gik fra TLScip09 suitelisten. 1.2 ned til 5 i TLS 1.3. Mindre reb at hænge sig med.

Angrebshistorikken, der formede TLS

• BEAST (2011) — valgt almindelig tekstangreb på CBC-tilstand i TLS 1.0. Rettet i 1.1+ via eksplicitte IVs.
• CRIME (2012) — brugte TLS-komprimering til at gendanne sessionscookies. Rettet ved at deaktivere komprimering.
• BREACH (2013) — Kompression på HTTP-niveau svarende til CRIME. Afværget ved at deaktivere HTTP-komprimering på følsomme svar.
• Heartbleed (april 2014) — OpenSSL-fejl, ikke et TLS-specifikationsproblem. Lækket serverhukommelse inklusive private nøgler. Massecertifikatrotationshændelse på tværs af nettet.
• POODLE (oktober 2014) — udnyttet SSL 3.0-faldback. Dræbt SSL 3.0 i browsere inden for få uger.
• Logjam (2015) — viste, at små Diffie-Hellman-grupper (især 1024-bit Group 2, der er meget brugt i IPsec/IKE) var inden for rækkevidde af nationalstatsangribere. Tvunget industridækkende migrering til større grupper og elliptisk kurve DH.
• Lucky Thirteen (2013) — timing angreb på CBC-tilstand. Rettelse på biblioteksniveau i OpenSSL og andre.

Hvert angreb strammede protokollen. Med TLS 1.3 er de fleste af disse klasser umulige af design.

Certifikatmyndigheder og tillidsproblemet

TLS-godkendelse er afhængig af certifikatmyndigheder (CA'er), som browsere har tillid til som standard. Top tre efter markedsandel siden 2019: IdenTrust, DigiCert og Sectigo. Let's Encrypt – den gratis, automatiserede CA, der blev lanceret i 2016 – førte til det største adoptionsfremstød i HTTPS-historien.

Den strukturelle svaghed: Enhver betroet CA kan udstede et certifikat for ethvert domæne. En kompromitteret eller tvunget CA kan præge et gyldigt certifikat for din bank. Certificate Transparency (CT)-logfiler — offentlige vedhæftede registreringer af hvert certifikat, der nogensinde er udstedt — blev introduceret for at opdage dette. Browsere kræver nu, at certifikater vises i CT-logfiler, før de accepterer dem.

CA/Browser-forummet godkendte at reducere den maksimale certifikatgyldighed til 47 dage inden 2029, hvilket skærper vinduet, hvor en kompromitteret CA kan gøre skade. læk: feltet Server Name Indication (SNI) i ClientHello, som fortæller serveren, hvilket værtsnavn du opretter forbindelse til, så den kan præsentere det rigtige certifikat. SNI er almindelig tekst, så netværksobservatører lærer hvert domæne, du besøger, selvom resten af ​​forbindelsen er krypteret.

Encrypted Client Hello (ECH) - en videreudvikling af det tidligere ESNI-forslag - krypterer SNI'et ved hjælp af en offentlig nøgle, som destinationen udgiver via DNS. Cloudflare og Apple har leveret ECH-support; Firefox og Chrome rullede det ud bag flag gennem 2024 og bevæger sig mod standard-on. For brugere på fjendtlige netværk er ECH den næste privatlivsopgradering efter universel HTTPS.

DTLS — TLS for UDP

DTLS (Datagram TLS) er TLS-varianten, der fungerer over UDP. Det driver WebRTC (browser video/stemme), QUICs underliggende sikkerhed og adskillige VPN-protokoller. DTLS 1.3 (RFC 9147, 2022) matcher TLS 1.3's håndtryk og chiffer-moderniseringer.

Post-quantum TLS

Diffie-Hellman nøgleudveksling — grundlaget for TLS fremadrettet hemmeligholdelse — er stort set, som kan brydes af en tilstrækkelig computer. Rettelsen er hybrid nøgleudveksling, der kombinerer en klassisk algoritme (X25519) med en post-kvantekandidat (typisk ML-KEM-768, tidligere kendt som Kyber).

Chrome aktiverede X25519MLKEM768 hybrid som standard i slutningen af 2024, og Apple flare, iCloud, leverer flere VPN-, Cloud- og Cloud-skibe via VPN. 2025. Den bredere udrulning beskytter dagens trafik mod angrebet "høst nu, dekrypter senere" - en modstander, der optager krypteret trafik i dag, venter på kvantecomputere og dekrypterer derefter historisk.

Sådan verificerer du den TLS, din browser faktisk bruger

på din browsers hængelås adresselinje. Moderne browsere viser protokolversionen, krypteringspakken og certifikatdetaljerne. Hvis du ser TLS 1.0 eller 1.1, bruger webstedet forældede konfigurationer. Hvis du ser TLS 1.3 med AES-256-GCM eller ChaCha20-Poly1305, er du på moderne crypto.

Den ledsagende teknologi HTTPS — covered in our HTTPS explainer — er det, der omslutter nettet i TLS. De to termer bruges ofte i flæng i daglig tale, men TLS er den underliggende kryptografiske protokol; HTTPS er bare HTTP-over-TLS.