Is HTTP/2 the "Final Boss" for open-source firewalls? 🛡️

For years, we’ve been forced to "downgrade" traffic just to inspect it. As a FOSS developer, I spent months trying to bridge the gap between HTTP/2 and legacy inspection tools in SSLproxy.

The result? A "Concurrency Density Spike" that can overwhelm even the best C-based proxies. 📈

In my latest article, I break down why we need to stop fighting the "Binary Frame" war and start focusing on the ICAP Path. It’s not just a fix for H2—it’s our only real ticket to supporting HTTP/3 (QUIC) and finally unblocking UDP port 443 without losing visibility.

#OpenSource #CyberSecurity #InfoSec #NetworkSecurity #HTTP2 #HTTP3 #SSLproxy #Suricata #Firewall #ICAP #SystemArchitecture

https://www.linkedin.com/pulse/i-tried-add-http2-sslproxy-here-why-stopped-we-need-icap-soner-tari-7x7mf

I Tried to Add HTTP/2 to SSLproxy. Here is Why I Stopped. (We Need ICAP.)

Discover why Divert Mode creates a "density spike" in SSLproxy and why the ICAP path is the future for H2/H3 support in open-source firewalls like Suricata.

Решаем архитектурную проблему nginx с HTTP/3: опыт Angie и магия eBPF

Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного ПО с многопроцессной архитектурой этот шаг превращается в настоящую «головную боль». Классическая схема с accept() , на которой годами строилась работа с TCP‑соединениями, в мире QUIC попросту не существует. Пакеты летят в UDP‑порт, и ядро ОС больше не знает, какому именно рабочему процессу их отдать. В оригинальном nginx это привело к тому, что поддержка HTTP/3 уже долгое время остается «экспериментальной» и ограниченной: она страдает от проблем с обрывами сессий при миграции клиентов и деградации сервиса при обновлении конфигурации. Для многих это стало стоп‑фактором для внедрения протокола в реальный продакшен. В этой статье мы расскажем, как в Angie 1.11 нам удалось устранить эти фундаментальные недостатки. Мы не просто добавили поддержку протокола, а пересмотрели механику взаимодействия с ядром. Путь от простых хешей до создания полноценного аналога accept() для QUIC с помощью BPF‑программ позволил нам заявить: реализация HTTP/3 в Angie закончена, лишена «детских болезней» nginx и полностью готова к эксплуатации в высоконагруженных средах. Добро пожаловать под капот современного транспорта данных.

https://habr.com/ru/articles/989748/

#http3 #nginx #quic #сетевое_программирование #ebpf #bpf #angie #h3 #многопроцессность #udp

Решаем архитектурную проблему nginx с HTTP/3: опыт Angie и магия eBPF

Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного...

Хабр

Ein Paketverlust und plötzlich steht alles? HTTP/2 über TCP leidet an Head-of-Line-Blocking. Wanderson Xesquevixos erklärt, wie #HTTP/3/QUIC das löst & wie es in #Java26 aktiviert wird.

So simpel ist der Einstieg! Jetzt lesen: https://javapro.io/de/java-26-uebernimmt-http-3-mit-der-weiterentwicklung-des-httpclient/

#Java #HTTP3 #Performance

Warum haben deine #Microservices trotz HTTP/2 noch fiese Tail-Latenzen? Wanderson Xesquevixos zeigt, wie #Java26 mit JEP 517 HTTP/3 (QUIC) in den HttpClient bringt – inkl. Fallback.

Finde Copy-paste-Code + Logs zum Nachweisen: https://javapro.io/de/java-26-uebernimmt-http-3-mit-der-weiterentwicklung-des-httpclient/

#Java #HTTP3 #QUIC #JAVAPRO

After spending some time digging into this, I have the feeling #HTTP3 may be destined to be the #IPv6 of #HTTP: cool features, good performance but suffers from adoption challenges.
Previous tests I did using a client machine on the GNS3 network simulator didn't utilize Connection Migration at all despite also using QUIC and HTTP3. (Using Chromium v141.0.7390.122). According to the Chromium docs, QUIC should be fully supported since version 90 though? https://www.chromium.org/quic/
#quic #http3 (5/x)
QUIC, a multiplexed transport over UDP

There are hundreds of articles about how HTTP3 are QUIC are the new hot shit and how it's revolutionizing web traffic (which I don't doubt), but none of the posts and articles (besides the spec itself) really explain how it all works. They're all just listing off those cool new features (0-RTT, Connection Migration) without any real in-depth explanation 🙄 Guess that's my problem, trying to actually understand how it works (for research purposes) #quic #http3 (4/x)
When switching off the ethernet interface, video playback doesn't stop and I can see the related QUIC traffic immediately appearing on the WiFi interface but I am not able to correlate any connection migration using PATH_CHALLENGE frames or the SCID/DCID. How does the browser know to switch to the other endpoint then? This is really puzzling. None of the guides I've found so far go into detail how exactly this is supposed to work :/ #quic #http3 (3/x)
My test setup:
- Client: Chromium v143.0.7499.169 on Linux (6.12.63-1-lts)
- Server: NGINX (v1.29.4) with H3/QUIC options enabled, connection migration enabled
- Playing back an MP4 video file (not segmented) using the Shaka player library from a website/content hosted via the web server
- Networks: Eth and WiFi interfaces are situated in the same network (same WAN IP)
- Testing by switching off the ethernet iface via network manager, capturing traffic on both with Wireshark #quic #http3 (2/x)
Hi fediverse fellows, most of the research I find around #http2 vs #http3 (#quic) focusses around performance, but given the power and maturity of OS/security tooling around #tcp vs #udp handling... I'd like to learn more about good practices around handling #http3 connections. eg: stateful firewalls, service meshes, etc.