QUIC macht Firewalls sinnlos

🔊Zum Podcast

Das Internet hat klammheimlich sein Fundament ausgetauscht und viele haben es nicht einmal bemerkt. Bereits heute laufen über 25% des weltweiten Web-Traffics über ein Protokoll namens QUIC, welches das jahrzehntelang bewährte TCP in den Schatten stellt. Dieser Wandel, der HTTP/3 als neue Version des Web-Protokolls mit sich bringt, optimiert nicht nur die Geschwindigkeit, sondern stellt durch seine radikale Verschlüsselungsphilosophie auch die Grundpfeiler der Netzwerksicherheit, insbesondere den Einsatz von Firewalls, fundamental infrage.

Das Dilemma mit TCP: Warum eine Neuerung unumgänglich war

Seit den 1980er Jahren bildet das Transmission Control Protocol (TCP) das Rückgrat für zuverlässige Datenübertragungen im Internet. Es hat uns gut gedient, doch die Anforderungen des modernen Webs haben seine Grenzen aufgezeigt. Zwei zentrale Probleme machten eine Weiterentwicklung zunehmend schwierig:

• Hohe Latenz beim Verbindungsaufbau: Ein klassischer Verbindungsaufbau mit TCP und der darauffolgenden Verschlüsselung mittels TLS erfordert mehrere “Round Trips” – also Kommunikationszyklen zwischen Client und Server. Ein TCP-Handshake (SYN, SYN-ACK, ACK) benötigt einen vollen Round Trip. Ein anschließender TLS-1.2-Handshake benötigt zwei weitere. Selbst mit dem optimierten TLS 1.3 sind es immer noch insgesamt zwei Round Trips, bevor das erste Byte an Anwendungsdaten fließen kann. In globalen Netzwerken bedeutet das oft eine Verzögerung von hunderten Millisekunden, bevor eine Webseite überhaupt zu laden beginnt.

• Versteinerung durch “Middleboxes”: Das vielleicht größere Problem war die sogenannte “Middlebox Ossification”. Unzählige Geräte zwischen Client und Server – Firewalls, NAT-Gateways, Load Balancer – sind tief in die Interna von TCP verdrahtet. Sie inspizieren TCP-Header, um Verbindungen zu überwachen oder zu filtern. Der Versuch, TCP durch neue Features zu erweitern, scheiterte oft kläglich. Ein Paradebeispiel ist TCP Fast Open, eine Erweiterung, die Daten bereits im ersten SYN-Paket mitsenden sollte, um den Handshake zu beschleunigen. Viele ältere Firewalls interpretierten diese legitimen Pakete als Angriffsversuch und verwarfen sie kurzerhand. Eine flächendeckende Einführung solcher Optimierungen wurde so über Jahre, wenn nicht Jahrzehnte, blockiert. Obwohl Google bereits 2014 seine Dienste auf QUIC migrierte und dies auch in seinem Chrome-Browser als primäres Protokoll hinterlegte, führte z.B. Fortinet TCP Fast Open erst am 12. Februar 2025 ein, was zeigt, wie lange sich große Firmen Zeit lassen.

Das Internet steckte in einer Zwickmühle: Eine Weiterentwicklung von TCP war durch die existierende Infrastruktur kaum möglich.

QUIC: TCP neu gedacht, aber auf UDP

Genau hier setzt QUIC (Quick UDP Internet Connections) an. Die Entwickler wählten einen radikalen, aber genialen Ansatz: Statt zu versuchen, das versteinerte TCP zu reparieren, bauten sie dessen Funktionalität auf einem anderen, minimalistischeren Protokoll neu auf: dem User Datagram Protocol (UDP).

Es hält sich hartnäckig der Mythos, QUIC sei schneller, weil es UDP nutzt. Das ist ein Trugschluss. QUIC implementiert alle Zuverlässigkeitsmechanismen, die TCP auszeichnen – wie Verbindungsaufbau, Fehlerkorrektur und Überlastkontrolle – selbst. Der eigentliche Grund für die Wahl von UDP ist ein strategischer: Middleboxes lassen UDP-Pakete in der Regel passieren. Sie erwarten entweder TCP oder UDP und alles andere wird oft verworfen. Indem QUIC sich als UDP “tarnt”, kann es die versteinerten Schichten des Internets unbeschadet passieren.

Das wahre Geheimnis von QUIC liegt jedoch in seiner Philosophie: Verschlüssele so viel wie möglich. Während bei TCP die Header-Informationen (wie Sequenznummern oder Window-Sizes) im Klartext übertragen werden, verschlüsselt QUIC fast den gesamten Transport-Layer. Für eine Middlebox sieht ein QUIC-Paket wie zufälliger Datenmüll aus. Sie kann es nicht mehr interpretieren und folglich auch nicht fälschlicherweise blockieren, wenn das Protokoll in Zukunft erweitert wird. Diese “Unsichtbarkeit” erkauft QUIC seine zukünftige Entwicklungsfähigkeit.

Killer-Feature #1: Der 0-RTT-Handshake

Früher mussten mehrere Verbindungen etabliert werden, bis letztlich Daten ausgetauscht werden konnten:

QUIC integriert den Transport-Handshake und den Verschlüsselungs-Handshake (basierend auf TLS 1.3) von Grund auf. Das Ergebnis ist eine drastische Reduzierung der Latenz beim Verbindungsaufbau.

• Erste Verbindung: Der Aufbau einer brandneuen Verbindung zu einem Server dauert nur noch einen Round Trip (1-RTT).
• Folgeverbindungen: Hier spielt QUIC seine größte Stärke aus. Bei der ersten Verbindung handelt der Client mit dem Server bereits kryptografisches Material für zukünftige Sitzungen aus. Bei einem erneuten Verbindungsaufbau kann der Client die erste HTTP-Anfrage bereits im allerersten Paket verschlüsselt an den Server senden. Der Server kann diese Anfrage sofort verarbeiten. Dieser Vorgang wird als 0-RTT (Zero Round Trip Time) bezeichnet und stellt den theoretisch schnellstmöglichen Verbindungsaufbau dar.

Konnten früher keine Daten gesendet werden, wenn ein SYN-Flag gesetzt war, so wird bei QUIC gleich alles ausgetauscht, was für die verschlüsselte Verbindung nötig ist:

Killer-Feature #2: Das Ende des Head-of-Line-Blocking

Ein weiteres chronisches Problem von HTTP/2 über TCP ist das sogenannte Head-of-Line-Blocking (HOL-Blocking). HTTP/2 erlaubt das “Multiplexing”, also die gleichzeitige Übertragung mehrerer Ressourcen (z.B. CSS, JavaScript, Bilder) über eine einzige TCP-Verbindung. Intern werden diese Ressourcen in separaten “Streams” verwaltet. Das Problem: TCP selbst kennt dieses Konzept nicht. Für TCP ist alles nur ein einziger, geordneter Datenstrom.

Geht nun ein einziges TCP-Paket verloren, das beispielsweise einen Teil einer JavaScript-Datei enthielt, hält TCP die gesamte Verarbeitung an – auch für Pakete, die danach eintreffen und zu einer komplett anderen Ressource (z.B. einer CSS-Datei) gehören. Obwohl die CSS-Datei bereits vollständig empfangen sein könnte, muss sie warten, bis das verlorene JavaScript-Paket erneut gesendet wurde. Ein kleiner Verlust blockiert die gesamte “Schlange”.

QUIC löst dieses Problem elegant, indem es die Stream-Verwaltung direkt in den Transport-Layer integriert. QUIC weiß, dass es mehrere voneinander unabhängige Streams transportiert. Geht nun ein Paket für den JavaScript-Stream verloren, wird nur dieser eine Stream blockiert. Der CSS-Stream kann ungehindert weiterverarbeitet werden. Man könnte es sich wie einen Supermarkt vorstellen, der von einer einzigen Kasse auf mehrere Kassen umstellt: Wenn ein Kunde an einer Kasse ein Problem hat, können die anderen Kunden an den anderen Kassen trotzdem weiter einkaufen.

Killer-Feature #3: Nahtlose Verbindungs-Migration

Jeder kennt das “Parkplatz-Problem”: Man verlässt das Bürogebäude, das Smartphone verliert die WLAN-Verbindung und wechselt nahtlos ins 4G/5G-Netz. Für TCP ist dies eine Katastrophe. Eine TCP-Verbindung ist fest an ein Tupel aus vier Werten gebunden: (Quell-IP, Quell-Port, Ziel-IP, Ziel-Port). Ändert sich die Quell-IP durch den Netzwerkwechsel, bricht die TCP-Verbindung ab und muss komplett neu aufgebaut werden.

QUIC entkoppelt die Verbindung von der IP-Adresse durch die Einführung einer Connection ID (CID). Diese eindeutige Kennung wird im (unverschlüsselten Teil des) QUIC-Headers mitgesendet. Wechselt der Client das Netzwerk und damit seine IP-Adresse, bleibt die CID gleich. Der Server erkennt, dass es sich um dieselbe Verbindung handelt und kann sie nahtlos fortsetzen.

Um das Tracking von Nutzern über verschiedene Netzwerke hinweg zu verhindern, wird die Sache noch cleverer: Während einer bestehenden, verschlüsselten Verbindung können Client und Server neue, alternative CIDs aushandeln. Bei einem Netzwerkwechsel verwendet der Client einfach eine dieser neuen CIDs. Ein externer Beobachter kann so die Verbindung im alten und neuen Netzwerk nicht mehr korrelieren, während der Server intern die Zuordnung kennt.

Die unumgängliche Konsequenz: Das Ende der klassischen Firewall?

Die tiefgreifende Verschlüsselung von QUIC ist Segen und Fluch zugleich. Für die Performance und Zukunftsfähigkeit des Protokolls ist sie ein Segen. Für die traditionelle Netzwerksicherheit ist sie eine massive Herausforderung.

Klassische Next-Generation Firewalls und Deep-Packet-Inspection (DPI)-Systeme verlassen sich darauf, den Netzwerkverkehr detailliert analysieren zu können. Sie inspizieren TCP-Header, um Anomalien zu erkennen, oder filtern Verbindungen basierend auf Transport-Layer-Signaturen. Bei QUIC ist all das nicht mehr möglich.

Da fast alle Transport-Metadaten verschlüsselt sind, sieht eine Firewall nur noch einen Strom von UDP-Paketen zwischen zwei Endpunkten. Sie kann nicht mehr erkennen, ob Pakete verloren gehen, welche Sequenznummern verwendet werden oder wie die Flusskontrolle abläuft. Ihr bleibt nur eine binäre Entscheidung: Den gesamten QUIC-Verkehr (typischerweise auf UDP-Port 443) entweder pauschal zu erlauben oder komplett zu blockieren.

Aktuell wird dieses Problem dadurch abgemildert, dass Browser eine “Happy Eyeballs”-Strategie fahren: Sie versuchen, parallel eine QUIC/HTTP/3- und eine TCP/HTTP/2-Verbindung aufzubauen. Diejenige, die zuerst erfolgreich ist, wird genutzt. Blockiert eine Firewall also QUIC, fällt die Verbindung nahtlos auf das alte Protokoll zurück. Dies ist jedoch nur eine Übergangslösung. Langfristig wird der Druck steigen, QUIC zu erlauben, und Administratoren müssen ihre Sicherheitsstrategien überdenken. Die Inspektion muss sich zwangsläufig vom Netzwerk weg und hin zum Endpunkt verlagern, da nur dort der Verkehr im entschlüsselten Zustand sichtbar ist.

Um selbst zu testen, ob ein Server HTTP/3 anbietet, kann ein modernes curl-Binary genutzt werden:

# --http3 teilt curl mit, QUIC zu versuchen
# -I sendet nur eine HEAD-Anfrage für die Header
curl --http3 -I https://blog.meister-security.de/

Wenn der Server HTTP/3 unterstützt, wird die erste Zeile der Antwort so aussehen:

HTTP/3 200
...

Die unsichtbare Bedrohung – SSH und andere Protokolle im QUIC-Tunnel

Während der ursprüngliche Fokus von QUIC auf der Beschleunigung des Web-Traffics liegt, eröffnet das Protokoll weitreichendere und aus Sicherheitssicht beunruhigende Möglichkeiten. Eine der größten Gefahren besteht darin, QUIC als verschlüsselten Tunnel für beliebige andere Protokolle zu missbrauchen. Ein besonders kritisches Beispiel hierfür ist das Tunneln von Secure Shell (SSH)-Verbindungen, was traditionelle Firewall-Konzepte ad absurdum führt.

Die Gefahr: Versteckter Admin-Zugriff per SSH-Tunnel

Normalerweise findet die Kommunikation per SSH über den TCP-Port 22 statt. Dieser Port wird von Firewalls in der Regel streng überwacht und der Zugriff darauf ist stark eingeschränkt, um unbefugte administrative Zugriffe auf Server zu verhindern. Wird SSH jedoch über QUIC getunnelt, läuft dieser hochprivilegierte Verkehr verschlüsselt über den UDP-Port 443 – denselben Port, den auch der legitime QUIC-Web-Traffic nutzt.

Für eine Firewall ist dieser getunnelte SSH-Verkehr von normalem, verschlüsseltem Websurfen nicht mehr zu unterscheiden. Die Konsequenzen für die Netzwerksicherheit sind gravierend:

• Umgehung von Firewall-Regeln: Sämtliche Sicherheitsregeln, die den Zugriff auf Port 22 beschränken, werden wirkungslos. Ein Angreifer kann potenziell von überall aus eine SSH-Verbindung zu internen Systemen aufbauen, solange die Firewall ausgehenden QUIC-Verkehr erlaubt.
• Verlust der Sichtbarkeit: Da der gesamte Datenverkehr innerhalb des QUIC-Tunnels Ende-zu-Ende-verschlüsselt ist, können weder Firewalls noch Intrusion-Detection-Systeme (IDS) den Inhalt der Pakete analysieren. Sie sind blind für die Tatsache, dass innerhalb einer vermeintlichen Web-Verbindung administrative Befehle ausgeführt oder Daten exfiltriert werden.
• Verdeckte Kanäle für Angreifer: Angreifer können so unbemerkt eine dauerhafte und verschlüsselte Kommandozentrale (Command and Control) innerhalb des Netzwerks etablieren und sensible Daten nach außen schleusen.

Die technische Realisierung von SSH über QUIC ist dabei keine reine Theorie mehr. Unter der Bezeichnung "SSH3" gibt es bereits konkrete Entwürfe und Implementierungen, die SSH über HTTP/3 und damit über QUIC realisieren.

Nicht nur SSH: Jedes Protokoll kann getunnelt werden

Die Bedrohung beschränkt sich nicht auf SSH. Nahezu jedes Protokoll, das auf TCP oder UDP aufsetzt, kann durch einen QUIC-Tunnel geschleust werden. Dazu gehören beispielsweise das Remote Desktop Protocol (RDP) für den Fernzugriff auf Windows-Systeme, Datenbankverbindungen oder sogar ganze VPN-Verbindungen. Dies eröffnet Angreifern eine Vielzahl von Möglichkeiten, Sicherheitsbarrieren ungesehen zu überwinden.

Angesichts dieser Risiken empfehlen einige Sicherheitsexperten und Firewall-Hersteller, den QUIC-Verkehr (UDP auf Port 443) komplett zu blockieren. Dies zwingt die Kommunikation zu einem Fallback auf das traditionelle HTTPS über TCP, wodurch Firewalls ihre Inspektions- und Filterfähigkeiten wieder anwenden können. Dieser Schritt geht jedoch zu Lasten der Performance-Vorteile, die QUIC eigentlich bieten soll.

Dieses Dilemma unterstreicht, dass QUIC einen Paradigmenwechsel in der Netzwerksicherheit erzwingt. Der Fokus muss sich von der reinen Port- und Protokoll-Kontrolle hin zu verhaltensbasierten Analysen und einem Zero-Trust-Ansatz verschieben, bei dem keinem Datenverkehr per se vertraut wird, unabhängig davon, wie er verpackt ist oder welchen Port er nutzt.

Cloudanbieter lieben QUIC

Die Tatsache, dass der QUIC-Traffic Ende-zu-Ende verschlüsselt ist, ermöglicht es Cloudanbietern alle Kundendaten und Programme in ihrer Cloud bearbeiten zu lassen. Der Kunde schaut dann auf seine Daten, wie durch eine Glasscheibe. Er nutzt seinen Laptop dann nurnoch als Anzeigegerät, da er nun seine Daten nicht mehr bei sich zuhause hat.

Eigentlich ein SuperGAU für die Anwender. Denn der Cloudanbieter kann nun in Ruhe alle Kundendaten und -verhalten analysieren. Und so verloren bereits mehrere Nutzer alle Fotos ihrer jungen Familie. Doch nicht nur der Verlust der Daten kann ein Problem darstellen. Auch strafrechtliche Konsequenzen bedrohen den Arbeitsplatz.

Fazit

QUIC und das darauf aufbauende HTTP/3 sind nicht nur ein inkrementelles Update, sondern ein fundamentaler Paradigmenwechsel für das Internet. Durch die geschickte Nutzung von UDP und eine radikale Verschlüsselungsstrategie werden Performance-Flaschenhälse der Vergangenheit beseitigt und die zukünftige Weiterentwicklung des Protokoll-Stacks sichergestellt. Diese Entwicklung erzwingt jedoch ein Umdenken in der Netzwerksicherheit, da traditionelle, auf Deep Packet Inspection basierende Firewalls ihre Sichtbarkeit und damit einen Großteil ihrer Wirksamkeit auf dem Transport-Layer verlieren.