Přeskočit na obsah
Magazín Chatujme.cz
Internet a sítě · čtení na 3 min

Nové protokoly nad TLS musí vyžadovat rovnou 1.3. Na DTLS se to nevztahuje

Kdo dnes navrhuje nový protokol postavený na TLS, musí v něm vyžadovat verzi 1.3. Starší 1.2 smí zůstat nanejvýš jako nevýchozí možnost pro nasazení, které si to vynutí. Na DTLS se pravidlo nevztahuje v žádné jeho verzi, protože DTLS 1.3 se zatím tolik nepoužívá.

IETF vydala v červenci 2026 dokument RFC 9852 s názvem New Protocols Using TLS Must Require TLS 1.3. Je to Best Current Practice, tedy doporučený postup se závaznou formulací, a spadá pod označení BCP 195. Podepsaní jsou Rich Salz z Akamai Technologies a Nimrod Aviram; dokument vznikl z návrhu draft-ietf-uta-require-tls13.

Propojovací panel v serverové skříni s množstvím síťových kabelů
Propojovací panel v serverové skříni. Foto: Andrew Hart, Wikimedia Commons (CC BY-SA 2.0)

Dvě věty, které se přepsaly

Dokument nepřináší nový protokol ani nové šifry. Mění dvě konkrétní věty v oddílu 3.1.1 staršího RFC 9325 z listopadu 2022, které dosud popisovalo, jak TLS bezpečně nasazovat:

  • místo „TLS 1.3 SHOULD být podporováno“ nově platí, že u nových protokolů nad TLS MUSÍ být podporováno,
  • a místo „TLS 1.2 MUSÍ být podporováno“ nově platí, že SMÍ být podporováno.

Velká písmena tu nejsou pro důraz. Slova MUST, MAY nebo SHOULD mají v dokumentech IETF přesně dohodnutý význam podle RFC 2119, takže záměna jednoho za druhé je celá změna normy.

Pro nasazení, kde by samotné TLS 1.3 nestačilo, zůstává průchod: nový protokol smí uvést TLS 1.2 jako doplňkovou možnost, ale nesmí být výchozí.

Proč se to netýká DTLS

Výjimka je v dokumentu hned v prvním odstavci a týká se všech verzí DTLS, tedy varianty TLS pro nespolehlivý přenos. Důvod je prostý: DTLS 1.3 zatím není široce dostupné ani nasazené, takže by pravidlo požadovalo něco, co se nedá splnit. Kdo tedy navrhuje nový protokol nad DTLS, řídí se dál doporučeními z RFC 9325.

Čím TLS 1.2 zestárlo

Bezpečnostní oddíl dokumentu jmenuje konkrétní slabiny, kvůli kterých se starší verze opouští. Samo RFC k nim dodává, že TLS 1.2 se nastavit bezpečně dá – jen je to podstatně těžší než u nástupce.

Bez rozšíření je TLS 1.2 zranitelné vůči útokům na opětovné vyjednání spojení a vůči útoku Triple Handshake; útočník při nich vloží do přenášeného textu předponu podle svého výběru. Obrana existuje od RFC 5746, ale musí se zapnout, nebo se opětovné vyjednávání musí vypnout úplně.

Původní způsoby výměny klíčů, tedy výměna přes RSA a Diffieho–Hellmanův postup nad konečnými tělesy, mají vlastní potíže. Ze symetrických šifer dokument jmenuje RC4, jehož proud klíče má využitelné odchylky (RFC 7465), a sady s režimem CBC. U nich stojí za pozornost jedna věta: první pokus naprogramovat je tak, aby trvaly vždy stejně dlouho, zavedl ještě horší zranitelnost, než jakou měl odstranit.

K tomu dokument řadí útoky BEAST, Logjam, FREAK a SLOTH, vůči kterým je TLS 1.3 odolné. A poslední bod se nastavením vyřešit nedá vůbec: zatímco vlastní přenášená data TLS 1.2 šifruje vždy, většina obsahu úvodního vyjednávání zůstává čitelná.

Kvantové počítače jako důvod navíc

Dokument uvádí ještě jeden důvod, tentokrát mířící dopředu. Pracovní skupina pro TLS soustředí své úsilí na verzi 1.3 a novější a TLS 1.2 už rozvíjet nebude – samostatně to konstatuje RFC 9851, vydané rovněž v červenci 2026 týmiž autory. Postkvantová kryptografie se tedy standardizuje jen pro TLS 1.3, a nový protokol, který by trval na 1.2, by se k ní nedostal.

Kdy přesně bude kvantový počítač schopný prolomit dnešní šifry k dispozici, dokument neřeší a výslovně to odsouvá mimo svůj záběr.

Jak to vypadá v hotových protokolech

RFC 9852 ukazuje obě krajní polohy na existujících specifikacích. QUIC vyžaduje TLS 1.3 a předepisuje, že koncový bod musí spojení ukončit, pokud protistrana použije starší verzi. Naopak profil pro DNS přes TLS uvádí jako výchozí TLS 1.2 a 1.3 pouze připouští; u nových specifikací se má tohle pořadí obrátit.

Praktický dopad má i rada pro klienty. Když knihovna umí vyjednat verzi a vybere nejvyšší, kterou obě strany zvládnou, má klient uvést jen tu nejnižší verzi, se kterou je ochoten mluvit – a tou má být podle okolností TLS 1.3, nebo TLS 1.2.

Mimochodem, v seznamu odkazů se skrývá ještě jedna změna: TLS 1.3 už se necituje jako RFC 8446, ale jako RFC 9846 z července 2026.

Zdroje

Diskuse

Zatím tu nikdo nediskutuje. Můžete být první.

Napsat příspěvek

Diskutovat můžete i bez účtu. S registrací se ale příspěvek zveřejní hned a nemusíte pokaždé vyplňovat jméno. Účet už máte? Přihlaste se.

Nezveřejňujeme ho, slouží jen redakci.

Podporuje zápis Texy: **tučně**, *kurzíva*, odrážky, odkazy.

Dál k tématu

Internet a sítě

Ve frontě RIPE na adresy IPv4 stojí 748 zájemců, ten první čeká 457 dní

Evropský registr internetových čísel rozdává poslední adresy IPv4 z čekací listiny. K 1. srpnu 2026 na ní stálo 748 místních registrů a ten na jejím čele čekal 457 dní. Odměnou je jediný blok o 256 adresách, a dostane ho jen ten, kdo od RIPE nikdy žádnou nedostal.

Internet a sítě

Norma pro Wi-Fi 8 došla k druhému návrhu. Schválit se má podle plánu až v roce 2028

Skupina IEEE, která píše doplněk 802.11bn, dala v Montrealu dohromady druhý návrh a odsouhlasila třicetidenní hlasování o něm. Konečné schválení má plán skupiny až na květen 2028, zatímco čip nabízený pod jménem Wi-Fi 8 už podle Broadcomu v květnu putoval ke zkouškám u operátorů. Samo to jméno se na přehledové stránce skupiny nevyskytuje ani jednou.

Internet a sítě

Nová norma DNS dovoluje přiobjednat další typy záznamů. Dvě starší cesty selhaly

Kdo chce k doméně adresu IPv4, IPv6 a záznam HTTPS, musí se dnes ptát třikrát. Norma RFC 10029 z července 2026 přidává do DNS dvojici voleb, kterými si klient k požadovanému typu záznamu přiobjedná další. Obě starší cesty k témuž skončily špatně: víc otázek v jednom paketu protokol formálně uměl, ale v praxi to nefungovalo, a dotaz ANY nezaručuje vůbec nic.

Internet a sítě

IMAP se naučil rozdělit schránku na dávky. Nové RFC míří na schránky se statisíci zpráv

Klient, který chce projít schránku se sto tisíci zprávami, si dosud musel rozsahy vymýšlet sám. Rozšíření UIDBATCHES z července 2026 nechá tuhle práci na serveru: klient řekne, jak velké dávky chce, a dostane hotové rozsahy. Od prvního návrhu k normě to trvalo dvacet měsíců a pracovní skupina za tu dobu vydala dvaadvacet revizí textu.