Die Nutzung von QUIC nimmt ständig zu. In Verbindung mit HTTP/3 soll QUIC die Einschränkungen von älteren Protokollen wie TCP und HTTP/1.1 überwinden. Allerdings existiert QUIC nicht für sich allein. Es muss mit anderen Netzkomponenten wie Firewalls interagieren und häufig kommt es dabei zu Problemen.
QUIC, auch bekannt als Quick UDP Internet Connections, ist nicht neu. Mein Kollege Dr. Joachim Wetzlar hat im Oktober 2022 den Artikel „Ist QUIC schneller als TCP?“ [1] im Netzwerk Insider veröffentlicht. QUIC wurde erstmals in 2012 implementiert und eingesetzt und soll die TCP-Sicherheitsfunktionen beibehalten, aber gleichzeitig wie UDP eine schnelle Übertragung ermöglichen. Der aktuelle Standard für QUIC ist in RFC 9000 definiert, der im Mai 2021 veröffentlicht wurde. Im Vergleich zu TCP/TLS ermöglicht QUIC einen schnelleren Verbindungsaufbau und beseitigt das bei TCP auftretende Head-of-Line-Blocking.
Der Grund für den schnelleren Verbindungsaufbau ist die reduzierte Anzahl von Handshake-Nachrichten. QUIC basiert auf UDP, sodass die sonst bei TCP erforderlichen drei Handshake-Nachrichten eingespart werden. Überdies verwendet es TLS 1.3 für den Handshake und die Generierung von Schlüsseln. Somit ist nur ein Roundtrip erforderlich, um einen Kommunikationspfad aufzubauen.
QUIC nutzt den UDP-Port 443, der auch für HTTPS verwendet wird. Falls dieser blockiert ist, weicht QUIC auf TCP/TLS aus. HTTP/3, das auf QUIC aufsetzt, hat HTTP/2, das auf TCP aufsetzt, langsam überholt [2]. Somit müssen die Firewalls immer mehr dieser Pakete bearbeiten und bei Bedarf gezielt blockieren.
Die Herausforderungen bei QUIC
SSL Inspection ist ein wichtiger Teil der Cybersicherheit. Das ist der Prozess zur Kontrolle von SSL/TLS-verschlüsselter Internetkommunikation zwischen Client und Server. Die Überwachung kann zwischen Sender und Empfänger und umgekehrt erfolgen. Es handelt sich um die gleiche Technik, die bei Man-in-the-Middle-Angriffen verwendet wird. Die Möglichkeit, verschlüsselten Verkehr einzusehen, ist nicht nur eine „nette Zusatzfunktion“, sondern eine unverzichtbare Voraussetzung für die Erkennung und Abwehr komplexer Bedrohungen geworden.
In der Regel wird QUIC auf Firewalls gezielt blockiert, weil es vollständig verschlüsselt ist und deswegen von einer SSL Inspection nicht geprüft werden kann. Bei einigen Firewalls kann die Aktion Block/Deny verwendet werden, damit der Client auf HTTPS zurückgreift. Alternativ kann die Aktion Block/Drop gesetzt werden, wodurch die Pakete verworfen und die Verbindung an der Firewall blockiert wird. Beim Aufrufen einer Webseite ist es zwar nicht ideal, eine Sekunde länger auf das Laden zu warten, in den meisten Fällen ist dies jedoch nicht kritisch. Allerdings kann es bei Anwendungen wie Zoom und Teams, deren Signalisierungsverkehr mittlerweile auch mittels QUIC übertragen wird, zu großen Performance-Problemen kommen. Auch Anwendungen wie Citrix sind inzwischen von QUIC abhängig, da die Latenz ohne QUIC zu hoch wäre.
Einrichtung von QUIC
QUIC wird kontrovers diskutiert. Einige Netzbetreiber blockieren QUIC, um Funktionen wie TLS/SSL Inspection zu ermöglichen. Andere akzeptieren QUIC für bestimmte Fälle, beispielsweise für Netze, die keiner strikten Kontrolle unterliegen, wie z. B. ein Gast-WLAN.
Nach meiner Wahrnehmung überwiegt die Haltung, QUIC zu blockieren. Häufig gibt man der IT-Sicherheit gegenüber der Performance den Vorzug. Viele Webseiten funktionieren auch beim Fallback auf TCP noch ausreichend gut und sind nicht zwingend auf QUIC angewiesen. Dagegen kann es bei zeit- und performancekritischen Anwendungen, wie z. B. Zoom, hilfreich sein, QUIC freizugeben. Zu diesem Zweck wird QUIC gezielt für bestimmte IP-Bereiche oder FQDNs erlaubt.
Next Generation Firewalls unterstützen bereits Patterns für vordefinierte „Network Applications“, in denen die zu einer gängigen Applikation gehörigen IP-Adressen enthalten sind. So ist die Einrichtung der passenden Regel unkompliziert. Dabei sollte zunächst eine kleine Gruppe von Nutzern testen, ob die entsprechenden Anwendungen ordnungsgemäß funktionieren.
Passt QUIC zu „Zero Trust“?
Aktuell widerspricht die Verwendung von QUIC den Zero-Trust-Prinzipien. Eines der Prinzipien lautet: „verify explicitly“, d.h. „explizit überprüfen“. Bei der Anwendung von QUIC muss man stattdessen der Zieladresse vertrauen, weil der Verkehr nicht durch SSL Inspection kontrolliert werden kann. Daher sollte regelmäßig geprüft werden, ob die freigeschalteten Ziele und die von den Anwendungen freigegebenen IP-Adressen und FQDNs übereinstimmen.
Derzeit werden mehr und mehr Firewalls entwickelt, die SSL Inspection auch für QUIC- und HTTP/3-Verkehr unterstützen. Es dürfte daher nicht mehr lange dauern, bis die QUIC Inspection zur Norm wird. Danach würde die Verwendung von QUIC auch Zero-Trust-konform sein.
Fazit
Da immer mehr Anwendungen auf QUIC umgestellt werden, sollte eine Lösung gefunden werden, die einen Kompromiss zwischen Performance und Sicherheit ermöglicht.
Verweise
[1] https://www.comconsult.com/ist-quic-schneller-als-cp/https://www.comconsult.com/ist-quic-schneller-als-tcp/https://www.comconsult.com/ist-quic-schneller-als-tcp/
[2] https://w3techs.com/technologies/comparison/ce-http2,ce-http3





