IETF zakázal v TLS 1.2 výměnu klíčů přes RSA i konečná tělesa, IANA přeznačila 222 sad

Výměna klíčů je ta část pozdravu TLS, ve které se klient se serverem domluví na tajemství, kterým pak šifrují vlastní přenos. V TLS 1.2 se na to dá použít několik postupů a dva z nich jsou od července zavržené: výměna klíčů přes RSA a Diffieho–Hellmanova výměna nad konečným tělesem, tedy nad obyčejnými čísly místo nad eliptickou křivkou. Píše to RFC 10015, dokument standardizační řady, který nese datum červenec 2026 a v datatrackeru IETF je jako RFC vedený od 16. července.

Co dokument zakazuje a co jen nedoporučuje

Dotčené postupy jsou rozdělené do čtyř skupin. Tři z nich dokument zakazuje slovem MUST NOT, tedy nejsilnějším, jaké normy IETF mají: klient je nesmí nabídnout a server vybrat. Jde o Diffieho–Hellmana nad konečným tělesem s jednorázovými klíči, tentýž postup s trvalými klíči a výměnu klíčů přes RSA. Čtvrtá skupina, statické ECDH nad eliptickou křivkou, dostala mírnější SHOULD NOT, které dovoluje výjimku, když pro ni má provozovatel důvod.

K tomu přibylo doporučení nepoužívat certifikáty s pevnými parametry Diffieho–Hellmana. Týká se to čtyř typů, které se v pozdravu ohlašují jménem: rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh a ecdsa_fixed_ecdh. Dokument je vypisuje výslovně proto, aby se variantám s trvalými klíči zavřela i tahle cesta.

Rozsah zásahu je vidět na seznamu měněných dokumentů. RFC 10015 aktualizuje sedmnáct starších RFC, mezi nimi i samotnou specifikaci TLS 1.2 a specifikaci DTLS 1.2, na kterou se všechna pravidla vztahují také.

U RSA se táž chyba vrací každých pár let

Důvody dokument vypisuje odděleně. Výměně klíčů přes RSA vytýká tři věci. Nemá dopřednou bezpečnost, takže kdo dnes zaznamená provoz a za pět let se dostane k soukromému klíči serveru, přečte si i ten starý provoz. Bývá zranitelná Bleichenbacherovým útokem, a hlavně: obrana proti němu se implementuje těžko, takže se varianty téhož útoku podle dokumentu objevují každých pár let. Jmenovitě odkazuje na ROBOT z roku 2018 a na DROWN z roku 2016.

Třetí výtka je nenápadná a přitom nejnepříjemnější. TLS 1.2 nemá jak oddělit klíče podle použití, takže jediný zranitelný koncový bod ohrožuje všechny ostatní, které sdílejí týž klíč RSA. Přesně na tom stál DROWN: stačil starý server s SSLv2 a padly i moderní služby se stejným certifikátem.

Skupinu si vybírá server a klient s tím nic nezmůže

U Diffieho–Hellmana nad konečným tělesem je seznam delší. Chybí mechanismus, kterým by se strany na skupině čísel domluvily, takže ji volí server. Vlastní, nestandardní skupiny jsou přitom rozšířené, protože se to doporučovalo v návodech, které vznikly po útoku Logjam. Klient tedy dostane skupinu, o které nemůže rozumně ověřit, jestli nemá malé podgrupy, a nemá ani jak požádat o jinou. Odmítnout všechny vlastní skupiny prakticky nejde.

K tomu se přidává velikost. Někteří provozovatelé podle dokumentu používají skupinu o 1 024 bitech, protože je to největší velikost, se kterou se domluví kdekdo. Proti současnému rekordu ve výpočtu diskrétního logaritmu je to tenká rezerva: ten rekord dokument uvádí na 795 bitů a odkazuje na práci z roku 2020, novější číslo v seznamu pramenů není. A protože se u standardizovaných skupin dá největší část výpočtu udělat jednou a pak ji použít opakovaně, stačí podle dokumentu hrstka velkých výpočtů na to, aby šla dešifrovat poměrně velká část provozu chráněného právě těmi skupinami.

Poslední důvod dal celé věci jméno. Útok Raccoon ze září 2020 ukázal, že z časování při zpracování předběžného hlavního tajemství, tedy hodnoty, ze které se odvozují šifrovací klíče spojení, se dá tahle hodnota odhalit. V poděkování stojí, že dokument vznikl z diskuse na seznamu pracovní skupiny a z podnětu Filippa Valsordy právě po zveřejnění Raccoonu.

V rejstříku IANA přibylo 222 písmen D

Nejlépe je změna vidět na rejstříku šifrovacích sad TLS, který vede IANA. Ve strojovém výpisu má k 1. srpnu 2026 přesně 222 položek, u kterých je RFC 10015 uvedené jako pramen, a všechny mají ve sloupci Recommended písmeno D. To podle RFC 9847 znamená, že se od dané položky odrazuje. Ke strojovému čtení je připravený i rejstřík typů obsahu, kam nedávno přibyl protobuf.

Rozpad podle tabulek v dokumentu vypadá takhle: zakázaných je 62 sad s trvalými klíči nad konečným tělesem, 69 s jednorázovými a 52 s výměnou přes RSA; zbylých 39 sad se statickým ECDH je jen nedoporučených. Dohromady 222, což s výpisem IANA sedí. Rejstřík má přitom celkem 356 šifrovacích sad, z toho 248 s písmenem D, 94 s N a čtrnáct s Y, tedy doporučených. Skoro devět desetin všech odrazovaných záznamů má tak na svědomí jediný dokument.

Co se mění v BCP 195

Praktickým adresátem změny je RFC 9325, tedy ta část BCP 195, kterou si provozovatelé otevírají, když nastavují server. RFC 10015 v ní mění čtyři řádky a vypisuje je v přehledné tabulce. Diffie–Hellman nad konečným tělesem s trvalými klíči, tentýž postup s jednorázovými a statické RSA se posouvají ze SHOULD NOT na MUST NOT. Certifikáty s pevnými parametry Diffieho–Hellmana v BCP 195 dosud řešené nebyly, nově je na ně SHOULD NOT. Statické ECDH zůstává beze změny a vše ostatní v BCP 195 platí dál.

Čtyři roky a měsíc od konceptu k RFC

Cesta byla dlouhá i na poměry IETF. Historie v datatrackeru začíná u dvou samostatných konceptů z počátku roku 2022; ten o zavržení skupin nad konečným tělesem je v datatrackeru vedený od 31. ledna 2022. V polovině června 2022 je pracovní skupina spojila do jednoho a od té chvíle uplynuly do vydání čtyři roky a měsíc.

Jako autor je uvedený Nimrod Aviram a v seznamu pramenů se jeho jméno objevuje dvakrát: u Raccoonu i u DROWN. V poděkování se píše, že velkou část textu napsala Carrie Bartle a první koncept sepsal Christopher A. Wood.

Kolik toho zbývá

Kolik serverů se změna dotkne, dokument neuvádí a přesné číslo se hledá špatně. Nejbližší veřejný údaj má přehled SSL Pulse od Qualysu, jenže jeho poslední zveřejněné měsíční měření je z 2. června 2025. Tehdy ze 134 380 prohlédnutých webů 256 nepodporovalo dopřednou bezpečnost vůbec, tedy dvě desetiny procenta, a dalších 6 629 jen zčásti. Ostatní ji zvládaly aspoň s běžnými prohlížeči.

Podle nás z toho plyne, že dokument nic nebourá, jen dopisuje, co se v praxi stalo. Zakázané sady většina serverů dávno nenabízí a prohlížeče je nenabízejí taky. Cena je jinde: dokud je položka v rejstříku bez značky, dá se leckde obhájit jako povolená, a kdo dnes nastavuje starší zařízení nebo píše vlastního klienta, má konečně jednu adresu, na kterou může ukázat.

Na TLS 1.3 se nic z toho nevztahuje. Statické RSA ani Diffieho–Hellmana nad konečným tělesem s trvalými klíči verze 1.3 nezná a variantu s jednorázovými klíči má postavenou tak, že popsané potíže nemá; dokument u ní výslovně říká, že se nabízet smí. TLS 1.0 a 1.1 zakázalo celé už RFC 8996 z března 2021.

Zdroje: RFC 10015 Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2, rejstřík šifrovacích sad TLS u IANA, historie konceptu v datatrackeru IETF, RFC 9325 (BCP 195) a SSL Pulse.