QUIC mit Proxy und Firewall

Der Zugriff auf Informationen im Internet ist bei den meisten Firmen über Firewalls reguliert und nicht wenige Firmen kombinieren die Firewall auch noch mit einem HTTP-Proxy-Server, teilweise mit SSL-Inspection. Solche Schutzfunktionen helfen die Sicherheit zu verbessern, indem je nach Benutzer, Alter, Authentifizierung entweder nur erlaubte Ziele angesprochen werden dürfen oder zumindest die bekannten unerwünschten Seiten blockiert werden. Mit QUIC ist das meiner Ansicht nach nicht möglich.

HTTP-Proxy

Klassische HTTP-Proxy Server nutzen natürlich TCP zur Verbindung vom Client zum Proxy und eine zweite TCP-Verbindung vom Proxy zum Zielsystem. QUIC nutzt aber UDP und da es keine richtige "Verbindung" gibt und auch kein CONNECT kann QUIC nicht über die normalen Proxy-Server verarbeitet werden.

Mit MASQUE gibt es wohl einen ersten Entwurf für einen QUIC-Proxy.

5 - Evaluation of QUIC-based MASQUE Proxying - EPIQ 2021
https://www.youtube.com/watch?v=GKpl3isJHPg

Bislang würde ich aber sagen, dass QUIC keinen Proxy unterstützt und Sie wohl oder übel auf der Firewall den Verkehr reglementieren müssen.

Ein Proxy kann aber natürlich die im QUIC Handshake initiale HTTP/1-Verbindung übertragen und den "Atv-Svc"-Header in der Antwort erkennen. Wenn der Proxy diesen Header entfernt, dann bekommt der Client nie die Information, dass QUIC möglich wäre. Wenn Sie also QUIC gar nicht erst erlauben wollen, dann sollen Sie diesen Weg wählen.

Firewall

Um QUIC ohne Proxy zu nutzen, müssen Sie natürlich einige Voraussetzungen erfüllen:

  • Externe Namenauflösung
    Da der Client die Anfrage nicht an einen HTTP-Proxy sendet, versucht er selbst per DNS den öffentlichen Namen aufzulösen. Wenn ihre Firma z.B. aus Sicherheitsgründen keine externe Auflösung zulässt, dann kann der Client auch keine IP-Adresse für den Namen ermitteln und wird gar nicht erst QUIC versuchen.
  • NAT und Routing
    Ist eine Namensauflösung möglich, dann versucht der Client eine UDP-Verbindung zur Gegenstelle aufzubauen. Der IP-Stack nutzt dazu ihre konfigurierten Leitwege, die letztlich bei einer Firewall mit Verbindung zum Internet landen müssen. Idealerweise ist das eine "naheliegende" Firewall, damit diese Übertragungen nicht noch ihr eigenen WAN belasten. Allerdings muss die Firewall die Adressen dann per NAT umsetzen. Auch wenn QUIC viel weniger Ports als HTTP/1 braucht, kann ein Client sehr wohl mehrere Verbindungen zu unterschiedlichen Zielen aufbauen und ihre externen Schnittstellen an das 65535 Port-Limit bringen.

Auf einer OPNSense ist z.B. QUIC nicht per Default freigeschaltet. Ich habe daher eine Regel addiert, welche UPD auf den Zielport 443 erlaubt und im Live View konnte ich dann schön sehen, wie das Paket einmal vom LAN intern ankommt und über das WAN nach extern weiter geroutet wird

Über den gleichen Live View kann ich natürlich auch sehen, wenn entsprechende Pakete blockiert werden.

QUIC und NAT (30 Sec)

Sobald NAT eine Rolle spielt, sollte ein Administrator auch über Timeouts sprechen. NAT setzt nicht nur interne private Adressen auf öffentliche Adressen um sondern speichert sich diese Zuordnung "Privat"<->"Public" in einer Tabelle, um in Gegenrichtung ankommende Pakete an das passende System zurück zu leiten. Die Firewall erkennt zwar beim ersten ausgehenden Paket den Verbindungswunsch und richtet die Translation ein aber es gibt keinen Prozess um eine Verbindung wieder ordnungsgemäß abzubauen. Selbst mit so einem Prozess würden viele Clients einfach "verschwinden", weil Sie das Netzwerk durch Ausschalten, Abstecken, WLAN-Wechsel verlassen. Ein Netzwerkgerät mit NAT-Funktion muss sich daher mit Timeouts behelfen, wann eine inaktive Sitzung komplett weggeräumt werden kann. Wenn dieser Timeout zu kurz ist, könnte eine im Grund noch aktive Verbindung unterbrochen werden.

Hinweis: TCP-Verbindungen könnten bis zu 2 Stunden ohne Aktivität als "bestehend" angesehen werden

So lange lässt aber keine Firewall eine inaktive Session bestehen, denn Ports sind knapp und kostbar. Siehe auch 65535 Port-Limit, Cloud Portlimit - Firewall und Proxy und Cloud NAT/Proxy. Zum Glück ist QUIC hier ziemlich bodenständig und überreizt die NAT-Limits nicht. Nach spätestens 30 Sekunden sendet ein Client mit QUIC-Nutzung ein kleines UDP-Pakete als "Keep Alive"


https://quicwg.org/ops-drafts/draft-ietf-quic-applicability.html#name-session-resumption-versus-k

QUIC uses a relatively conservative NAT timeout of 30 seconds, so 120 seconds should be more than enough. That being said, we're actively working on handling port and IP migrations smoothly in QUIC, so even that wouldn't be as large a problem in the close future
Quelle https://groups.google.com/a/chromium.org/g/proto-quic/c/VZudByfcOlg

Das ist wohl schon der Tatsache geschuldet, dass viele Firewalls von sich aus für UDP deutlich kürzere Timeouts definiert haben, als dies für TCP üblich war. Das ist auch in einem Memo zu "QUIC Network:

Although the recommended UDP timeout for arbitrary ports is two minutes (Section 4.3 of [RFC4787]), some residential CPE devices have a 30 second timeout and a majority have a three minute timeout ([homeCPE][tsvarea]). Longer timeouts are provided to connection-oriented TCP -- 4 minutes during connection establishment and 2 hours after connection establishment [homeCPE]. Such short timers are not a problem if the mapping is destroyed and the client sends data first, as a new mapping will be created and QUIC handles a new mapping (on a new UDP port or even on a new IP address) without an additional round-trip with its Connection Id.
Quelle: Network Path Requirements for QUIC  https://danwing.github.io/quic-network-req/draft-wing-quic-network-req-00.html

Wenn Sie einen Chromium Netzwerktrace starten und dann diesen anzeigen lassen, sehen sie den Wert auch in den QUIC Optionen:

Das ist deutlich kürzer als der Session Timeout bei TCP.

Firewall Inspection

Viel unangenehmer ist für Firmenadministratoren und Sicherheitsbeauftragte aber die generelle Verschlüsselung von Funktion QUIC mit TLS 1.3. Eine Firewall hat eigentlich keine Change hier etwas über den Inhalt in Erfahrung zu bringen. Sie kann nur anhand der Ziel-IP grob den Provider erkennen. Vielleicht kann die Firewall vorab noch die DNS-Anfrage und die IP-Adresse aus der Antwort ermitteln und damit vermuten, wohin der Client eigentlich möchte. Da aber immer mehr legitime aber auch kriminelle Anbieter den Mehrwert der Content Delivery Netzwerken (CDN) nutzen, bekommen Sie bei einer einfachen Betrachtung der IP-Adresse dann eben Cloudflare, Akamai, Azure-CDN oder einen anderen Anbieter als Ergebnis. Das finden wir auch in einigen Foren der klassischen Firewall-Hersteller:

QUIC traffic is completely opaque to us. There is no way currently to: Decrypt QUIC traffic (i.e. with HTTPS Inspection) See the website(s) being browsed over QUIC  Which means: if you care about the kinds of websites your end users attempt to access (e.g. you block access to porn), you should block QUIC. This is irrespective of whether or not you use HTTPS Inspection. 
Quelle: https://community.checkpoint.com/t5/Security-Gateways/Quic-protocol/m-p/176488#M32310

Hier sind noch viele Fragen offen. Sie könnten aber heute schon mal in den Logs schauen, wer QUIC versucht oder sogar schon unbemerkt nutzt.

Denken Sie bei all den Firewall-Einstellungen auch an die Benutzer im Homeoffice mit Split/Tunnel-VPN und deren Namensauflösung und IPv6-Kompatibilität. Es wäre nicht das erste mal, dass eine Firma behauptet, wie habe ein strenges "Tunnel-VPN", weil alle Pakete und auch die Namensauflösung ins Firmennetzwerk laufen aber dann IPv6 übersehen wird.

Weitere Links