Übersicht Fachbeiträge

Fachbeiträge

HTTP/3 wird zum Standard


Welche Bedeutung hat dies für Internet, VoIP und Video?

4.11.2022

Autor: Benjamin Pfister

[Erschienen in: VAF Report 2/2022] Die finale Version von HTTP/3 ist im Juni 2022 im RFC 9114 als »Proposed Standard« veröffentlicht worden. Die Entwicklung von HTTP/3 ist für Systemhäuser von Interesse, da der potenzielle SIP-Nachfolger »Real-Time Internet Peering for Telephony Protocol« (RIPT) u.a. auf HTTP/3 aufbaut.



Bild 1: Vergleich HTTP/2- vs. HTTP/3-Protokollstapel



Zum Autor:

Benjamin Pfister, Pfister IT-Beratung

Benjamin Pfister ist Sachgebietsleiter Telekommunikation und Netze der Stadt Kassel und Gründer seiner Firma Pfister IT-Beratung. Gemeinsam mit dem VAF arbeitet er an Empfehlungen des AMEV mit und schreibt als Experte Fachartikel in VAF-Publikationen.



Die Anzahl der auf dem Hypertext Transport Protocol (HTTP) aufbauenden Dienste im Web nimmt immer weiter zu. Neben Infrastrukturdiensten wie DNS over HTTP (DoH) finden sich darunter zunehmend auch Echtzeitdienste, wie z. B. bei Audio- und Videodaten in Unified Communication as a Service (UCaaS) und Webkonferenzsystemen. Wo früher lediglich aktive Abfragen der Anwender von Webseiten über HTTP stattfanden und statischer Content in der Antwort folgte, ist heute wesentlich mehr Interaktion zu verzeichnen. HTTP/3 kombiniert die Vorteile von HTTP/2, wie Stream Multiplexing und Server Push, mit dem Transportprotokoll QUIC zur schnelleren und stabileren Datenübertragung.

Bisherige Herausforderungen von HTTP

Die Webtechnologien bauen grundsätzlich noch auf dem 1981 veröffentlichten Transmission Control Protocol (TCP) sowie dem 1990 von Tim Berners-Lee am CERN in Genf erfundenen HTTP auf. Mobile Nutzung, interaktive Inhalte und Echtzeitkommunikation bringen jedoch einige Herausforderungen für Webapplikationen mit sich, die mit den klassischen Protokollen nur noch bedingt handhabbar sind. So bringt beispielsweise ein Wechsel des Zugangsmediums einer verkabelten Ethernet-Verbindung hin zu einer mobilen Datenverbindung auch eine Änderung der IP-Adresse mit sich. Der TCP-Socket, der darauf aufbaut, wird unterbrochen und ein neuer muss aufgebaut werden, was zu Verzögerungen und Verbindungsabbrüchen führen kann. Zudem bietet die TCP-Übertragung, die bis zu HTTP/2 zum Einsatz kommt, das Risiko eines sogenannten Head-of-Line Blocking. Dabei bremst ein verlorenes Paket im Stream durch die TCP Congestion Control (Staukontrolle) alle anderen Streams aus.

Diese müssen warten, bis das Paket wiederholt übertragen und empfangen wurde. Aber auch die Notwendigkeit serverseitiger Push-Operationen, also serverseitig initiierter Übertragung, wie beispielsweise die proaktive Auslieferung von Javascript zu einer Webseite, bringt die alten Protokolle an ihre Grenzen. Während in anderen Bereichen wie HTML inzwischen bei einem hohen Anteil der Webseiten neue Versionen (HTML 5) eingesetzt werden, läuft heutzutage noch sehr viel Kommunikation über das alte HTTP/1.1.

Bild 2

Bild 2: TCP & TLS vs. QUIC-Handshake: Bei QUIC ist der Transportweg verkürzt.

Neuer Unterbau

Den geänderten Anforderungen an Mobilität und stabile sowie latenzoptimierte Übertragung versucht die Internet Engineering Task Force (IETF) nun mit dem in RFC 9114 definierten HTTP/3 gerecht zu werden. HTTP/3 baut, wie in Bild 1 im rechten Bereich ersichtlich, auf dem verbindungslosen User Datagram Protocol (UDP) sowie dem im vergangenen Jahr standardisierten Quick UDP Internet Connections (QUIC) auf.
QUIC ermöglicht einen schnelleren initialen Verbindungsaufbau durch einen optimierten Handshakeprozess. In diesen ist der TLS-1.3-Handshake direkt integriert. Die Verwendung von TLS 1.3 ist dabei in QUIC gemäß RFC 9000 obligatorisch. Einen Vergleich zwischen TCP inklusive TLS 1.2 und QUIC mit dem integrierten TLS-Handshake stellt Bild 2 dar. Die Vereinfachung bzw. die Verkürzung ist auf den ersten Blick ersichtlich. Diese Optimierung hilft insbesondere bei hoher Latenz, wie beim Zugriff auf Public-Cloud-Ressourcen, da der Transportweg in einer geringeren Anzahl von Schritten passiert werden muss.

Eigenschaften von HTTP/3

Neben den positiven Eigenschaften durch den QUIC-Unterbau gibt es weitere Vorteile. Bereits in HTTP/1.1 gab es ein sogenanntes Pipelining, also die Möglichkeit, mehrere Requests parallel über einen TCP-Stream zu liefern. Dies verringert die Verzögerung, da keine multiplen TCP- und TLS-Handshakes notwendig sind. Das verbessert die Eigenschaften bei Anfragen/Antworten zu mehreren WebsiteElementen wie CSS, Javascript und HTML. Der Server musste jedoch bei diesem Verfahren die Responses in der gleichen Reihenfolge wie die zugehörigen Requests versenden.


Bild 3: Packet Loss bei TCP vs. Packet Loss in einem QUIC-Stream bei Stream Multiplexing in HTTP/3



Quellen und Links


RFCs

RFC 9114 – HTTP/3, 2022
https://datatracker.ietf.org/doc/rfc9114/

RFC 2616 – Hypertext Transfer Protocol - HTTP/1.1, 1999
https://tools.ietf.org/html/rfc2616

RFC 7230 – HTTP/1.1 Message Syntax and Routing, 2014
https://tools.ietf.org/html/rfc7230#section-6.3.2

IETF Draft : RealTime Internet Peering for Telephony, 2020
https://datatracker.ietf.org/doc/html/draft-rosenbergjennings-dispatch-ript-00


Artikel

Website Fingerprinting on Early QUIC Traffic, Pengwei Zhana,b, Liming Wanga, Yi Tang, China, Nov. 2021
https://arxiv.org/abs/2101.11871

Dissecting Performance of Production QUIC, Alexander Yu and Theophilus A. Benson, Ljubljana Slovenia, April 2021
https://cs.brown.edu/~tab/papers/QUIC_WWW21.pdf

Our Roadmap for QUIC and HTTP/3 Support in NGINX, Liam Crilly of F5, Juli 2021
https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/

Nearly half of malware now use TLS to conceal communications, Sean Gallagher, April 2021
https://news.sophos.com/en-us/2021/04/21/nearly-half-of-malware-now-use-tls-to-conceal-communications/

Has encryption made your current firewall irrelevant? Five TLS inspection capabilities you need in your next firewall, Sophos Whitepaper, June 2021
https://www.sophos.com/de-de/medialibrary/Gated-Assets/white-papers/sophos-encryption-firewall-wp.pdf

TLSv1.3 Decryption, Palo Alto Networks, Juli 2022
https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-admin/decryption/decryption-concepts/tlsv13-ssl-decryption-support


Weiterführende Links

Why We Love QUIC and HTTP/3, März 2019
https://news.ycombinator.com/item?id=19476439

Enabling HTTP/3 support on Windows Server 2022, Tommy Jensen (tojens), August 2021
https://techcommunity.microsoft.com/t5/networking-blog/enabling-http-3-support-on-windows-server-2022/ba-p/2676880

Enabling QUIC and HTTP/3; März 2022
https://docs.litespeedtech.com/lsws/cp/cpanel/quic-http3/

https://http3-explained.haxx.se/en/criticism



Über ein Stream Multiplexing wurde bei HTTP/2 die Zuordnung der Antwortreihenfolge aufgehoben. Somit konnten einzelne Anfragen, deren Verarbeitung auf dem Server länger braucht, nicht mehr den gesamten Stream blockieren bzw. ausbremsen. Es bleibt jedoch dabei, dass bei verlorenen Paketen in HTTP/1.1 und HTTP/2 durch das zugrunde liegende Transportprotokoll TCP alle nachfolgenden Pakete auf die Retransmission warten müssen. Dies ist bei HTTP/3 auf Basis von QUIC, wie in Bild 3 dargestellt, nicht mehr der Fall. Wie HTTP/2 ermöglicht auch HTTP/3 ein serverseitiges Pushen von Daten, was jedoch recht aufwendig in der Implementierung sein kann. Dies kann beispielsweise zur Signalisierung von neuen Anrufen oder Nachrichten in UCC Applikationen zum Einsatz kommen.
Neu in HTTP/3 ist zudem die Möglichkeit eines Wechsels des Transportmediums innerhalb einer bestehenden Verbindung, wie z. B. beim Wechsel von LAN oder WLAN zu einem Mobilfunknetz, wenn der Arbeitsplatz verlassen wird. Dieses Feature basiert auf der Entkopplung von IP-Adresse und Portinformation bei QUIC auf Basis von sogenannten Connection Identifiers. Innerhalb der QUIC-Kommunikation kommen diese für die Zuordnung der Verbindung zum Einsatz. Innerhalb dieser Connection können dann mehrere Streams übertragen werden.

Unterstützung auf Client und Serverseite

Der beste Standard nutzt jedoch im Fall fehlender Praxisimplementierungen nichts. Dort tut sich aktuell einiges. So unterstützen auf Clientseite Google Chrome, Microsoft Edge, Mozilla Firefox sowie Safari bereits HTTP/3. Auf Serverseite fehlt aktuell jedoch noch eine Implementierung im beliebten Apache Webserver. Microsofts aktuelle Serverversion 2022, genauer gesagt der darauf aufbauende Webserverdienst Internet Information Server (IIS), kann bereits mit HTTP/3 umgehen. Gleiches gilt für den LiteSpeed Webserver sowie in einer Preview auch für NGINX.

Grundlage des SIP-Nachfolgers

Die Entwicklung von HTTP/3 ist für Systemhäuser im Hinblick auf den potenziellen SIP-Nachfolger »Real-Time Internet Peering for Telephony Protocol« (RIPT) von Interesse, da er auf QUIC und HTTP/3 aufbaut (VAF Report berichtete in Ausgabe 2/2020). Die ersten Entwürfe erschienen Anfang 2020 bei der IETF, die jedoch aktuell als »abgelaufen« geführt werden. Man kann jedoch davon ausgehen, dass dies daran liegt, dass zunächst die finalen Versionen von QUIC und HTTP/3 veröffentlicht werden sollten.
Dies war in Form von QUIC im RFC 9000 im Mai 2021 und bei HTTP/3 im Juni 2022 der Fall. RIPT soll perspektivisch SIP, SDP, RTP und WebRTC ersetzen. Somit wären dann
sowohl Signalisierungs- als auch die Mediendaten obligatorisch verschlüsselt.

Bild 4: Einsortierung HTTP/3 in Protokollstapel für den potenziellen SIP-Nachfolger RIPT (rechts); klassischer Protokollstapel mit SIP und RTP (links)

Verbindungsab- und aufbau

Bevor eine HTTP/3-Anfrage vom Client an den Server versendet werden kann, braucht es eine bestehende QUIC-Connection. Dafür wird, wie in Bild 2 dargestellt, initial ein sogenannter 1-RTT-Handshake (One RoundTrip Time) von QUIC benötigt, bei dem der TLS-Handshake integriert ist. Sobald durch den ersten Handshake entsprechendes Schlüsselmaterial auf Clientseite vorhanden ist, kann der Client bei neuen Anfragen darauf aufbauen und muss keinen Handshake mehr durchführen. Er kann also seine Anfrage direkt an den Server versenden ohne Verzögerung durch einen zusätzlichen neuen Handshake. Dies nennt man bei QUIC 0-RTT (Zero Round-Trip Time). Auf diesem Feature kann auch HTTP/3 aufbauen. Ob HTTP/3 zur Anwendung kommt, kann trotz der TLS-Verschlüsselung wie in Bild 5 ersichtlich im QUIC-Handshake am Application-Layer Protocol Negotiation (ALPN) »h3« erkannt werden. Dabei muss zwingend auch der Zielserver anhand der Angabe zur Server Name Indication (SNI) erkennbar sein. Im Beispiel in Bild 5 war dies update.googleapis.com.
Jede Seite der Verbindung muss zu Beginn der Verbindung einen Kontrollstream aufbauen und einen Frame mit den entsprechenden SETTINGS übermitteln. HTTP-Requests senden Clients jeweils in einem Request Stream. Dieser ist als bidirektionaler QUIC-Stream definiert. Über einen Stream darf nur ein einzelner Request laufen, um das zuvor genannte Head-ofLine Blocking zu verhindern. Nach dem Request muss der Client den Stream sendeseitig schließen. Nachdem der Server seine finale Antwort gesendet hat, schließt auch er seine Senderichtung des bidirektionalen Streams. Die gesamte HTTP/3-Connection (nicht der Stream) besteht jedoch über alle Requests hinweg. Push-Ereignisse des Servers erfolgen hingegen über serverinitiierte unidirektionale QUIC-Streams.


Bild 5: Trotz der zwingenden Verschlüsselung mit TLS 1.3 kann das Protokoll HTTP/3 am ALPN „h3“ erkannt werden. Selbst der Beispiel-Zielserver „update.googleapis. com“ kann erkannt werden.

Eine HTTP/3-Connection kann über einen sogenannten GOAWAY-Frame sanft beendet werden, der dem Empfänger die Requests oder Pushes darstellt, die in dieser Verbindung verarbeitet wurden oder verarbeitet werden sollen. Über einen QUIC CONNECTION_CLOSE kann jederzeit allerdings auch eine sofortige Beendigung erfolgen.

Kompatibilität

Konnektivitätsprobleme, also falls beispielsweise UDP komplett oder der spezifisch genutzte Port geblockt sein sollte, können zu Fehlern beim QUIC-Verbindungsaufbau führen. Der Client sollte gemäß dem RFC versuchen, TCP-basierende Versionen von HTTP einzusetzen.

Kritische Punkte

Forscher hegen jedoch Bedenken gegen QUIC und HTTP/3. In mehreren Papers, die auch in den Quellen dargestellt sind, stellen sie Datenschutzprobleme aufgrund von Website-Fingerprinting dar. Aber auch die Performance einzelner Implementierungen verbessert sich nicht zwingend im Vergleich zu HTTP/2. Dabei stellen die Forscher dar, dass dies eher an der Art der Implementierung von QUIC als an der Protokollspezifikation liegt. QUIC erzeugt jedoch gemäß Angaben einiger Experten bei hohen Datenraten auch wesentlich höhere CPU-Lasten als HTTP/2 in Kombination mit TCP und TLS.
Eine weitere Herausforderung birgt HTTP/3 im Zusammenhang mit einer Inhaltskontrolle auf Sicherheitssystemen wie Proxy-Servern. Da HTTP/3 zwingend TLS-1.3-Verschlüsselung voraussetzt, ist eine Kontrolle der Inhalte der übertragenen Pakete nicht mehr ohne Weiteres möglich. Dies war in TLS 1.2 in Kombination mit schwachen Verschlüsselungsalgorithmen ohne Perfect Forward Secrecy (PFS) noch anders. Jedoch steigt auch der Anteil an verschlüsselter Kommunikation von Schadsoftware, um kriminelle Aktivitäten zu verschleiern. Um Schadsoftware zu erkennen, bedarf es nun erweiterter Analysen der Metadaten, wie der Extraktion von Daten aus dem Handshake sowie der Auswertung von Paketlängen und der Byte-Verteilung. Zum Aufbrechen der Verschlüsselung kommen in einigen Fällen auch sogenannte »Downgrades«, also die Abschwächung der Verschlüsselung, zum Einsatz. Konkret wird beispielsweise der UDP-Port 443 geblockt, um auf HTTP/2 und TLS 1.2 mit schwachen Algorithmen zu wechseln und folglich den Datenverkehr inspizieren zu können. Dies birgt zusätzliche Risiken. Einige Hersteller bieten jedoch bereits Sicherheitssysteme an, die TLS-1.3-Datenverkehr entschlüsseln, analysieren und anschließend verschlüsseln können. Wenn jedoch sogenanntes Zertifikatspinning zum Einsatz kommt, also nur das reale Serverauthentifizierungszertifikat vom Client akzeptiert wird, scheitern diese Ansätze.

Fazit

Es bleibt abzuwarten, ob und wann sich HTTP/3 durchsetzen wird. Zwar bringt es interessante Ansätze, welche insbesondere bei der mobilen Nutzung eine große Rolle spielen, wie Verbesserung im Verhalten bei Paketverlusten und Verbesserung im Verhalten bei IP-Changes des Clients bei QUIC. Jedoch sind dies keine Killerfeatures im Vergleich zu HTTP/2. Die entscheidenden Vorteile kommen eher aus der Verwendung von QUIC als von HTTP-spezifischen Protokollanpassungen. Aktuell mangelt es noch an einigen Server­im­ple­men­tier­ungen. Jedoch könnte über die positiven Eigenschaften von HTTP/3 ein noch stärkerer Drang zur »HTTPisierung« des Netzes, also der Abbildung von immer mehr Applikationen auf Basis von HTTP, erfolgen. Dies macht ein Firewalling immer schwieriger. Auch bleibt der Einfluss von UDP-Filtern und IDSVerhalten (Intrusion Detection System) bei größerer Verbreitung abzuwarten.



Veröffentlicht am: 20.10.2022