Vlákno názorů k článku HTTP/3: co nám nový protokol přinese a proč to hned tak nebude od anonym - Mě by hlavně zajímalo jakým způsobem se pak...

Mě by hlavně zajímalo jakým způsobem se pak bude sanitizovat trafik, a to hned na obou dvou koncích:
1. denně na nás jde několik UDP flood útoků, které je triviální teď čistit, protože téměř nic nepřipomíná regulérní provoz. Přechodem HTTP na UDP to bude znamenat parsovat komunikace až na aplikační úroveň a tedy nejspíše desetinásobek současného výkonu.
2. aktuálně máme bezpečnostní pojistku, aby ze sítě neodcházeli UDP až na pár výjimek. S přepnutím HTTP na UDP komunikaci tak umožníme opět jakémukoliv počítači v síti stát se aktivním prvkem v botnetu a riskovat například zablokování celé sítě. V dřívější dobách by se to řešilo povolením jen schválených zařízení, ale dnes každý vyžaduje wifi access s internetem ke svému mobilu/tabletu/no­tebooku.

1. Až na aplikační úroveň se kvůli šifrování nedostanete. Bez znalosti klíče relace není možné odlišit legitimní součást QUIC relace jiných UDP zpráv

2. Jaký je rozdíl v botnetu na UDP proti botnetu na TCP?

1. To lze vyřešit problém logováním klíčů, Wireshark je na to připraven. Java mu může data poskytnout skrze http://jsslkeylog.sourceforge.net/ , u Firefoxu a Chrome AFAIR stačilo nastavit nějakou environment variable.

I když to odlišíte, k čemu vám taková informace bude? Stejně to musíte zahodit až na cílovém stroji, žádný síťový prvek po cestě nebude schopen takové drobné nuance rozlišovat, natož pak takové detaily třeba pomocí RTBH filtrovat přímo u providera.

Je to vlastně celé takové symbolické. Tím, že se middleboxy naučily strkat prsty i do transportních protokolů byl způsoben současný stav, kdy je každý nový protokol třeba vymyslet tak, aby navenek předstíral nějaký starý známý transportní protokol. Na to vývojáři middleboxů zřejmě zareagují strkáním prstů i do aplikačních dat, ve kterých se skrývá nový transportní protokol. Takhle to nejspíš budeme iterovat donekonečna a ze čtyřvrstvého TCP/IP nám časem vznikne dvacetivrstvé, kde budou vrstvy L4a až L4t ;)

Aha, vypadá to, že jsem ten komentář vytrhl z kontextu. Sorry.

Z našeho provozu registrujeme kupodivu jen větší UDP floody. Na TCP možná něco chodí, ale nic, čeho bychom si všimli mimo normální trafik. Pokud je mi známo, tak TCP floody se běžně řeší limitováním rate syn packetů per IP a zaříznutím čehokoliv, co není v conntrack tabulce. Což je docela CPU/RAM náročné, ale dnešní běžný serverový hw by snad mohl ustát i pár Gbps syn flood. A to je v podstatě způsob, jakým bych přistoupil k filtrování floodu z QUICu. Analyzováním TLS hlavičky, jestli se jedná o již započaté spojení a omezil vytváření nových per IP. Nicméně oproti vyparsování TCP portu a flagů, abych se dostal k informacím o flow, budu muset parsovat QUIC a TLS hlavičky, abych dostal tu samou informaci. Hardware to zvládne, ale pomaleji.

Myslím, že tohoto není třeba se až tak bát. TCP filtrujete na firewallech hlavně kvůli tomu, aby vám nevyčerpalo prostředky v TCP/IP stacku v jádře. Proti tomu UDP datagram projde velmi rychle přímo do aplikace, aniž by za sebou zanechával jakékoli stopy - pokud tedy pro UDP vypnete conntrack. Samotná aplikace pak nepochybně velmi rychle a levně* vyhodnotí, které datagramy patří k existujícím spojením a ty ostatní ihned zahodí.

Proto si myslím, že žádný předsunutý inteligentní firewall analyzující obsahy UDP zpráv není nutný.

*) přinejmenším stejně rychle a levně, jako by to dělal předsunutý firewall