Názory k článku
HTTP/2 Bomb ohrožuje servery Nginx, Apache, IIS, Envoy a Cloudflare Pingora

Uzasny. A zpusob reseni taky.

Vypnout http/2 == znasobit pocet http/1 spojeni na cele infrastrukture, nemluve o tom, kolik stoji samotne navazani tls.

Kazdopadne, pokud ted nekdo zkusi globalne tuhle akci provest, tak lehne internet :D

Ty jo, tak to sem rad, ze to nemusim vypinat, protoze to mam davno vsude vypnuty. A jestli to utavi vsechny mozny servery, co mi posilaj reklamy a obrazky, tak to bude super, dost mi to snizi zatez na mym fw, DNSBL mi uz ted blokuje 70% provozu.

A mozna lehnou i update servery MS, a ja alespon nebudu muset absolvovat kazdomesicni opravy oprav na pocitacich tech nasich domacich parilku.

"Opravy jsou dostupné v Nginx 1.29.8+ a Apache mod_http2 v2.0.41"

Čekal bych, že kontrolovaný MAX_HEADER_LIS­T_SIZE z RFC tu první část bude řešit. Chápu správně, že problém je v tom, že (a) servery to nemají a (b) RFC počítá s režií 32 oktetů na hlavičku, zatímco Apache alokuje 4000? nebo tam jde o něco zásadnějšího?

Asi se navrátím ke kořenům a všude si zkompiluju nginx ručně, jak jsem to dělal na Slackwaru. :-)

Z jakého důvodu?

Pokud se nechci zbavit HTTP/2 ve zranitelné verzi nginx, která není v repozitáři opravena, neodstranil bych problém kompilací opravené verze, než bude k dispozici opravená verze v repozitáři? Byl jsem zvyklý si spoustu věcí kompilovat sám, jen si to opráším, roky jsem to nedělal. ;-)

Před nginx mám traefik, který řeší http2 a ssl. nginx není dostupný přímo. To mě předpokládám ochrání? Ne že by byl problém aktualizovat 1 nginx, ale mám jich tam schovaných desítky a to už by se mi úplně nechtělo.

Já ti nevím, já myslím, že je lepší přístup mít to prostředí nastavené tak, že udržuješ aktualizované všechno. Teď je to chyba v nginxu, zítra to bude chyba zase v kernelu, pozítří v openssl knihovně a takto jedeme v cyklech, které neskončí.

Traefik je len load balancer.
Ak sam vyskladava paket kym ho dalej posle, tak moze obsahovat rovnaku zranitelnost.
Ak preposiela, co prislo od utocnika, na jedenz mnoziny Nginxov za nim, tak podla mna problem neriesi, len ho posunie na Nginx.

4. 6. 2026, 13:16 editováno autorem komentáře

Opravdu?

„Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy.“

Podle toho bych řekl, že Traefik interpretuje HTTP, a toto by mohl odfiltrovat.

Určitě, navíc za reverzní proxy už nemá HTTP/2 moc výhod, degradovat to na HTTP/1.1 je normální.

Ale baví mě jak se doba mění. Pamatuju když se Nginx běžně používal jako reverse proxy před Apache, a dneska vídám Traefik a další jako reverse proxy před Nginx (:

A pri tom Nginx sa na tom "backende" stale pouziva ako revezne proxy pre ine aplikacie.

Ale http/2 ma sakra hodne vyhod, degradace je nevyhodna! Uz jenom to, ze pokud je v ceste firewall, je to jedno spojeni, u http/1 se udavalo 5-10 spojeni pro jednoho klienta. To je zatraceny rozdil, i kdyby slo jenom o logy a ne o veskerou omacku, ktere k tomu spojeni patri.

Azure serverless web"servery" nebo Cloudflare WAF by toto měly mitigovat tak nějak by design, nebo se mýlím?

A co Caddy? Ten chybu neměl?

Taky bych ocenil, kdyby uvedli, které servery testovali. Není Caddy v seznamu, protože ho testovali a chybu nemá, nebo protože ho netestovali? Zatím jsem nikde nenašel informace o tom, že by Caddy bylo zranitelné. Ale to nemusí nic znamenat…

Svůj server si člověk může otestovat sám, ne? Aspoň bude testovat proti reálnému a ne defaultnímu nastavení. Testovací python v tom repu je.

Jsou tam testovací Python skripty, pro každý server (nginx/Apache/En­voy…) jiné, vygenerované AI. To moc důvěryhodně nevypadá.

Testoval jsem "duveryhodne nevypadajici" python skript pro nginx a funguje na 100%.