Jeżeli jesteście szczęśliwi i żyjecie w odpowiedniej rzeczywistości równoległej, to pewnie nie zmącił Wam spokoju ostatni fakt znalezienia szeregu podatności w popularnym protokole HTTP 2, za pomocą którego, można śmiało rzecz, odbywa się większość komunikacji przeglądarek ze stronami WWW na świecie. Przygotowałem szybkie streszczenie tego, z czym mamy tutaj do czynienia, bowiem, jeśli toczycie wojny apache vs nginx, czy podobne, to musicie się na razie wstrzymać ze śmieszkami.

Inżynier Netfliksa, Jonathan Looney oraz Piotr Sikora z Google odkryli poniższą listę luk w specyfikacji HTTP2:

Teraz o co tu chodzi. Jak masz stracha, że właśnie coś Ci wycieka, gdy Ty jesteś na urlopie, to póki co jeszcze śpij spokojnie, choć szykuj się na ewentualne telefony od klientów, że Wordpressy mogą im nie działać i właśnie biznesy im się sypią. :-)

Generalnie są to błędy typu denial of service. Sprawa ma się tak, że specyfikacja HTTP jest ogólnie znana, serwery www jakoś ją implementują i wszystko ładnie się kręci. Ktoś majgany jednak wczytał się w te specyfikację najwyraźniej i postanowił zadać sobie kilka dziwnych pytań i je sprawdzić, no i mamy taki efekt jaki mamy. Czyli serwery nieprzygotowane, na niestandardowe sytuacje, np. pingi lub zachowania, które mogą przypominać pingi, puste nagłówki lub manipulacje pakietami i takie tam, bo powoduje to ich zawieszenie lub nadmierne zużycie CPU (skutkujące czasami np. sfreezowaniem całego serwera w najgorszym przypadku)

Nie tylko najpopularniejsze serwery WWW nie były na te niestandardowe przypadki przygotowane, ale także niektóre ważne biblioteki, na myśli mam tutaj net/http z Go, która napędza prawdopodobnie niemałą część API w Internecie, Dockery, Kubernetesy i inne takie.

Oczywiście informacje o luce zostały w miarę odpowiedzialne opublikowane i zanim ujrzały światło dzienne, to stosowne poprawki już są, co by większość internetu się łatwo nie sypała:

Tutaj z kolei warty do poczytania artykuł inżynierów z F5, którzy już wcześniej badali podobne błędy i pokazali do czego one mogą finalnie prowadzić

Nie znalazłem informacji apropo czy lighttpd łatał tę lukę, ale jego wolny rozwój sugeruje, że obsługi HTTP2 może on jeszcze nie mieć, co paradoksalnie ochroniło jego użytkowników. :-)