QUIC Handshake
Damit stellt sich nun die Frage, wie ein Client denn erfährt, dass die Gegenseite "QUIC" kann. Ein Browser können parallel zur TCP-Verbindung natürlich einfach auch UDP versuchen aber das wäre "unfreundlich". da zumindest in den ersten Jahren die meisten Gegenstellen wohl kein QUIC verstehen und der Client nicht sicher weiß, ob er den alten HTTP/1 bzw. HTTP/2 nutzen muss oder die Verbindung per QUIC möglich ist. Zudem würden auch die Firewall-Administratoren viele UDP-Verbindungen auf Port 443 oder 80 sehen und diese in Logs erscheinen.
Auch wenn ich hier QUIC und HTTP3 beschreibe, ist QUIC einfach nur ein weiteres Transportprotokoll und kann von beliebigen Diensten genutzt werden. Microsoft SMB wird auch QUIC nutzen können.
HTTP-Header "Alt-Svc"
Der Wechsel von HTTP/1 auf HTTP/2 wird durch den Client initiiert, der mit dem HTTP-Request den Wunsch einen Upgrade mitteilt. Wenn der Server dies versteht und erlaubt, dann antwortet er entsprechend und wechselt das Protokoll. Das ist einfach, da HTTP/1 und HTTP/2 ja beide über TCP/443 und ggfls. einen Proxy schon eine Kommunikation haben und es für die Firewall damit keinen Unterschied macht. Ein HTTP-Proxy mit Inspection kann den Header modifizieren.
- HTTP 1.1 Upgrade
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade
Bei QUIC geht dies so nicht, denn hier wird das Protokoll von TCP auf UDP gewechselt und der Client kann gar nicht wissen, ob die Firewall oder das Netzwerk eine QUIC-Verbindung erlaubt. Daher startet auch eine QUIC-Verbindung zuerst mit der ersten HTTP-Verbindung über TCP, über die der Browser die gewünschte Seite abruft.
In der Antwort liefert der Server aber nun eine Information, dass er QUIC anbietet. Das macht er über einen eigenen Header "Alt-Svc". Hier z.B.: beim Zugriff auf Amazon.com.
Amazon teilt meinem Browser damit mit, dass ich "HTTP/3" auf dem gleichen Host über Port 443 erreichen darf und mein Browser die Information für 86400 Sekunden = 24 Stunden cachen darf.
Wenn der Parameter "ma" nicht angegeben ist, dann scheint 24h der Default zu sein
Ob der Browser danach eine erfolgreiche HTTP/3-Verbindug aufbauen konnte, sehen Sie z.B. auch im Chromium Debugger, wenn sie die Tabellenspalte "Protocol" einblenden.
Ein "h3" zeigt die Dateien an, die über HTTP/3, d.h. QUIC/UDP übertragen wurden. Natürlich können Sie auch mit WireShark die UDP-Pakete erfassen, aber da alles verschlüsselt ist, werden Sie keine Inhalte sehen.
- QUIC im Internet
- QUIC mit IIS
- RFC 7838 HTTP Alternative Services
https://www.rfc-editor.org/rfc/rfc7838 - Alt-Svc
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc - Bootstrap with Alt-svc
https://http3-explained.haxx.se/en/h3/h3-altsvc
Das können wir per PowerShell einfach prüfen.
Function Test-QUICOffer { param ($url) try { (Invoke-WebRequest -Uri $url -Method head -UseBasicParsing).headers."Alt-Svc" } catch { $_.exception.response.headers.GetValues("Alt-Svc")} }
Auf der Seite QUIC im Einsatz habe ich einige Gegenstellen aufgeführt, die ich 2021 und 2024 geprüft habe.
QUIC per DNS
Die Prüfung von QUIC über den ALT-SVC-Header bedeutet aber, dass der Client erst einen HTTP/TCP-Verbindung aufbauen und einen Request ausführen muss. Um diese Vorarbeit zu ersparen, gibt es einen neuen DNS-Eintrag, mit dem ein Client schon per DNS-Abfrage mehr über den Webserver erfahren kann. Das könnte z.B. so aussehen:
msxfaq.de IN HTTPS 10 www.msxfaq.de alpn="h3,h2" port=8443
Ein Browser könnte dann beim Zugriff auf "mxsfaq.de" per HTTPS diesen Namen auflösen und bekommt die Hostadresse "www.msxfaq.de" aber auch die Information, dass er Webserver HTTP/3 und HTTP/2 unterstützt aber abweichend auf Port 8443 statt 443 auf Anfragen wartet. Sie sehen aber auch eine Priorität (10), die damit auch Backup-Server bereitstellen kann.
Diese Option wird anscheinend nicht aktiv genutzt. Gesehen habe ich es noch nicht und das müsste der DNS-Server und DNS-Resolver unterstützten. Auch im April 2024 hat auf meinem Windows 11 Client weder "NSLOOKUP" noch die PowerShell "Resolve-DNSName" den "HTTPS"-Typ unterstützt.
Browser können es aber schon. Zuerst hat Apple schon im Jahr 202 angefangen und mittlerweile haben alle anderen (Edge, Chrome, Vivaldi, Brave etc. auch nachgezogen. Bei Firefox muss man es mit "about:config" erst einschalten. Schlecht sieht es auch bei den verschiedenen DNS-Hostern aus, die noch keine HTTPS-Einträge in DNS-Zonen erlauben.
- RFC 9460 Service Binding and Parameter Specification via the DNS (SVCB and
HTTPS Resource Records)
https://datatracker.ietf.org/doc/rfc9460/ - NPN and ALPN (20 Mar 2013)
https://www.imperialviolet.org/2013/03/20/alpn.html - Wie der HTTPS-Eintrag das DNS erweitert und warum er so nützlich ist
https://www.heise.de/ratgeber/Wie-der-HTTPS-Eintrag-das-DNS-erweitert-und-warum-er-so-nuetzlich-ist-9658803.html - Speeding up HTTPS and HTTP/3 negotiation with... DNS
https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns - The Use Cases and Benefits of SVCB and HTTPS DNS Record Types
https://www.domaintools.com/resources/blog/the-use-cases-and-benefits-of-svcb-and-https-dns-record-types/ - HTTPS-Records (HTTPS Service binding and parameter specification)
https://simpledns.plus/help/https-records - SVCB / HTTPS: Zwei neue
DNS-Eintragstypen
https://blog.nameshield.com/de/2023/02/20/svcb-https-zwei-neue-dns-eintragstypen/
QUIC Timeout
Der Client hat erfolgreich eine Verbindung aufgebaut und den Alt-Svc bekommen. Was macht er aber nun, wenn die Verbindung per QUIC dennoch nicht zustande kommt? Wie lange versucht der Client eine QUIC-Verbindung, ehe er wieder auf TCP zurückfällt.
Beachte dazu die Seite QUIC und Timeout