Was ist QUIC? Das Protokoll verstehen
Ein Protokoll definiert, wie Daten über das Internet zwischen zwei Geräten übertragen werden. Und da die Protokolle zwischen Client und antwortendem Server aufeinander abgestimmt sein müssen, hat sich die Branche überwiegend auf einige wenige, weit verbreitete Standardlösungen gestützt. Zu den ältesten Protokollen gehören TCP und UDP, die beide schon seit Jahrzehnten existieren.
Dies änderte sich im Jahr 2013, als Google begann, einen neuen Ansatz zu erproben: Das QUIC-Protokoll bietet der Google Anwendung die Möglichkeit, Daten schneller und mit geringerer Protokolllatenz als mit herkömmlichen Protokollen zu übertragen.
Wie funktioniert das QUIC-Protokoll?
QUIC ist ein verschlüsseltes Transportprotokoll, das auf UDP aufbaut. Es wurde entwickelt, um die Geschwindigkeit von UDP mit der Sicherheit von Protokollen wie TLS zu kombinieren und so effektiv eine schnelle und sichere Internetverbindung herzustellen.
Im Gegensatz zu herkömmlichen Protokollen, bei denen Authentifizierung und Verschlüsselung durch Lösungen höherer Schichten wie TLS verwaltet werden, integriert QUIC diese Funktionen direkt in die Transportschicht.
Dadurch ist QUIC schneller und effizienter für den modernen Webverkehr.
- Es funktioniert durch die Einleitung eines schnellen Handshake-Prozesses, der es ermöglicht, rasch eine sichere Verbindung herzustellen.
- Sobald der Handshake abgeschlossen ist, sendet QUIC mehrere verschlüsselte Datenströme gleichzeitig an den Server, wodurch die Latenz reduziert und die Leistung verbessert wird.
Durch die Integration von Authentifizierung und Verschlüsselung in das Protokoll selbst optimiert QUIC die sichere Kommunikation und erhält gleichzeitig die Vorteile des geringen Gewichts von UDP bei.
Fast Handshake
Der Handshake ist ein entscheidender Bestandteil jedes Netzwerkprotokolls. QUIC ersetzt den traditionellen Drei-Wege-Handschlag, der bei TCP verwendet wird, durch den Authentifizierungs- und Verschlüsselungsprozess des TLS 1.3-Handschlags.
Vereinfacht ausgedrückt umfasst eine typische TCP-Verbindung Folgendes:
- Der Client sendet ein SYN-Paket
- Der Server antwortet mit einem SYN-ACK-Paket
- Der Client schließt die Verbindung mit einem ACK-Paket ab.
Dieser dreistufige Prozess ist erforderlich, bevor Daten übertragen werden können.
QUIC umgeht diese Anforderung durch die Verwendung von UDP. Da UDP keine Verbindungsherstellung in gleicher Weise erfordert, ermöglicht QUIC die sofortige Datenübertragung über UDP-kompatible Verbindungen und reduziert so die Latenz.
In einigen Fällen kann QUIC Daten bereits im ersten Verbindungszyklus senden – dies wird als 0-RTT (Zero Round Trip Time) bezeichnet. Dies ist möglich, wenn der Server bereits eine zwischengespeicherte Verbindung zum Client hat. Aber obwohl 0-RTT die Geschwindigkeit verbessert, ist es nicht immer die sicherste Option und kann Daten Replay-Angriffen aussetzen, wenn es nicht ordnungsgemäß gehandhabt wird.
Verschlüsselung
Zusätzlich zum schnellen Handshake bietet QUIC eine integrierte Verschlüsselung. Traditionell wurde bei TCP die Verschlüsselung separat über das TLS-Protokoll abgewickelt, welches einen eigenen Handshake zur Aushandlung der Version und der Verschlüsselungssuite erforderte. Dieser Handshake legte die Verschlüsselungsalgorithmen und -protokolle fest, die für die Sitzung verwendet werden sollten.
Da QUIC auf UDP basiert, modifiziert es den traditionellen TLS-Handshake, um ihn an seine optimierte Architektur anzupassen. QUIC erreicht dies durch das Senden eines Client Hello (CHLO), das in zwei spezifische Komponenten eingebettet ist:
- Ein erstes Paket
- Ein Krypto- Rahmen
Diese Paketierung ermöglicht es, den kryptografischen Handshake in das allererste UDP-Datagramm einzubinden, das der Client sendet. Dadurch werden Transport- und Verschlüsselungs-Handshakes zu einem einzigen, effizienten Schritt zusammengeführt. Nach diesem anfänglichen Datenaustausch verhält sich QUIC weitgehend wie TLS 1.3.
Die gesamte nachfolgende Kommunikation zwischen Client und Server wird mit Hilfe der Sitzungsschlüssel aus dem Handshake verschlüsselt.
Paketbestellung
QUIC basiert auf UDP, einem Protokoll, das für seine Geschwindigkeit, aber nicht für seine Zuverlässigkeit bekannt ist – Pakete können verloren gehen oder in falscher Reihenfolge ankommen. TCP gewährleistet zwar Zuverlässigkeit, jedoch auf Kosten erhöhter Latenzzeiten. Bei TCP werden, wenn in einem Datenstrom ein Fehler auftritt, alle gleichzeitig vom Client kommenden Datenströme angehalten, bis das Problem behoben ist.
QUIC schafft ein Gleichgewicht zwischen Geschwindigkeit und Zuverlässigkeit, indem es Daten in unabhängige Datenströme organisiert und sicherstellt, dass jeder Datenstrom seine eigene interne Paketreihenfolge beibehält.
QUIC erzwingt jedoch keine Paketreihenfolge zwischen verschiedenen Datenströmen.
Stellen Sie sich beispielsweise vor, dass zwei Datenströme – Strom A und Strom B – von einem Server zu einem Client übertragen werden.
- Stream A. Falls ein Paket von Stream A verloren geht, wird Stream A die erneute Übertragung selbstständig durchführen.
- Der Datenstrom B läuft ununterbrochen weiter und kann seine Übertragung abschließen, ohne durch den Verlust im Datenstrom A beeinträchtigt zu werden.
Diese hohe Stream-Unabhängigkeit ist eine wesentliche Verbesserung gegenüber früheren Protokollen wie HTTP/2, bei denen Paketverluste in einem Stream andere Streams, die dieselbe Verbindung nutzten, zum Stillstand bringen konnten.
Die Herausforderungen des QUIC-Protokolls
Obwohl QUIC bereits einen erheblichen Teil der Anwendungsdaten von Google transportiert, ist seine breitere Akzeptanz in global verteilten Umgebungen nach wie vor begrenzt.
Eine der größten Hürden ist das langsame Tempo des Wandels in der Internetinfrastruktur. TCP ist seit über 40 Jahren das dominierende Transportprotokoll und kann praktisch jede Art von Daten übertragen. Während QUIC klare Vorteile bietet, insbesondere bei der Reduzierung der Latenz über große Entfernungen, wie z. B. bei interkontinentalen Verbindungen, werden seine Vorteile im Vergleich zur Vielseitigkeit von TCP oft als begrenzt angesehen.
Google hat die Einführung von QUIC aggressiv vorangetrieben und dessen Entwicklung und Integration in seine Dienste beschleunigt. Dies hat jedoch viele Unternehmen in Bedrängnis gebracht, sich an neue Standards und Trends anzupassen.
Daher bleiben die Herausforderungen bei der Implementierung von QUIC beträchtlich, insbesondere für Organisationen mit komplexer Infrastruktur, veralteten Systemen oder fehlendem internen Fachwissen.
Risiken von 0-RTT
Bei zwischengespeicherten Verbindungen ermöglicht QUIC das Senden von Daten bereits beim ersten Roundtrip – bekannt als 0-RTT. Dieser Ansatz beseitigt zwar effektiv die Latenz beim Handshake, birgt aber erhebliche Sicherheitsrisiken.
Ein wesentliches Risiko besteht im Fehlen eines aktuellen kryptografischen Handshakes. Wenn die ursprüngliche Verbindung, die zum Zwischenspeichern von Sitzungsinformationen verwendet wurde, kompromittiert wurde, könnten auch alle Anwendungsdaten, die während der wiederhergestellten Verbindung gesendet wurden, offengelegt werden.
Ein weiteres Problem stellen Replay-Angriffe dar. Über 0-RTT gesendete Anwendungsdaten können von einem Angreifer auf dem Übertragungsweg abgefangen und mehrfach an denselben Server zurückgesendet werden. In den meisten Fällen hilft die Verschlüsselung, diese Art von Bedrohung zu mindern, aber 0-RTT schwächt diese Schutzebene, indem es die vollständige Neuverhandlung umgeht.
Daher bietet 0-RTT zwar Leistungsvorteile, muss aber mit Vorsicht eingesetzt werden, insbesondere in Szenarien mit sensiblen Daten oder hohen Sicherheitsanforderungen.
Firewall-Inkompatibilität
Aus Sicht der Unternehmenssicherheit bringt QUIC zusätzliche Herausforderungen mit sich – insbesondere für Organisationen, die auf Deep Packet Inspection und Datenverkehrsentschlüsselung angewiesen sind.
Ein zentrales Problem ist, dass QUIC die SSL-Entschlüsselung nicht unterstützt. Dies ist eine gängige Methode, die von Unternehmensfirewalls zur Überprüfung und Sicherung des Netzwerkverkehrs verwendet wird. Stattdessen verwendet QUIC eine eigene, proprietäre Verschlüsselung. Da es in der gesamten Anwendungspalette von Google weit verbreitet ist, entsteht dadurch ein erheblicher blinder Fleck in Bezug auf Netzwerktransparenz und -kontrolle für IT-Teams.
Eine weitere Herausforderung liegt in der Designphilosophie von QUIC.
Google hat QUIC so konzipiert, dass es flexibel und leicht aktualisierbar ist, im Gegensatz zur starren und veralteten TCP-Infrastruktur. Dieser Ansatz fördert zwar schnelle Innovationen, erfordert aber auch, dass sich Firewall- und Sicherheitstools schnell an Änderungen auf Protokollebene anpassen . Dieser ständige Aktualisierungsbedarf kann die IT-Teams und die Infrastruktur stark belasten.
Aus diesem Grund empfehlen einige Firewall-Anbieter, QUIC vollständig zu blockieren, bis ausgereiftere und kompatiblere Sicherheitslösungen verfügbar sind. Von sich ständig weiterentwickelnder Dokumentation bis hin zu uneinheitlicher Implementierung häufen sich die Sicherheitsherausforderungen von QUIC immer weiter an, insbesondere in Unternehmensumgebungen.
Erzwingen Sie Hochgeschwindigkeitsnetzwerksicherheit mit Check Point
Check Point Quantum ist eine branchenführende Firewall, die jetzt QUIC unterstützt. Quantum Netzwerk Security bietet jedoch weit mehr als nur Einblick in Google Anwendungen: Es bietet Check Pointumfassendes Bedrohungsbewusstsein zusammen mit dem Schutz vor SandBlast Zero-Day-Angriffen. Um ein Verständnis dieser hochaktuellen Bedrohungen zu erlangen, werfen Sie einen Blick in unseren Risikobericht 2025.
On-Demand-Hyperscale-Infrastruktur hält die Latenz niedrig und bietet nahtlose Skalierbarkeit, wenn sich die Bedürfnisse einer Organisation weiterentwickeln. Für ein besseres und transparenteres Management bietet Quantum ein einheitliches Managementsystem, das die Transparenz in Netzwerk-, Cloud- und IoT-Umgebungen integriert.
Erleben Sie den vollen Funktionsumfang von Check Point Quantum und starten Sie noch heute Ihre kostenlose Demo.
