Varför äldre TLS-protokoll är osäkra för din organisation?

Publicerad: september 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI-rådgivningsteam.

Netscape skickade in det första offentliga utkastet av SSL 1995, och SSL 3.0 följde ett år senare när tidiga brister uppdagades. IETF döpte om protokollet till TLS 1999 (RFC 2246) och publicerade sedan TLS 1.1 2006 (RFC 4346), TLS 1.2 2008 (RFC 5246) och TLS 1.3 2018 (RFC 8446). Den versionshistoriken är viktig av en anledning: varje version äldre än TLS 1.2 är nu formellt föråldrad, och två av dem, TLS 1.0 och SSL 3.0, har offentligt demonstrerat och namngett attacker mot dem. Den här guiden täcker exakt varför dessa versioner är osäkra, de specifika sårbarheterna bakom den slutsatsen, hur man väljer rätt protokoll och chiffersvit framöver, och hur man migrerar utan att förstöra äldre klienter som man inte visste att man hade.

Varför är TLS 1.0 och TLS 1.1 osäkra?

TLS 1.0 och TLS 1.1 är osäkra eftersom båda versionerna är beroende av SHA-1 för handskakningsintegritet och meddelandeautentisering, båda tillåter CBC-lägeskrypteringssviter med kända svagheter i utfyllnadsorakel, och båda har formellt föråldrats av IETF. RFC 8996, Deprecating TLS 1.0 and TLS 1.1 , publicerad i mars 2021, anger tydligt att dessa versioner "saknar stöd för nuvarande och rekommenderade kryptografiska algoritmer och mekanismer", och den föråldrar RFC 5469 (krypteringssviterna DES och IDEA) och RFC 7507 (TLS Fallback Signaling Cipher Suite), samtidigt som den uppdaterar mer än 80 andra RFC:er som tidigare refererat till TLS 1.0 eller 1.1 som en acceptabel minimiversion.

Tre konkreta svagheter driver den nedvärderande trenden:

• SHA-1-beroende handskakningar. Båda versionerna autentiserar handskakningen med hjälp av SHA-1 eller en MD5/SHA-1-sammankoppling, vilket möjliggör nedgraderingsattacker som kräver ungefär 2^77 operationer, en arbetsbelastning som inte längre räknas som beräkningsmässigt ogenomförbar mot en angripare med resurser.
• Inget AEAD-stöd. Varken TLS 1.0 eller TLS 1.1 stöder autentiserad kryptering med associerade data (AEAD) chiffer, AES-GCM och ChaCha20-Poly1305 sviterna som introducerades i TLS 1.2 och som tar bort en hel klass av utfyllnads- och MAC-timing-buggar.
• Osäkra initialiseringsvektorer. TLS 1.0 återanvänder det sista chiffertextblocket i en post som initialiseringsvektor för nästa, en förutsägbar IV-design som TLS 1.1 delvis fixade men som lämnade båda versionerna exponerade för den postdelningsattack som beskrivs i nästa avsnitt.

SSL 2.0 och SSL 3.0 är ännu värre: SSL 2.0 drogs tillbaka för årtionden sedan på grund av grundläggande designfel, och SSL 3.0 är den protokollversion som POODLE-attacken knäckte helt. Ingen organisation bör tillåta SSL 2.0, SSL 3.0, TLS 1.0 eller TLS 1.1 på något produktionssystem. TLS 1.2 är det nuvarande golvet för efterlevnad, och TLS 1.3 bör vara standard där din kundbas stöder det.

Skräddarsydda krypteringstjänster

Vi utvärderar, strategiserar och implementerar krypteringsstrategier och lösningar.

Läs mer

Vilka specifika sårbarheter påverkar äldre TLS-versioner?

BEAST och POODLE är de två namngivna, offentligt demonstrerade attackerna som förvandlade "TLS 1.0 är gammal" till "TLS 1.0 är aktivt exploaterbar", och båda riktar sig mot samma underliggande svaghet: förutsägbart beteende i CBC-läges blockchiffer.

• BEAST (Webbläsarattack mot SSL/TLS), CVE-2011-3389. Forskarna Thai Duong och Juliano Rizzo publicerade 2011 ett fungerande proof of concept mot TLS 1.0:s CBC-lägeschiffrar. TLS 1.0 använde det sista chiffertextblocket från den föregående posten som initialiseringsvektor för nästa, ett förutsägbart värde som lät en angripare som kunde injicera vald klartext (till exempel genom skadlig JavaScript i en webbläsare) återställa krypterade sessionscookies en byte i taget genom en blockvis attack med vald gräns. Den underliggande svagheten hade varit känd sedan 2002 och åtgärdades i TLS 1.1:s specifikation 2006, men BEAST bevisade att den var praktiskt utnyttjad, inte bara teoretiskt.
• POODLE (Padding Oracle vid nedgraderad äldre kryptering), CVE-2014-3566. Googleforskarna Bodo Moller, Thai Duong och Krzysztof Kotowicz avslöjade POODLE i oktober 2014. Attacken utnyttjar SSL 3.0:s CBC-lägesfyllning, vilket inte täcks av postens meddelandeautentiseringskod, så en man-in-the-middle-angripare som kan tvinga fram en nedgradering av protokollet till SSL 3.0 (många klienter vid den tiden skulle tyst försöka igen en misslyckad TLS-handskakning över SSL 3.0) kan dekryptera en byte av ett målblock per ungefär 256 förfrågningar, tillräckligt för att återställa sessionscookies och annan känslig data över upprepade anslutningar.

Utöver dessa två namngivna attacker tillåter äldre TLS-distributioner vanligtvis fortfarande svaga chiffersviter: RC4 (brutna av statistisk nyckelströmsbias och formellt förbjudna av RFC 7465), 3DES (sårbara för Sweet32-födelsedagsattacken, CVE-2016-2183, på grund av dess 64-bitars blockstorlek), och exportklassade chiffer som avsiktligt försvagats för att följa 1990-talets exportkontroller. Alla dessa som förhandlas fram i en handskakning, oavsett vilken protokollversion som bär dem, undergräver anslutningen. För en fullständig uppdelning av chiffersvitens komponenter och vilka som ska aktiveras, se vår tillhörande guide, En introduktion till chiffersviter.

Hur väljer du rätt TLS-protokoll och chiffersvit?

Välj TLS 1.3 som standard och TLS 1.2 som kompatibilitetsgolv och begränsa krypteringssviter till endast AEAD-alternativ; återaktivera aldrig TLS 1.0 eller TLS 1.1 för att hantera en enda äldre klient. Beslutet beror på tre frågor: vad din äldsta klient faktiskt kräver, vad ditt efterlevnadsramverk minst kräver och om din certifikatinfrastruktur och lastbalanserare kan avsluta TLS 1.3 utan en uppgradering av firmware eller programvara.

• Endast moderna miljöer (interna API:er, tjänst-till-tjänst-trafik, aktuella webbläsare): endast TLS 1.3, med dess tre definierade AEAD-sviter, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 och TLS_CHACHA20_POLY1305_SHA256.
• Offentliga tjänster med en bredare kundbas: TLS 1.2 och TLS 1.3 tillsammans, med TLS 1.2 begränsad till ECDHE-nyckelutbyte i kombination med AES-GCM eller ChaCha20-Poly1305, aldrig statiska RSA- eller CBC-lägessviter.
• Ett dokumenterat äldre undantag (en specifik företagsklient eller inbäddad enhet som verkligen inte kan uppgraderas): isolera den trafiken bakom en dedikerad, övervakad slutpunkt med minsta möjliga nedgradering, snarare än att öppna om gamla protokoll för varje klient.

NIST SP 800-52 Rev. 2, Riktlinjer för TLS-implementeringar , är den primära referens som federala och reglerade organisationer bör validera all konfiguration mot, och den kräver uttryckligen TLS 1.2 som minimum, där TLS 1.3 är att föredra.

Vad är hotmodellen för äldre TLS?

Den realistiska hotmodellen för äldre TLS är en man-in-the-middle-angripare, oftast på ett delat nätverk som offentligt Wi-Fi eller en komprometterad mellanliggande router, som tvingar fram en nedgradering av protokollet eller chifferet och sedan utnyttjar en känd svaghet i CBC-läge för att återställa sessionscookies eller inloggningsuppgifter. Detta är inte en risk som endast gäller för nationell stat. BEAST och POODLE hade båda offentlig, fungerande exploitkod kort efter avslöjandet, och nedgraderingsattacker riktar sig specifikt mot det faktum att många klienter historiskt sett försökte igen en misslyckad handskakning över ett äldre, svagare protokoll snarare än att misslyckas med att stänga.

• Vem utnyttjar detta: en angripare placerad mellan klienten och servern (en skadlig Wi-Fi-åtkomstpunkt, en komprometterad router eller en proxy av captive-portal-typ), inte en fjärrangripare utan nätverksposition.
• Vad som är i riskzonen: sessionscookies, autentiseringstokens och all data som överförs i den krypterade kanalen, återställd via samma padding-oracle- eller chosen-plaintext-mekanik som BEAST och POODLE demonstrerade.
• Varför det kvarstår: Organisationer som fortfarande stöder TLS 1.0/1.1 ”för kompatibilitet” håller nedgraderingsvägen öppen för alla klienter, inte bara den äldre klienten som förmodligen behöver den.

Föråldrade TLS-konfigurationer skapar också en falsk känsla av säkerhet: anslutningen visar fortfarande ett hänglås och krypterar fortfarande trafiken, så felläget är tyst tills en angripare med rätt nätverksposition faktiskt är närvarande.

Hur migrerar man från gamla TLS-versioner?

Migrera bort gamla TLS-versioner genom att först inventera varje slutpunkt, testa inaktiveringen i ett kontrollerat fönster, övervaka äldre nedfall före den slutliga övergången och inaktivera gamla protokoll helt istället för att lämna dem aktiverade som reserv. Följ dessa steg i ordning:

1. Inventera varje TLS-slutpunkt. Upptäck varje server, lastbalanserare, API-gateway och inbäddad enhet som avslutar TLS. En enhet som ingen kommer ihåg är den vanligaste källan till en migreringsincident, inte de system som redan finns i ändringskalendern.
2. Identifiera vilket protokoll och vilken krypteringssvit varje slutpunkt förhandlar om för närvarande. Använd ett TLS-skanningsverktyg eller serveråtkomstloggar för att se vad klienter faktiskt förhandlar om idag, inte bara vad konfigurationsfilen påstår är aktiverat.
3. Identifiera vilka verkliga klienter som fortfarande är beroende av TLS 1.0/1.1. Korsreferera loggar mot din faktiska användarbas eller enhetsflotta. Det här steget avgör om ett äldre undantag verkligen behövs eller om antagandet att "någon fortfarande behöver det" är föråldrat.
4. Iscensätt förändringen i en test- eller kanariemiljö. Inaktivera TLS 1.0/1.1 och svaga chiffersviter på en delmängd av trafiken eller en icke-produktionsmiljö först, och övervaka felfrekvensen innan du vidrör produktionstrafik i stor utsträckning.
5. Lansering med övervakning, inte tystnad. Håll noga koll på andelen misslyckade handskakningar och supportärenden under övergångsperioden; en topp identifierar en legitim äldre klient som du missade i steg 3.
6. Inaktivera gamla protokoll och chiffersviter helt. Lämna inte TLS 1.0/1.1 konfigurerat som en inaktiverad men närvarande reservfunktion; ta bort konfigurationen helt så att en framtida felkonfiguration inte kan återaktivera den i tysthet.
7. Verifiera igen enligt ett återkommande schema. Webbläsarens standardinställningar, klientbibliotek och efterlevnadskrav ändras över tid; skanna om din TLS-konfiguration minst en gång per år, inte bara under den första migreringen.

Vilka är avvägningarna mellan prestanda och interoperabilitet?

Att migrera till TLS 1.2/1.3 förbättrar både säkerhet och prestanda för den överväldigande majoriteten av klienterna, men en liten population av genuint gamla enheter kommer inte att kunna ansluta, och det är den verkliga avvägningen att planera för snarare än att undvika.

• Prestandavinst: TLS 1.3 reducerar handskakningen till en enda tur och retur (jämfört med två för TLS 1.2) och stöder 0-RTT-sessionsåterupptagning, vilket mätbart minskar anslutningslatensen, särskilt på mobilnätverk med hög latens.
• Kostnad för interoperabilitet: Företagsmellanboxar, vissa äldre mobila operativsystem och äldre IoT- eller industriella enheter kan bara hantera TLS 1.0/1.1 eller CBC-lägespaket. Dessa klienter kommer att ha ett hårdfel när gamla protokoll inaktiveras, inte att försämras smidigt.
• Reducering av attackyta: Varje äldre protokoll eller chiffersvit som hålls aktiverad är ytterligare en nedgraderingsväg som en angripare kan tvinga fram, och varje bibliotek som stöder det är ytterligare en kodbas som behöver patchas mot framtida sårbarheter.

Det praktiska svaret är inte ”aldrig förstöra någonting”, det är ”bryta den minsta, tydligast identifierade populationen på kortast acceptabla tidslinje”, med hjälp av inventerings- och övervakningsstegen ovan för att göra populationen liten och känd snarare än en överraskning.

Vilka nyckelhanteringsberoenden påverkar en TLS-migrering?

En migrering av TLS-protokoll är beroende av certifikat- och nyckelinfrastruktur som är lätt att förbise tills den blockerar övergången: certifikatnyckeltyp, tillgänglighet för hårdvarusäkerhetsmodul (HSM) och det accelererande certifikatgiltighetsschemat begränsar alla hur och när du kan flytta.

• Certifikatnyckeltypen måste matcha de krypteringssviter som du avser att aktivera. ECDSA-krypteringssviter kräver ett ECDSA-certifikat, och RSA-krypteringssviter kräver ett RSA-certifikat; en server som bara utfärdar en certifikattyp spärrar tyst ute klienter som behöver den andra.
• Utfärdande av certifikat för HSM och tillgänglighetsportar för nyckelceremonier. Om din certifikatutfärdare signerar från en HSM, blockerar en stoppad nyckelceremoni eller en otillgänglig HSM förnyelsen eller återutgivningen som en migrering är beroende av, lika effektivt som ett glömt utgångsdatum.
• Certifikatens livslängd krymper, vilket ökar insatserna med manuell spårning. Enligt CA/Browser Forums SC-081v3-schema sjunker den maximala giltighetstiden för publika TLS-certifikat från 398 dagar till 200 dagar från och med den 15 mars 2026, till 100 dagar från och med den 15 mars 2027 och till 47 dagar från och med den 15 mars 2029. En migreringsplan som förutsätter årlig certifikatrotation kommer inte att överleva det schemat; automatiserad identifiering och förnyelse blir en förutsättning, inte en valfri förbättring.
• Kedjans fullständighet är lika viktig som protokollversionen. En server som bara installerar sitt lövcertifikat utan det mellanliggande CA-certifikatet kommer att misslyckas med handskakningar av skäl som inte är relaterade till protokollversionen, och det felet är lätt att feldiagnostisera som ett migreringsproblem istället för ett kedjeproblem. Vår kompletterande guide om diagnostisera SSL-handskakningsfel täcker exakt hur man skiljer de två åt med openssl s_client.

Hur ser verkliga TLS-migreringsdistributioner ut?

Tre distributionsmönster dyker upp upprepade gånger i TLS 1.0/1.1-utfasningsprojekt, vart och ett med en annan begränsning som styr tidslinjen:

• Webbapplikationer och CDN:er för allmänheten rör sig generellt snabbast, eftersom de flesta CDN:er och moderna webbläsare redan som standard vägrar TLS 1.0/1.1. Det huvudsakliga implementeringsarbetet är att bekräfta att ursprungsservrarna bakom CDN:et är lika härdade, eftersom ett CDN kan maskera en svag ursprungskonfiguration.
• Interna företagsapplikationer och API:er gå långsammare, eftersom äldre mellanprogramvara, äldre lastbalanserare och internt byggda klienter ofta skrevs mot det TLS-bibliotek som levererades med en gammal applikationsserver, och att identifiera varje internt beroende tar längre tid än det externt inventeringssteget.
• Betalnings- och kassasystem (POI) arbeta under en uttrycklig efterlevnadsfrist: PCI DSS har krävt en övergång till en säker version av TLS sedan den 30 juni 2018, med ett snävt, verifierbart undantag för POI-terminaler som bekräftats inte vara mottagliga för kända SSL/tidiga TLS-attacker. Dessa miljöer bör behandla migrering som ett efterlevnadsprojekt med en revisionslogg, inte en infrastrukturförändring som sker efter bästa förmåga.

Vilken TLS-version ska du egentligen köra?

Tabellen nedan mappar varje TLS/SSL-version som använts tidigare till dess nuvarande status, dess kända sårbarheter och rekommendationen för produktionsanvändning.

Version	Status	Kända sårbarheter	Rekommendation
SSL 2.0	Föråldrad (länge tillbakadragen)	Grundläggande protokolldesignbrister; inget meningsfullt integritetsskydd	Tillåt aldrig under några omständigheter
SSL 3.0	fasats	POODLE (CVE-2014-3566), CBC-utfyllnadsorakel	Tillåt aldrig under några omständigheter
TLS 1.0	Formellt avskrivet (RFC 8996, mars 2021)	BEAST (CVE-2011-3389), SHA-1-beroende handskakning, inget AEAD-stöd	Inaktivera; PCI DSS har förbjudit det sedan juni 2018
TLS 1.1	Formellt avskrivet (RFC 8996, mars 2021)	SHA-1-beroende handskakning, inget AEAD-stöd	Inaktivera; inget regelverk för efterlevnad accepterar det som ett minimum
TLS 1.2	Nuvarande, brett stöd	Inget som är inneboende i protokollet när det konfigureras med endast AEAD-krypteringssviter	Acceptabel kompatibilitetsgolv; begränsa till ECDHE-nyckelutbyte med AES-GCM eller ChaCha20-Poly1305
TLS 1.3	Nuvarande, rekommenderad standard	Inga kända; tar bort CBC-lägeschiffer och statiskt RSA-nyckelutbyte helt	Standard för alla nya distributioner och där klientbasen stöder det

Begränsningar

• Den här guiden täcker risker på protokollnivå och krypteringssvitnivå i TLS 1.0/1.1; den täcker inte sårbarheter på applikationslagret i en specifik TLS-biblioteksimplementering, vilka kräver egen patchspårning oberoende av protokollversion.
• Att inaktivera gamla protokoll minskar risken men eliminerar inte all TLS-relaterad exponering; en korrekt konfigurerad TLS 1.3-slutpunkt är fortfarande beroende av ett giltigt, icke-komprometterat certifikat och en privat nyckel som inte har exponerats.
• Efterlevnadskraven varierar beroende på ramverk och jurisdiktion; validera eventuella protokoll- eller chifferändringar mot dina specifika PCI DSS-, HIPAA- eller FIPS 140-3-skyldigheter innan driftsättning, eftersom undantag (som det snäva undantaget för POI-terminaler under PCI DSS) är villkorade, inte automatiska.
• Migreringstidslinjerna beror starkt på hur mycket äldre infrastruktur en organisation har ackumulerat; stegen ovan beskriver rätt sekvens, inte en fast varaktighet.

Vad skulle krypteringskonsulter rekommendera?

Vi skulle först behandla en kvarvarande TLS 1.0/1.1-slutpunkt som ett synlighetsproblem för certifikat och konfiguration, inte bara en inställningsändring. I våra samarbeten har organisationer som fortfarande kör tidig TLS nästan aldrig avsett att göra det; de saknar helt enkelt en enda, aktuell inventering av varje certifikat och TLS-slutpunkt i sin miljö, så en äldre konfiguration överlever obemärkt i åratal. CertSecure Manager upptäcker automatiskt varje certifikat och protokoll-/chiffreringskonfigurationen bakom det i din miljö, flaggar allt som fortfarande förhandlar om TLS 1.0/1.1 eller svaga chiffersviter och automatiserar förnyelse så att det krympande certifikatgiltighetsfönstret (på väg till 47 dagar år 2029) inte blir sin egen avbrottskälla. För organisationer som bygger om eller stärker certifikatutfärdarinfrastrukturen som utfärdar dessa certifikat från första början, utformar vårt PKI Services- team CA-hierarkin, nyckelhanteringspraxis och HSM-baserad signeringsinfrastruktur som håller certifikatutfärdande tillgängligt genom en migrering istället för att bli sin egen flaskhals. Börja med inventeringssteget i den här guiden; Om gamla protokoll eller svaga krypteringssviter dyker upp någonstans, är det signalen att få certifikat- och TLS-konfigurationssynlighet under ett program istället för att uppdatera slutpunkter en i taget.

Slutsats

TLS 1.0 och TLS 1.1 är inte bara föråldrade, de är formellt utfasade enligt RFC 8996 och har namngivna, offentligt demonstrerade attacker (BEAST och POODLE) mot de CBC-lägeschiffer som båda versionerna är beroende av. Att köra dem idag ger en falsk känsla av säkerhet: anslutningen visar fortfarande ett hänglås samtidigt som den kan utnyttjas av en angripare i rätt nätverksposition. Byt till TLS 1.2 som kompatibilitetsgolv och TLS 1.3 som standard, begränsa chiffersviter till endast AEAD-alternativ och behandla migreringen som ett certifikat- och nyckelhanteringsprojekt, inventera först, testa och övervaka innan övergång, och inaktivera sedan gamla protokoll helt istället för att lämna dem som en tyst reservlösning.

Vanliga frågor om partihandel med mat och dryck

Används TLS 1.0 fortfarande någonstans idag? Sällan, och bara där det inte borde användas. Vissa äldre inbyggda enheter, äldre mellanprogram för företag och opatchade system förhandlar fortfarande om TLS 1.0, men alla större webbläsare och CDN vägrar det som standard, och RFC 8996 avfärdade det formellt i mars 2021. Alla produktionssystem som fortfarande accepterar det bör behandlas som ett fynd, inte ett konfigurationsval.

Vad är den verkliga skillnaden mellan TLS 1.2 och TLS 1.3? TLS 1.3 tar helt bort CBC-lägeschiffer, statiskt RSA-nyckelutbyte och icke-AEAD MAC-konstruktioner, så varje TLS 1.3-handskakning är framåtriktad hemlig och AEAD-skyddad av designen. TLS 1.2 kan konfigureras lika säkert, men bara om du uttryckligen begränsar det till ECDHE-nyckelutbyte med AES-GCM eller ChaCha20-Poly1305 och inaktiverar de svagare alternativ som protokollet fortfarande tillåter.

Kan jag låta TLS 1.1 vara aktiverat för bara en äldre klient? Nej. Om du aktiverar TLS 1.1 var som helst på en server öppnas nedgraderingsvägen för varje klient som ansluter till den, inte bara den du avsåg att hantera. Om det finns en äldre klient som verkligen inte stöds, isolera den bakom en dedikerad, övervakad slutpunkt istället för att försvaga den primära tjänsten.

Påverkar inaktivering av gamla TLS-versioner PCI DSS-efterlevnaden? Att inaktivera TLS 1.0 och TLS 1.1 är vad PCI DSS-efterlevnad kräver, inte en risk för den. PCI DSS har krävt en övergång till en säker version av TLS sedan den 30 juni 2018, med endast ett smalt, verifierbart undantag för POI-terminaler som visat sig immuna mot kända SSL/tidiga TLS-attacker.

Hur lång tid tar en typisk migrering av TLS-protokoll? Det beror nästan helt på hur komplett ert certifikat- och slutpunktsinventering är. Organisationer med automatiserad certifikatidentifiering kan ofta genomföra och slutföra en migrering på några veckor; organisationer som upptäcker slutpunkter manuellt, eller hittar äldre enheter som de inte visste var TLS-avslutande, bör förvänta sig att inventeringsfasen ensam tar längre tid än den faktiska protokolländringen.

Referensprojekt

• RFC 8996: Avveckling av TLS 1.0 och TLS 1.1, IETF
• RFC 8446: Transport Layer Security (TLS)-protokollet version 1.3, IETF
• CVE-2011-3389: BEAST-konceptbevisoch Hur BEAST-attacken fungerar, Invicti
• POODLE: En SSL 3.0-sårbarhet (CVE-2014-3566), Röd hatt
• Migrera från SSL och tidig TLS, PCI:s säkerhetsstandardråd
• SP 800-52 Rev. 2, Riktlinjer för TLS-implementeringar, NIST CSRC
• Omröstning SC-081v3: Inför ett schema för att minska giltigheten och återanvändningsperioder för data, CA/Webbläsarforum