Login
Newsletter
Werbung

Di, 22. Januar 2019, 14:22

Software::Netzwerk

Fehlende Funktionen in TLS-Bibliotheken könnten HTTP/3 aufhalten

Daniel Stenberg, Autor von Curl und Experte für HTTP/3, geht davon aus, dass die Einführung von HTTP/3 später erfolgen wird als gedacht. Ausgebremst wird es von freien TLS-Implementationen wie OpenSSL, die einige nötige Funktionen noch nicht implementiert haben.

Von HTTP/QUIC zu HTTP/3

Mike Bishop

Von HTTP/QUIC zu HTTP/3

HTTP/3, die kommende Revision des HTTP-Standards, ist im Wesentlichen identisch zu HTTP/2, nutzt aber QUIC statt TCP als Transport. War in HTTP/2 die TLS-Verschlüsselung noch optional, ist sie in HTTP/3 fester Bestandteil von QUIC und damit verbindlich. QUIC selbst baut auf UDP auf und stellt wie TCP einen zuverlässigen, verlustfreien Transport bereit, aber ohne die großen Latenzen, die TCP beim Verbindungsaufbau hat, und ohne die großen Verzögerungen, die HTTP/2 und früher bei schlechten Verbindungen mit Paketverlusten plagen. UDP zu verwenden, statt ein neues Protokoll zu entwickeln, hatte sehr handfeste Gründe. Zum einen können Millionen von Geräten und Routern im Internet nur TCP und UDP gut verarbeiten oder lassen nichts anderes passieren. Zum anderen ermöglicht es UDP, dass man darauf aufbauende Protokolle außerhalb des Kernels, in der Anwendersoftware, implementiert.

Erst letzten November hatte die Arbeitsgruppe der IETF, die sich mit der Standardisierung von HTTP über QUIC beschäftigt, den Namen HTTP/3 geprägt. Die Internet Engineering Task Force (IETF) ist die Organisation, die sich mit der Standardisierung aller wichtigen Protokolle im Internet beschäftigt. Innerhalb der IETF gibt es zahlreiche Arbeitsgruppen, darunter auch solche zu QUIC und HTTP über QUIC. Letzteres wird jetzt als HTTP/3 und damit als Nachfolger von HTTP/2 geführt. Die Arbeiten an der Standardisierung von HTTP/3 und QUIC sind aber noch nicht abgeschlossen.

Der Entwickler Daniel Stenberg, bekannt vor allem durch die Entwicklung von Curl, weist nun darauf hin, dass die Verwendung von TLS durch QUIC neue Schnittstellen in den TLS-Bibliotheken erfordert, da die Anforderungen andere sind als bei TLS über TCP. Einige der wichtigsten freien TLS-Bibliotheken, darunter OpenSSL, LibreSSL, GnuTLS, schannel und Secure Transport, haben diese Schnittstellen aber noch nicht implementiert. Dagegen waren die Entwickler von BoringSSL, NSS, quicly, PicoTLS und Minq flink und haben die erforderlichen Arbeiten bereits abgeschlossen. Ein Grund dafür ist, dass diese Entwickler auch aktiv an der Spezifikation von QUIC beteiligt waren. Doch leider handelt es sich dabei durchgehend um Bibliotheken, die entweder generell nicht weit verbreitet sind oder nur in wenigen Anwendungen genutzt werden.

Für OpenSSL beispielsweise existieren bereits Patches, die im Rahmen der QUIC-Implementation ngtcp2 entwickelt wurden, und dem OpenSSL-Team ist das Problem bereits seit September 2017 bekannt. Dennoch gibt es noch keine veröffentlichte Version von OpenSSL, die die Änderungen enthält. Stenberg ist sich daher sicher, dass HTTP/3 daher nicht so schnell eingesetzt werden kann wie erhofft. Denn damit die HTTP/3-Unterstützung aktiviert werden kann, muss erst in der verwendeten TLS-Bibliothek die Funktionalität zur Verfügung stehen.

Die Situation ist ähnlich zu der bei der Einführung von HTTP/2. Damals wurde auch eine neue TLS-Erweiterung namens ALPN benötigt. Diese war in OpenSSL 1.0.2 bereits implementiert, doch viele Benutzer hatten noch mehr oder weniger lang eine ältere Version von OpenSSL im Einsatz. Dieses Mal ist der Code aber noch nicht einmal in einer Betaversion von OpenSSL vorhanden. Noch ist aber fast ein halbes Jahr Zeit, die Situation zu ändern. So besteht immer noch Hoffnung, dass mit dem Startschuss von HTTP/3 auch die nötige Funktionalität in den Bibliotheken implementiert ist und die Akzeptanz von HTTP/3 keinen wesentlich anderen Verlauf nimmt als bei HTTP/2.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung