Hlavní navigace

TLS 1.3 plné novinek: vylepšená bezpečnost a vyšší rychlost

4. 9. 2019
Doba čtení: 5 minut

Sdílet

 Autor: Depositphotos
Kryptografický protokol Transport Layer Security (TLS) se v poslední verzi 1.3 zásadně proměnil. Došlo k odstranění některých funkcí a k zavedení úplné novinky, 0-RTT. Co ale tyto změny přesně znamenají?

Komunikace na internetu je nejčastěji chráněna pomocí kryptografického protokolu TLS, využívaného pro šifrování spojení webových stránek, elektronické pošty ad. Historie protokolu začíná v roce 1999, kdy bylo TLS poprvé představeno.

Jeho novější verze TLS 1.1 přišla v roce 2006, dosud nejpoužívanější TLS 1.2 se objevilo v roce 2008 a po více jak deseti letech byl schválen nový RFC 8446 přinášející TLS 1.3. Jeho hlavním cílem je vylepšit bezpečnost a rychlost šifrování.

Účinnější ochrana

Pro zajištění větší bezpečnosti došlo v rámci výměny klíčů k odstranění podpory algoritmu RSA, který byl vyhodnocen jako slabý. Důvodem byla především nepřítomnost perfect forward secrecy, takže v případě, že útočník získal privátní klíč serveru, dokázal dešifrovat obsah předchozí komunikace.

Skončila podpora používání blokových šifer v režimu CBC a blokové šifry 3DES, proudové šifry RC4, hašovací funkce SHA-1, SHA-224, MD5 a dalších funkcí v minulosti zodpovědných za útoky jako BEAST, Lucky 13, nebo LogJam. Ukončena byla také podpora výměny klíčů bez PFS (perfect forward secrecy).

Symetrické šifrování nyní v TLS 1.3 zajišťuje úzká množina šifer (AES-GCM, AES-CCM, CHACHA20-POLY1305-SHA512). Všechny využívají autentizované šifrování. Jedná se o formu šifrování, která chráněnému obsahu zajišťuje jak utajení (confidentiality), tak autenticitu (authenticity, integrity). Módy šifrování dovolené v TLS 1.3 spadají do kategorie AEAD (authenticated encryption with associated data), tzn. k šifrovaným datům umožňují „přilepit“ obsah, jehož utajení není potřeba, a tedy stačí chránit pouze jeho integritu.

Šifrovací sady v dřívějších verzích TLS obě vlastnosti zajišťovaly různými prostředky. K utajení často sloužil mód CBC a pro zajištění integrity například HMAC odvozený z hašovací funkce rodiny SHA2. TLS 1.3 podporuje pro AES pouze módy GCM a CCM, které z tohoto pohledu poskytují „vše v jednom“ – z vstupní zprávy vytvoří blok šifrovaných a autentizovaných dat.

Omezením pouze na módy navržené přímo pro autentizované šifrování se tedy TLS 1.3 vyhýbá potenciálním rizikům plynoucím z použití nevhodné kombinace šifrovacího a autentizačního algoritmu.

Změny v handshaku

Navázání spojení TLS probíhá v několika krocích (tzv. TLS handshake). Během nich dojde k výměně kryptografických dat mezi klientem a serverem. V TLS 1.2 při handshaku proběhla tři kola výměny informací, v TLS 1.3 jsou výměny už jen dvě. Tím se doba komunikace zredukovala téměř o 1/3 (cca z 300 ms na 200 ms).

Změn se dočkal způsob ustavení sdíleného kryptografického materiálu a odvození klíčů během handshaku. Jako základní stavební blok pro derivaci klíčů slouží funkce HKDF. Sdílené tajemství lze vytvořit prostřednictvím protokolu Ephemeral Diffie Hellman ((EC)DHE) a/nebo díky „tajnému heslu“ (pre-shared key, PSK) známému oběma stranám před navázáním spojení. Zjednodušení a ustálení šifrovacích sad, stejně jako zredukování počtu povolených klíčů, umožnilo celkové zrychlení handshaku. 

Změnil se i celý průběh úvodního vyjednávání spojení. Na začátku handshaku dojde k odeslání zprávy ClientHello, ale na rozdíl od handshaku TLS 1.2 pošle klient už v první zprávě seznam podporovaných šifrovacích sad a stejně tak pošle protokol pro výměnu klíčů, který chce použít.

Server ve své odpovědi na zprávu ClientHello odešle sekvenci zpráv, obsahující vybraný protokol pro výměnu klíčů, certifikát serveru a ukončovací zprávu ServerFinished. Na to klient zkontroluje certifikát serveru, vygeneruje klíče a odešle zprávu ClientFinished. To znamená, že je ušetřeno jedno celé kolo výměny, kdy se server a klient domlouvali na tom, jaké klíče pro výměnu dat využijí.

0-RTT

Největší novinkou je ale tzv. Zero Round Trip Time Resumption (0-RTT) . Ve chvíli, kdy se komunikace mezi klientem a serverem otevře, dojde zároveň k založení tzv. „master resumption secret“. V praxi to znamená, že server po úspěšném navázání spojení pošle klientovi zprávu NewSessionTicket, ve které mu sdělí identifikátor pro pre-shared-key odvozený právě z master resumption secret. Takto uložená data jsou využita pro příští obnovení spojení klienta se serverem, díky čemuž je znovunavázání spojení rychlejší.

Přenos dat v 0-RTT probíhá bez interakce mezi klientem a serverem, což s sebou nese velké výhody, ale zároveň i riziko útoku, typicky tzv. replay útoků – třídě síťových útoků spočívajících v pozdržení či duplikaci komunikace mezi zúčastněnými stranami.

TLS 1.3 nedisponuje žádným mechanismem detekce replay útoků na aplikační data odeslaná klientem v rámci 0-RTT (tzv. early data). Neimplementuje-li server žádnou ochranu proti replay útokům, samotné TLS 1.3 nedetekuje případy, kdy útočník celou komunikaci duplikuje (od úvodního ClientHello až po signalizaci ukončení 0-RTT dat)

Tento způsob útoku nelze přímo využít k duplikaci aplikačních dat odeslaných normálním způsobem – až po dokončení handshaku, protože klíče k jejich šifrování jsou odvozeny i ze zpráv odeslaných serverem (např. ServerHello), a tedy jiné pro každé nové spojení nezávisle na použití 0-RTT. Další překážku představuje číslování balíčků přijatých a odeslaných dat.

Druhý případ replay útoku na 0-RTT je záludnější, protože k jeho realizaci útočník využije chování samotného klienta, konkrétně jeho snahu požadavek odeslat znovu v případě, že první pokus skončil nezdarem.

Představme si, že provoz směřující na určitou doménu je přijímán vždy jedním ze serverů A nebo B na základě překladu doménového jména na příslušnou IP adresu. Klient nejprve naváže TLS spojení se serverem A a provede plný handshake. Server A po dokončení handshaku vystaví klientovi tiket identifikující sdílené tajemství (pre-shared key odvozený z master resumption secret) pro případné pozdější obnovení spojení (včetně možnosti 0-RTT). Po nějaké době se klient znovu rozhodne komunikovat s A a odešle svůj požadavek v rámci 0-RTT.

Pokud útočník dokáže zablokovat zprávu ServerHello od A (popř. i zprávy následující za ní), klient může nabýt přesvědčení, že A je momentálně nedostupný a ve snaze odstínit uživatele od problému odešle stejný požadavek i na B. Nezáleží na tom, zda-li B akceptuje tikety vydané serverem A; klient přinejhorším provede plný handshake. Takovéto vícenásobné odeslání dat může vést k duplicitnímu provádění operací na serveru.

RFC 8446 diskutuje několik možností obrany proti jednodušší variantě replay útoků (server například akceptuje každý tiket nejvýše jednou), ale žádné z řešení není dokonalé, zejména pokud se daný systém skládá z více instancí serveru. Proti záludnější variantě se nelze bránit na úrovni TLS; to je úkolem aplikace, která jej využívá.

Problém je především s packety odesílajícími data, která donutí server k trvalé změně stavu (např. transakci databáze, nebo zvyšování counteru). Replaybilitu je potřeba mít na paměti.

UX DAy - tip 2

Aktuální stav

V tuto chvíli podporuje TLS 1.3 už většina webových prohlížečů, jako Google Chrome (od verze 70 je povolena pro všechna odchozí spojení), Firefox (od verze 63), Opera (od verze 53) a Safari (od verze 11.1).

Konkrétní čísla, získaná ze statistik využívání TLS v SMTP v červnu a červenci ukazují, že šifrováno je cca 70 % zpráv, z čehož cca 60 % je stále šifrováno nejužívanějším protokolem TLS 1.2. TLS 1.3 a jeho využití se mění. V únoru bylo pouze na 2 %, v červnu už na 16,5 % a nyní pravděpodobně z důvodu menšího trafiku během letních prázdnin, je jeho využití na 6,4 %. V průběhu dalších měsíců ale můžeme určitě čekat ve využití TLS 1.3 další nárůst.

Byl pro vás článek přínosný?

Autor článku

Aktivně používá Linux od roku 2009, jeho oblíbenou distribucí je Gentoo. Snaží se přispívat do různých open-source projektů, jeho oblíbeným jazykem je C.

Anděla Heřmánková je textař a copywriter. Postupně se přes menší zakázky různého druhu dostala až k práci na textech z oboru IT.

Věnuje se výzkumu, systémovému programování a problematice tvorby ovladačů. Zajímá se také o bezpečnost, kryptologii a příbuzné obory.