Co je záplava TLS handshaků?

Na HTTPS je drahá jen kryptografie

Odeslat cachovanou stránku po už navázaném spojení je téměř zdarma: symetrická šifra jede v gigabajtech za sekundu na jádro a obsah se bere z paměti. Navázat nové HTTPS spojení je ale úplně jiná práce. Ještě než existuje jakýkoli požadavek, musí váš server:

1. Dokončit TCP handshake (levné — ale co se stane, když se útočí i na tohle, rozebírá SYN flood).
2. Vygenerovat efemérní klíčový podíl a spočítat sdílené tajemství.
3. Podepsat se privátním klíčem svého certifikátu, aby dokázal, že certifikát je jeho.
4. Odeslat řetězec certifikátů — typicky tři až šest kilobajtů.

Krok 3 je ten drahý a ještě důležitější než cena je pořadí: v TLS 1.2 s ECDHE i v TLS 1.3 server ten podpis udělá ve zprávě, kterou posílá hned po ClientHello — tedy dřív, než má jakýkoli důkaz, že klient na druhé straně chce handshake dokončit nebo že vůbec existuje.

Neberte ta čísla z webové stránky: spusťte openssl speed rsa2048 ecdsap256 ecdhx25519 na stroji, který TLS skutečně ukončuje. Výsledek vydělený počtem jader a vydělený na polovinu kvůli všemu ostatnímu, co ten stroj dělá, je váš skutečný strop v nových HTTPS spojeních za sekundu. U velké části originů to číslo vyjde někde mezi jedním a deseti tisíci — což je pohodlně v možnostech pronajatého botnetu a ani zdaleka to nejsou gigabity, proti kterým se ochrana inzeruje.

Nerovnost vypsaná natvrdo

První řádek si přečtěte dvakrát. I když CPU úplně pustíme z hlavy, opuštěný handshake vás nutí odeslat asi osmkrát víc, než odeslal útočník — a tím se nenápadně mění skromná záplava na vstupu na citelnou záplavu na výstupu. Proto při záplavě handshaků často roste egress rychleji než ingress, což vede lidi k hledání scraperu.

Šest podob téhož útoku

Poslední řádek obránci obvykle přehlédnou. Vaše konfigurace TLS je menu a útočník si z něj objednává. Pokud na něm z důvodů kompatibility pořád je velká grupa Diffie-Hellman nad konečným tělem nebo sada s výměnou klíčů přes RSA, ClientHello, které nenabídne nic jiného, dostane přesně ji.

První tři řádky jsou zároveň místa, kde se záplava handshaků prolíná se sousedními rodinami útoků. Jeden požadavek na spojení ve velkém je současně útok na aplikační vrstvě i útok na vyčerpání kryptografie; opuštěný handshake držený záměrně nedokončený tak dlouho, jak váš timeout dovolí, je low-and-slow útok, který jen míří na vrstvu TLS. Skutečné incidenty mezi nimi rotují, což je téma multivektorových útoků.

Graf přenosu vás znovu svede ze stopy

Aritmetika je tatáž lekce jako u SYN floodu, jen o vrstvu výš:

Čtyřicet megabitů za sekundu se na dashboardu kalibrovaném na gigabity neprojeví. Pokud vaše monitoring kreslí přenos a požadavky za sekundu, ale ne nová spojení za sekundu, je pro vás záplava handshaků prakticky neviditelná, dokud není web dole — a symptom (vysoké CPU, HTTPS v timeoutech, access log tišší než obvykle) vypadá přesně jako porucha serveru.

Jak si ověřit, že jde právě o tohle

Pět kontrol v pořadí, které to rozhodne nejrychleji:

• Zprofilujte CPU. perf top na terminátoru TLS během incidentu. Pokud user time dominují symboly OpenSSL — rutiny P-256 nebo montgomery u RSA — stroj se vydává na handshaky, ne na vaši aplikaci.
• Srovnejte počet spojení s počtem požadavků. nstat -az TcpPassiveOpens odečtený dvakrát s několika sekundami mezi tím dá nová spojení, access log dá požadavky. Počet spojení na úrovni počtu požadavků nebo nad ním znamená, že se skoro nic neamortizuje přes keep-alive — a to je podpis tohoto útoku.
• Počítejte obnovení session. Logujte $ssl_session_reused v nginxu (nebo ssl_fc_is_resumed v HAProxy). Zdravý provoz obnoví velkou část session; záplava neobnoví v podstatě žádnou.
• Přečtěte error log v objemu. Tisíce řádků SSL_do_handshake() failed nebo while SSL handshaking znamenají, že se handshaky zakládají a opouštějí v tempu, které by žádná populace prohlížečů nevytvořila.
• Znejte svůj strop dřív, než ho budete potřebovat. openssl s_time -connect host:443 -new měří tempo plných handshaků, -reuse tempo obnovených. Rozdíl mezi těmi dvěma čísly je přesně ta expozice, na kterou tento útok míří — a měří se lépe v klidné úterý než během incidentu.

Pokud máte místo toho logy plné věrohodně vypadajících požadavků a CPU v kódu aplikace, jde o záplavu požadavků, ne handshaků, a stránka, kterou chcete, je jak zastavit DDoS útok.

Co opravit na serveru

Každá z těch věcí se vyplatí. Žádná z nich není odpověď.

Nasaďte ECDSA certifikát. Vyměnit podpis RSA-2048 za ECDSA P-256 je největší změna, kterou máte k dispozici — typicky řádově víc handshaků na jádro. Moderní stacky umí nastavit oba a podat ten, který klient podporuje, takže pro RSA-only v roce 2026 už nezbývá argument kompatibilitou.

Zkraťte menu. Nabídněte X25519 a P-256 a tím to skončí. Odeberte velké grupy DH nad konečným tělem a všechny zbylé sady s výměnou klíčů přes RSA. Útočníkovi nezabráníte vybrat si tu nejdražší možnost, kterou podporujete; můžete ale zkrátit seznam.

Zajistěte, aby obnovení session reálným návštěvníkům fungovalo. Session tickety s rozumnou rotací a cesta PSK v TLS 1.3 znamenají, že váš skutečný provoz plný handshake platí jen zřídka. S útokem to neudělá nic, s vaší rezervou během něj hodně.

Zakažte renegociaci iniciovanou klientem a preferujte TLS 1.3. TLS 1.3 renegociaci zrušilo úplně, čímž podobu THC-SSL-DOS zavírá rovnou. Pokud někde ještě ukončujete TLS 1.2, ověřte, že renegociace od klienta je odmítnutá, místo abyste předpokládali, že to distribuce udělala za vás.

Zkraťte timeout handshaku. ssl_handshake_timeout v nginxu má výchozí hodnotu 60 sekund, což je pozvánka držet slot workeru celou minutu zdarma. Skutečnému prohlížeči stačí pár sekund.

Nechte keep-alive zapnutý a velkorysý. Handshake skutečného návštěvníka by měl zaplatit desítky požadavků. Každé spojení, které nutíte prohlížeč navazovat znovu, je kapacita darovaná útoku.

Omezte počet současných spojení na zdroj přes limit_conn nebo obdobu. Proti jednomu hlasitému hostu to funguje, proti třem tisícům domácích adres skoro vůbec — z důvodů rozebraných v co je botnet a rate limitingu.

Dohromady to může zvednout přežitelné tempo handshaků desetinásobně. Útočník to své znásobí tím, že si za cenu obědu pronajme druhý botnet — a hlavně, a na tomhle žádné ladění nic nemění, každá vaše obrana běží až po tom, co pakety dorazily na vaši linku a prošly vaším CPU. Náklad, který platíte na každý paket útoku, je náklad, jehož výši určuje útočník.

Kde se záplava TLS handshaků skutečně zastaví

Nad strojem, který drží privátní klíč, a v pořadí od nejlevnějšího rozhodnutí:

1. TCP ukončené mimo váš origin. Zdroj, který nedokáže dokončit TCP handshake, se na vrstvu TLS vůbec nedostane — tím z problému zmizí každý podvržený paket ještě před jakoukoli kryptografií.
2. Řízení přístupu podle tempa spojení ze zdroje. Strop na to, jak rychle smí jeden zdroj zakládat nové handshaky, uplatněný dřív než podpis, ne po něm — a návštěvníci, kteří se už prokázali, jsou vpuštěni před stropem, aby záplava nevytlačila vaše stálé.
3. Zahození prokázaných útočníků v jádře. Jakmile je zdroj posouzený, jeho pakety mají stát vyhledání v tabulce a nic víc. Celá hra je o poměru mezi tím, co rozhodnutí stojí vás, a tím, co stojí je.
4. Agregovaná kapacita na handshaky. Mnoho jader na několika uzlech má řádově vyšší společný kryptografický strop než jeden origin a záplava se mezi ně rozdělí, místo aby se koncentrovala na vás.
5. Obnovení session a sdružování spojení na edge. Když skuteční návštěvníci obnovují session na nejbližším uzlu a edge sahá na váš origin malým poolem dlouho žijících spojení, přestane být tempo handshaků na vašem originu funkcí počtu vašich návštěvníků — i počtu útočníkových.
6. Teprve potom obrana na úrovni požadavku. Výzvy, behaviorální signatury i rate limity předpokládají požadavek. Jsou to správné nástroje na záplavu na aplikační vrstvě a na handshake opuštěný dřív, než jakýkoli požadavek vznikne, přicházejí pozdě.

Jedna podmínka stojí mimo ten seznam a potichu ruší všechno v něm: váš origin musí být nedosažitelný jinak než přes ochrannou síť. Pokud útočník pořád dokáže otevřít TCP spojení na skutečnou adresu vašeho serveru, nic z výše uvedeného není v cestě — viz jak skrýt IP adresu originu. Obecná podoba téhle argumentace, pro všechny rodiny útoků, je v co je DDoS mitigace.

Jak Itnetic zastavuje záplavy TLS handshaků

Edge Itnetic je navržený přesně podle pořadí nákladů výše — tlačit každé rozhodnutí tak nízko, jak to jde, a nechat být zajímavý jen provoz, který přežije všechno.

Dvě komerční věci jsou stejně důležité jako cesta paketu. Zmitigovaný provoz útoku se nikdy neúčtuje proti vaší bandwidth kvótě — včetně řetězců certifikátů, které záplava handshaků nutí edge odeslat — takže týden trvající záplava nepřijde jako faktura. A spuštění jsou dva DNS záznamy u vašeho stávajícího poskytovatele: žádná změna nameserverů, asi pět minut, klidně jen jeden hostname, pokud si to chcete nejdřív osahat. DDoS ochrana Itnetic popisuje zbytek pipeline a každá funkce zmíněná výše je v každém plánu, ten zdarma včetně.

Checklist o sedmi bodech

1. Změřte si vlastní strop: openssl s_time -connect vashost:443 -new proti -reuse a openssl speed na terminátoru TLS.
2. Kreslete nová spojení za sekundu vedle přenosu a požadavků a alertujte na ně. Na metriku, kterou nemáte v grafu, nejde reagovat.
3. Nasaďte ECDSA certifikát a RSA si nechte jen jako fallback, pokud ho ještě potřebujete.
4. Omezte nabízené grupy a šifrovací sady na levné moderní; smažte velké grupy FFDHE a výměnu klíčů přes RSA.
5. Ověřte logováním, že obnovení session skutečným návštěvníkům opravdu funguje — ne předpokladem.
6. Snižte ssl_handshake_timeout na jednociferné sekundy a potvrďte, že renegociace od klienta je na každém TLS 1.2 listeneru odmítnutá.
7. Zafirewallujte origin na svou ochrannou síť, aby handshake, který útočník platí, nikdy nebyl ten, který by váš server mohl zodpovědět.

Pokud se to děje právě teď, nedočítejte tuhle stránku a projděte jak zastavit DDoS útok. Až to přejde, jak otestovat svou DDoS ochranu popisuje, jak si bezpečně a legálně potvrdit, že příští záplava narazí na filtr, a ne na váš privátní klíč.