Entwickler möchten Anwendungen und Infrastrukturen in der Regel mit veröffentlichten, offiziellen und unterstützten Bibliotheken erstellen. Auch bei HTTP/3 besteht ein großer Bedarf an einer benutzerfreundlichen Bibliothek, die QUIC unterstützt, ohne die Wartungskosten oder die betriebliche Komplexität der Produktionsinfrastruktur zu erhöhen.
Für viele Nutzer von QUIC+HTTP/3 ist diese standardmäßige Kryptografiebibliothek OpenSSL. OpenSSL ist auf den meisten Linux-basierten Betriebssystemen standardmäßig installiert, die führende Bibliothek für Transport Layer Security (TLS) und wird von der Mehrheit der Netzwerkanwendungen verwendet.
Das Problem: Inkompatibilität zwischen OpenSSL und QUIC+HTTP/3
Trotz seiner weiten Verbreitung stellt OpenSSL nicht die für die QUIC-Unterstützung erforderliche TLS-API bereit. Stattdessen hat das OpenSSL Management Committee beschlossen, selbst einen vollständigen QUIC-Stack zu implementieren. Dieses Vorhaben ist mit erheblichem Aufwand verbunden und für OpenSSL v3.4 geplant. Laut der OpenSSL-Roadmap wird dies jedoch voraussichtlich nicht vor Ende 2024 geschehen. Darüber hinaus wird das erste Minimum Viable Product der OpenSSL-Implementierung keine QUIC-API enthalten, sodass es für Benutzer keinen klaren Weg gibt, HTTP/3-Unterstützung mit OpenSSL zu erhalten.
Optionen für QUIC-TLS-Unterstützung
In dieser Situation haben Benutzer, die QUIC-TLS-Unterstützung für ihre HTTP/3-Anforderungen benötigen, zwei Möglichkeiten:
- OpenSSL-QUIC-Implementierung – Wie oben erwähnt, arbeitet OpenSSL derzeit an der Implementierung eines eigenen vollständigen QUIC-Stacks. Dadurch wird die gesamte QUIC-Funktionalität in der Implementierung gekapselt, sodass HTTP/3-Nutzer die OpenSSL-TLS-API wesentlich einfacher verwenden können, ohne sich um QUIC-spezifische Funktionen kümmern zu müssen.
- Bibliotheken mit Unterstützung für die BoringSSL-QUIC-API – Verschiedene SSL-Bibliotheken wie BoringSSL, quicTLS und LibreSSL (die alle ursprünglich Abspaltungen von OpenSSL waren) bieten inzwischen QUIC-TLS-Funktionalität, indem sie die BoringSSL-QUIC-API implementieren. Allerdings sind diese Bibliotheken nicht so weit verbreitet wie OpenSSL. Bei dieser Option muss die SSL-Bibliothek außerdem aus dem Quellcode kompiliert und auf jedem Server installiert werden, der QUIC+HTTP/3 unterstützen soll, was möglicherweise nicht für alle praktikabel ist. Dennoch ist dies derzeit die einzige Option für Benutzer, die HTTP/3 verwenden möchten, da die QUIC-TLS-Implementierung von OpenSSL noch nicht einsatzbereit ist.
Eine neue Lösung: die OpenSSL-Kompatibilitätsschicht
Bei NGINX haben uns diese Herausforderungen dazu inspiriert, die OpenSSL-Kompatibilitätsschicht zu entwickeln. Sie vereinfacht QUIC+HTTP/3-Bereitstellungen mit OpenSSL und hilft, den Aufwand zu vermeiden, der mit der Pflege einer separaten SSL-Bibliothek in Produktionsumgebungen verbunden ist.
Verfügbar mit NGINX Open Source Mainline ab Version 1.25.0 und NGINX Plus R30: Die OpenSSL-Kompatibilitätsschicht ermöglicht es NGINX, QUIC+HTTP/3 auf OpenSSL auszuführen, ohne OpenSSL patchen oder neu erstellen zu müssen. Dadurch entfällt die Notwendigkeit, TLS-Bibliotheken von Drittanbietern zu kompilieren und bereitzustellen, um QUIC-Unterstützung zu erhalten. Da Benutzer keine Bibliotheken von Drittanbietern verwenden müssen, verringert sich auch die Abhängigkeit von deren Zeitplänen und Roadmaps. Somit lässt sich diese Lösung vergleichsweise einfacher in Produktionsumgebungen bereitstellen.
Funktionsweise der OpenSSL-Kompatibilitätsschicht
Die OpenSSL-Kompatibilitätsschicht führt die folgenden Schritte aus:
- Konvertiert einen QUIC-Handshake in einen von OpenSSL unterstützten TLS-1.3-Handshake.
- Leitet die TLS-Handshake-Nachrichten an OpenSSL weiter und empfängt sie von OpenSSL.
- Ruft die Verschlüsselungsschlüssel für die Verschlüsselungsebenen des Handshakes und der Anwendung aus OpenSSL ab.
- Übergibt die QUIC-Transportparameter an OpenSSL und liest sie daraus aus.
Angesichts der heutigen Verbreitung von OpenSSL und seines aktuellen Stands bei der offiziellen Unterstützung von QUIC+HTTP/3 sind wir überzeugt, dass eine einfache und skalierbare Möglichkeit zur Aktivierung von QUIC ein Schritt in die richtige Richtung ist. Dies wird auch die Verbreitung von HTTP/3 fördern und wertvolles Feedback ermöglichen. Vor allem vertrauen wir darauf, dass uns die OpenSSL-Kompatibilitätsschicht dabei helfen wird, unseren Unternehmenskunden und der gesamten NGINX-Community eine robustere und skalierbarere Lösung bereitzustellen.
Hinweis: Mit der OpenSSL-Kompatibilitätsschicht stellen wir NGINX-Benutzern zwar eine einfache und skalierbare Option zur Verfügung, sie können mit NGINX jedoch weiterhin Drittanbieterbibliotheken wie BoringSSL, quicTLS oder LibreSSL verwenden. Um zu entscheiden, welcher Weg für Sie der richtige ist, sollten Sie überlegen, welcher Ansatz Ihre Anforderungen am besten erfüllt und wie vertraut Sie mit dem Kompilieren und Verwalten von Bibliotheken als Abhängigkeiten sind.
Ein Hinweis zu 0-RTT
0-RTT ist eine Funktion von QUIC, die es einem Client ermöglicht, Anwendungsdaten zu senden, bevor der TLS-Handshake abgeschlossen ist. Die 0-RTT-Funktionalität wird durch die Wiederverwendung ausgehandelter Parameter aus einer früheren Verbindung ermöglicht. Dazu speichert der Client wichtige Parameter und stellt dem Server ein TLS-Sitzungsticket bereit, mit dem dieser dieselben Informationen wiederherstellen kann.
Obwohl diese Funktion ein wichtiger Bestandteil von QUIC ist, wird sie in der OpenSSL-Kompatibilitätsschicht noch nicht unterstützt. Wenn Sie konkrete Anwendungsfälle haben, die 0-RTT erfordern, freuen wir uns über Ihr Feedback, das uns bei der Planung unserer Roadmap hilft.
Weitere Informationen zu NGINX mit QUIC+HTTP/3 und OpenSSL
Sie können die OpenSSL-Kompatibilitätsschicht von NGINX ab heute mit NGINX Open Source nutzen oder eine 30-tägige kostenlose Testversion von NGINX Plus starten. Wir hoffen, dass sie Ihnen nützlich ist, und freuen uns über Ihr Feedback.
Weitere Informationen zu NGINX mit QUIC+HTTP/3 und OpenSSL finden Sie in den folgenden Ressourcen.
- Eine Einführung in QUIC-Netzwerke und -Verschlüsselung in NGINX
- Binärpakete jetzt für die Vorschauimplementierung von NGINX QUIC+HTTP/3 verfügbar
- Unsere Roadmap für die Unterstützung von QUIC und HTTP/3 in NGINX
- Unterstützung von Open Source für eine sicherere Welt: F5 NGINX kündigt Sponsoring von Let’s Encrypt und OpenSSL an
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.