QUIC und Wireshark

Clients und Server, die QUIC verwenden, nutzen statt HTTPS over TC/443 eben UDP als darunterliegendes Protokolle. Da ansonsten der Port 443 für UDP quasi noch nie genutzt wurde, können wir mit einem einfachen Capture-Filter in Wireshark diese Verbindungen suchen.

icmp or udp port 443

Ich addiere gerne "or imcp", damit auch auch aktive Rückmeldungen von Firewalls wie "Destination unreachable" etc. erkenne.

Wählen Sie die aktuelle Netzwerkkarte aus, geben den Filter ein und starten das Capture:

Nun heißt es einfach etwas warten oder mit meinem kompatiblen Client eine QUIC-Webseite wie z.B. www.google.com anzusurfen. Meist reicht aber einfach ein paar Minuten, bis sich jemand verrät, hier ist es eine Anfrage an den Google PlayStore, wie Sie im ersten Paket, welches auch den TLS-Handshake enthält, sehen können. Das Paket ist schon 1392 Bytes lang:

Interessant, dass im "Client Hello" der Name im Klartext zu sehen ist, wo das doch grade ein Vorteil von TLS 1.3 sein sollte, um Schnüfflern das Filtern etwas zu erschweren. So ist es aber ein guter Indikator für Firewalls zukünftig Verbindungen auf 443/UDP gezielt zuzulassen.

Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 [TLS-ECH]. This would make SNI-based application identification impossible by on-path observation for QUIC and other protocols that use TLS.
Quelle: https://quicwg.org/ops-drafts/draft-ietf-quic-manageability.html

Beachten Sie, dass das Paket nicht nur 1392 Bytes groß ist, sondern am Ende 600 Bytes "gefüllt" sind. QUIC prüfte damit schon beim ersten Paket die MTU-Size (Siehe  Maximum Transmission Unit (MTU) und Fragmentierung). Die ist nämlich bei QUIC auf 1392 Bytes festgelegt, so das die auf Ethernet möglichen 1514 Bytes gar nicht ausgenutzt werden. Es gibt aber noch einen zweiten Aspekt, wenn das erste Paket eine Mindestgröße haben muss. DDos-Attacken werden teurer für den Angreifer, da er nicht mit einem kleinen Paket an einen Server mit falsche Source-IP-Adresse eine große Antwort des Servers an das Opfer verursachen kann. Der Angreifer muss schon eine gewisse Bandbreite aufbringen, auch wenn die Antwort des Servers durch das schon enthaltene TLS-Zertifikat immer noch größer ist.

QUIC spielt seine Stärken nicht im LAN aus sondern im WAN, wo kleinere Pakete üblich sind.

Auch die Antwort ist entsprechend 1392 Bytes "groß" um über die Antwort die Durchgängigkeit zu bestätigen und enthält im QUIC Handshake auch schon die TLS Antwort:

Nach dem zweiten Paket komm eine kurze Quittung. Alle Pakete haben eine Prüfsumme, so dass Veränderungen schon früh erkannt und das Paket verworfen werden können.