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.
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.
