Internet-Protokoll: Quic soll der neue Kick für sicheres Surfen werden
Es ist ein fürchterlich abgedroschener Spruch, und der Konzern Google will ihm immer wieder gerecht werden: "Time is money" . Darum hat Google Quic(öffnet im neuen Fenster) erfunden. Das Akronym steht für Quick UDP Internet Connections. Das neue Protokoll soll insbesondere bei verschlüsselten Web-Verbindungen für deutlich kürze Reaktionszeiten und schneller ladende Webseiten sorgen. "Da ist Google ganz offen. Das ist einfach bares Geld für die" , erklärt Netzwerkexperte Lars Eggert die Motivation des Internetkonzerns.
Eggert hat die sogenannten Bird-of-Feather-Diskussionen (BOF) zu Quic bei der Internet Engineering Task Force (IETF) geleitet. Er meint, ein besseres Web sorge für mehr Werbeeinblendungen und für mehr Klicks. Das bedeute mehr Geld für Google. Dennoch würden alle im Web von der Beschleunigung profitieren. Auch deshalb hat das Plenum während des letzten IETF-Meetings im Juni 2016 in Berlin entschieden, Quic durch die Task Force zu standardisieren.
Verschlüsselung boomt
Konkret handelt es sich bei Quic um ein schnelles Transportprotokoll, das standardmäßig die Verschlüsselung des gesamten Datenverkehrs vorsieht. Bislang sichern Anwendungen vertrauliche Daten zwischen Servern und Surfern ab, indem ein zusätzliches Verschlüsselungsprotokoll eingesetzt wird. Dieses verschlüsselt die übertragenen Daten vor dem Transport und entschlüsselt sie nach dem Empfang wieder. Das ist beispielsweise dann der Fall, wenn Bankgeschäfte online erledigt oder Kundendaten bei einem Online-Shop erfasst werden.
Der HTTPS-Standard sieht vor, dass zusätzlich zwischen dem reinen Datentransport über das Transport Control Protocol (TCP) und der Web-Anwendung nach dem Hypertext Transfer Protocol eine Verschlüsselung nach dem Transport-Layer-Security-Verfahren TLS aktiviert wird. Seit den Enthüllungen von Edward Snowden bieten aber immer mehr Webanbieter ihre Seiten nur noch per HTTPS an. Dadurch hoffen sie, die Privatsphäre ihrer Webseiten-Besucher besser schützen zu können.
Dabei hat die Methode, die Verschlüsselung wie bei HTTPS erst mit der Anwendung einzusetzen und nicht bereits auf der Verbindungsebene, gravierende Nachteile. So benötigt TCP oft mehrere Hundert Millisekunden, um bei einem Handshake überhaupt eine Verbindung herzustellen. Die Zeit für den aufwendigen Zertifikats- und Schlüsselaustausch, mit dem die Verschlüsselung initialisiert wird, kommt dazu. Darüber hinaus kümmert sich TCP darum, dass die Daten vollständig und in der richtigen Reihenfolge beim Empfänger ankommen.
Das kann bei Datenverlust oder Fehlübertragung zu längeren Wartezeiten führen, bis fehlende Pakete erneut übertragen wurden und der restliche Datentransport fortgesetzt werden kann. Da in der Regel bei den meisten Web-Anwendungen mehrere TCP-Verbindungen nötig sind, um etwa Daten aus verschiedenen Quellen anzeigen zu können, addieren sich die Verzögerungszeiten im schlimmsten Fall. Quic hingegen bietet neue Übertragungsmechanismen an, die diese Schwächen weitestgehend vermeiden.
Alles in einem Aufwasch
"Die Idee von Quic ist es, den Transport von Daten und gleichzeitig die Verschlüsselung von Daten in einem einzigen Protokoll zu organisieren" , erklärt Jari Arkko, Vorsitzender der IETF den Ansatz. So benutzt Quic statt des gesicherten Transportprotokolls TCP das ungesicherte und einfache User-Datagram-Protokoll (UDP). Das erlaubt es, einfache Datenpakete, die Datagramme, von A nach B zu schicken, ohne vorher eine Verbindung aufgebaut zu haben.
Quic kann sich durch geschickten Austausch von Datagrammen selbst um die Verbindungskontrolle kümmern. Bei dem initialen Handshake werden bei Quic gleichzeitig die Zertifikate und Schlüssel für die Absicherung der nachfolgenden Datagramme, die zwischen Sender und Empfänger gesendet werden, ausgetauscht.
Verbindungsaufbau und Kryptoinitialisierung können im besten Fall in nur einer Runde Kommunikations-Ping-Pong zwischen Server und Client erledigt werden. Danach werden alle Datagramme nahezu vollständig verschlüsselt. Die IETF sieht für Quic vor, die Datagramme mit dem neuen Sicherheitsprotokoll TLS 1.3 zu verschlüsseln, das seit Anfang des Jahres in der IETF-Standardisierung steckt.
Schlüssel halten länger
Zusätzlich merkt sich Quic die zwischen zwei Rechnern ausgehandelten Schlüssel für eine gewisse Zeit. "Wenn sich zum Beispiel Ihr Mobiltelefon und ein Google-Server das erste Mal miteinander unterhalten, dann findet ein etwas längerer Handshake statt, bei dem ja unter anderem die Krypto-Schlüssel ausgetauscht werden" , beschreibt Eggert das weitere Detail. " Wenn Sie dann aber zwei Minuten später wieder mit dem Server kommunizieren, dann erinnert der sich an Sie, und man kann einen Teil des Handshakes umgehen und gewinnt damit Latenzzeiten."
Nur wenige Header-Daten bleiben dabei unverschlüsselt, werden dann aber zumindest authentifiziert, so dass sie nicht unbemerkt verändert werden können. Um auf mehrere gleichzeitige Quic-Verbindungen zwischen einem Server und einem Client verzichten zu können, sieht das neue Protokoll Multiplexing vor. Dies sind virtuelle Verbindungen, die beliebig zwischen dem Server und dem Client eingerichtet werden können. Die IETF-Version von Quic soll vorsehen, dass in einem Datagramm Nutzdaten sowohl ausschließlich für einen einzigen Kanal des Multiplexes als auch für mehrere Kanäle enthalten sein können. Dies wird über die Headerdaten gesteuert.
Ebenso kann flexibel festgelegt werden, welches Maß an Datenintegrität ein einzelner Kanal bietet. Dazu soll Quic je nach Anforderung vorauseilend Datagramme mit Fehlerkorrektur-Informationen schicken, mit deren Hilfe falsch oder gar nicht übertragene Daten rekonstruiert werden können, ohne dass eine Neuübertragung nötig wird. Reichen diese vorsorglich übertragenen Fehlerkorrektur-Daten nicht aus, dann wirkt sich die Verzögerung durch den zusätzlichen Roundtrip nur auf einen einzelnen Kanal des Multiplexes aus und nicht auf den gesamten Stream.
Bei unkritischen Daten, etwa innerhalb von Videostreams, kann sogar auf den Roundtrip verzichtet werden, weil der Fehler in diesem Kanal toleriert wird, während in einem anderen Kanal eine vollständig gesicherte Übertragung stattfindet. Auch dies kann flexibel pro Kanal vom Sender festgelegt werden.
Breite Feldversuche laufen bereits
Dass Quic funktioniert und sich der Geschwindigkeitsgewinn auch tatsächlich wie erhofft einstellt, konnte Google schnell beweisen. Schon 2013 implementierte der Internetkonzern den neuen Protokollstack auf seinen Servern. Zusätzlich wurde Quic auch in Canary und in die folgenden Versionen des Google-Web-Browsers Chrome eingebaut. Nahezu unbemerkt von den Anwendern wurde Quic in der Praxis getestet. Auch Netflix und Microsoft sollen angeblich mit Quic experimentieren, allerdings nicht auf produktiven Systemen. Google allerdings beließ es nicht nur bei Tests.
Heute schon wird der Großteil von Verbindungen zwischen Google-Servern und Chrome-Browsern per Quic abgewickelt. Vor allem bei Youtube komme Quic zum Einsatz, wenn mit einem Chrome-Browser darauf zugegriffen werde, sagt Eggert. Schätzungen zufolge liege dadurch der Quic-Anteil am Gesamtaufkommen des Internetverkehrs bereits bei 9 Prozent. Anders als etwa die Umstellung des Internet-Protokolls von Ipv4 auf Ipv6, vollzieht sich der Umstieg auf Quic vergleichsweise rasend schnell.
Das liegt vor allem daran, dass Quic, anders als TCP, nicht auf Betriebssystemebene verankert ist, sondern in jeder einzelnen Applikation selbst, etwa in einem Webbrowser. Deshalb konnte Google die Einführung des neuen Protokolls durchziehen, ohne auf andere Softwarehersteller wie etwa Microsoft oder die Linux-Kernel-Community Rücksicht nehmen zu müssen.
Aus für Deep-Packet-Inspection
Die Standardisierung von Quic durch die IETF ist allerdings bei den Beteiligten teilweiser umstritten. Zum einen, weil die Task Force zwischenzeitlich in mühevoller Abstimmungsarbeit den neuen Standard HTTP/2 fertiggestellt hat. Er basiert im wesentlichen auf dem ebenfalls von Google vorgeschlagenen SPDY-Protokoll. Zwar bietet HTTP/2 wie Quic die Möglichkeit, per Multiplexing mehrere Anfragen zusammenzufassen, doch setzt auch die zweite Version des World-Wide-Web-Protokolls auf TCP, weshalb sich Latenzen bei der Fehlerkorrektur auf alle Streams gemeinsam auswirken, auch wenn Google versucht, das mit dem Rack-Algorithmus einzuschränken.
Vielmehr stören sich etliche Netzwerkbetreiber an Quic wegen seiner sehr tiefgreifenden Verschlüsselung der Datenpakete und der Authentifizierung der Headerdaten. In ihnen befinden sich jede Menge Meta-Informationen, die den Weg der Datagramme durch das Netz steuern. Sowohl durchgehende Ende-zu-Ende-Verschlüsselung als auch die Authentifizierung hat Google bislang in Quic standardmäßig vorgesehen, auch die IETF wird wohl daran festhalten. Dies sei im Interesse der Datensicherheit und des Datenschutzes nötig.
Quic-Dilemma für Betreiber
Dadurch aber können die Header während des Transportes durch das Netz nicht mehr verändert werden. Authentifizierte Header, die verändert wurden, lehnen die Empfänger nämlich ab. "Und das bringt einen Konfliktpunkt hervor, weil die Betreiber bislang Verkehrsmanagement gerne so gemacht haben, dass sie auf die Headerdaten zugegriffen haben" , beschreibt der Netzwerkspezialist Eggert das Dilemma.
Aus den Headerdaten wurden bislang Informationen zur Netzsteuerung gewonnen, teilweise wurden sie auch zur Optimierung des Verkehrsflusses verändert. Das ist mit Quic gar nicht mehr möglich. Nicht nur weil die Authentifizierung das verbietet, sondern auch, weil ein Großteil der Headerdaten genauso wie die Nutzdaten selbst verschlüsselt ist.
Auch zusätzliche Datenkomprimierung oder Deep-Packet-Inspection, also die Untersuchung der Datenpakete etwa zur Feststellung des Medientyps, sind mit Quic nicht mehr umsetzbar. Besonders Mobilfunkbetreiber, die ihre ständig knappen Netzwerkressourcen durch geschicktes Management zu steuern versuchen, tun sich mit einer Standardisierung durch die IETF schwer. Heftige Diskussionen werden für die kommenden Quic-Sessions erwartet, bevor irgendwann der traditionelle Konsens für das Protokoll gefunden werden kann und ein RFC daraus wird, also ein Internet-Standard.
Schon die letzte Quic-Session auf dem 96. IETF-Meeting in Berlin war komplett überfüllt, was das große Interesse der Netz-Community an dieser Diskussion zeigt. Eggert ist zuversichtlich, dass sich die Netzwerkbetreiber mit dieser Situation abfinden und neue Möglichkeiten der Netzwerkoptimierung auftun werden. "Es gibt ja zudem noch immer die Möglichkeit, dass man mehr in Kapazität investiert statt in Equipment, um Kapazitätsengpässe zu managen."
Manfred Kloiber arbeitet als freier Wissenschaftsjournalist in Köln. Sein Einstieg in die IT-Welt begann in der 1980er-Jahren als Film-Autor und Realisator beim legendären WDR-Computerclub. Nachdem die Sendung im WDR-Programm auslief, produzierte er über Jahre hinweg zusammen mit Wolfgang Back und Wolfgang Rudolph den Computerclub2. Seit über 20 Jahren ist er Redakteur am Mikrofon der wöchentlichen Deutschlandfunk-Sendung Computer und Kommunikation. Darüber hinaus berichtet er regelmäßig für Deutschlandradio und die ARD über IT-Themen.
- Anzeige Hier geht es zu Hacking & Security: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.