TLS 1.2 får ingen uppdatering när IETF fryser standarden

I juli 2026 publicerade IETF:s TLS-arbetsgrupp RFC 9851, som sätter TLS 1.2 i så kallad feature freeze. Inga nya cipher suites, inga nya extensions, inget stöd för post-quantum-kryptografi. Standarden är inte förbjuden och det finns inget slutdatum men den slutar utvecklas. Vill du ha nya funktioner i din TLS-stack framåt behöver du TLS 1.3.

Bakom dokumentet står Rich Salz och Nimrod Aviram, samma två personer som samtidigt lade fram RFC 10015 med förslag på att fasa ut RSA och DHE i TLS 1.2 och bara behålla ECDHE.

Fyra saker får fortfarande ändras i TLS 1.2

En feature freeze är inte samma sak som att specifikationen läses ner. RFC 9851 räknar upp exakt vad som fortfarande får passera och listan är kort: brådskande säkerhetsfixar (efter konsensus i arbetsgruppen), redaktionella förtydliganden i texten, nya TLS Exporter Labels och nya ALPN-identifikatorer så att kommande applikationsprotokoll kan förhandlas över TLS 1.2.

Allt annat är stängt. Så här ser skillnaden ut mot TLS 1.3:

Raden om post-quantum är den som betyder mest på sikt. Arbetet med kvantsäkra nyckelutbyten pågår i IETF:s PQUIP-arbetsgrupp och resultatet landar i TLS 1.3 och senare versioner. Behöver din organisation kvantsäker transportkryptering är migrationen inte längre en preferensfråga, den är enda vägen.

DTLS är inte med i frysen

RFC 9851 gäller TLS och bara TLS. DTLS, varianten som körs över UDP och används i WebRTC, VoIP och andra latenskänsliga sammanhang, har en egen utvecklingscykel och påverkas inte. Har du DTLS 1.2 i produktion behöver du inte agera på det här beslutet.

Vad du behöver göra i praktiken

Kort svar: mät först, migrera sedan. De flesta moderna miljöer förhandlar redan TLS 1.3 automatiskt när både klient och server stöder det och då är arbetet i huvudsak gjort utan att någon märkte det.

Börja med att titta i loggarna på vilken TLS-version dina anslutningar faktiskt landar på, uppdelat per klienttyp. Det är där du hittar problemen: gamla Java-runtimes, inbyggda enheter, betalterminaler, industriella styrsystem och integrationer mot partners som inte rört sin stack sedan 2015. Serversidan är sällan flaskhalsen. En nginx eller en OpenSSL som är någorlunda aktuell klarar TLS 1.3 direkt.

Nästa steg är att gå igenom vad som är hårdkodat. Cipher suite-listor i konfigurationsfiler brukar vara skrivna för TLS 1.2 och innehåller namn som inte betyder något i TLS 1.3, där sviterna heter något helt annat och nyckelutbytet konfigureras separat. Kopierar du en gammal ciphersträng rakt in i en ny konfiguration får du antingen ett fel eller ett sämre resultat än standardinställningen.

Sist: bestäm ett datum. Flera stora leverantörer och plattformar har redan satt slutdatum för TLS 1.2 i sina tjänster, bland dem Azure, Auth0, Mixpanel och Frankfurtbörsens derivatplattform Eurex. Tyska BSI pekar ut 2031 som målår i sitt tekniska ramverk och franska ANSSI har rekommenderat TLS 1.3 i flera år. Ingen svensk myndighet har satt ett hårt datum men om dina motparter i Europa gör det spelar det mindre roll.

Historiken säger att det här tar tio år

Mönstret från TLS 1.0 och 1.1 är tydligt. Först freeze, sedan att webbläsarna slutar förhandla protokollet, sist att stödet tas bort ur bibliotek och operativsystem. Mellan första och sista steget gick det ungefär ett decennium.

Det talar för att TLS 1.2 kommer att fungera i produktion långt efter 2030. Det talar också för att den som väntar hamnar i den svåraste delen av migrationen, den där systemen är gamla nog att inte gå att uppdatera och unga nog att inte gå att stänga av. Industriell IoT och inbyggda system pekas ut som de långsammaste punkterna, precis som förra gången.

För dig som bygger webb i dag är åtgärden liten. Kolla att din server har TLS 1.3 påslaget, rensa cipher-konfigurationen från kopierade rader du inte förstår och slå på HSTS om det inte redan är gjort. Vill du testa hur handshake och certifikat ser ut i din egen trafik finns vårt IP- och nätverksverktyg och för nyckel- och hashexperiment på skrivbordet fungerar hashverktygen.

FAQ

Slutar TLS 1.2 fungera nu?

Nej. RFC 9851 innehåller inget slutdatum och förbjuder ingenting. Anslutningar över TLS 1.2 fortsätter fungera precis som förut.

Kan jag fortfarande få säkerhetsuppdateringar till TLS 1.2?

Ja. Brådskande säkerhetsfixar är uttryckligen undantagna från frysen men de kräver konsensus i IETF:s TLS-arbetsgrupp. Det som stoppas är nya funktioner, inte reparationer av allvarliga brister.

Varför får TLS 1.2 inte post-quantum-kryptografi?

Handskakningen i TLS 1.2 är byggd på ett annat sätt, med fler klartextdelar och en nyckelutbytesmodell som skulle behöva byggas om från grunden för att bära kvantsäkra algoritmer. Arbetsgruppen har valt att lägga arbetet där det ger effekt i stället, det vill säga i TLS 1.3 och framåt. Praktiskt betyder det att kvantsäker trafik kräver migration.

Påverkas WebRTC av beslutet?

Nej. WebRTC använder DTLS, som har en egen specifikation och en egen utvecklingscykel och som inte omfattas av RFC 9851.

Var hittar jag RFC-texten och villkoren för att återanvända den?

Alla RFC:er publiceras öppet av IETF och villkoren för att citera och återanvända dokumenten framgår av IETF Trusts licensinformation.