Ankündigung von NGINX Plus R26

Robert HaynesManager für technisches Marketing

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 26 (R26) bekannt zu geben. Basierend auf NGINX Open Source ist NGINX Plus die einzige All-in-One-Softwarelösung, die Webserver, Load Balancer, Reverse Proxy, Content-Cache und API-Gateway vereint.

Zu den neuen und verbesserten Funktionen in NGINX Plus R26 gehören:

• Schnellere JWT-Validierung durch Zwischenspeicherung von JSON Web Key Sets – Als Fortsetzung der in den letzten Versionen eingeführten Verbesserungen bei der Unterstützung von JSON Web Tokens (JWT) führen wir die Zwischenspeicherung von JSON Web Key Sets (JWKS) im Arbeitsspeicher ein, wodurch der Aufwand für die JWT-Validierung erheblich reduziert wird.
• Gehärtete TLS-Handshakes – NGINX Plus lehnt den TLS-Handshake ab, wenn der Client über ALPN ein Kommunikationsprotokoll vorschlägt, das nicht zum NGINX-Konfigurationskontext der aufzubauenden Sitzung passt (wenn er beispielsweise einem virtuellen Server im http{}-Kontext das IMAP-E-Mail-Protokoll vorschlägt).
• Verbesserungen am NGINX-JavaScript-Modul – Asynchrone Funktionen, die die Schlüsselwörter async und await sowie das Promise-Objekt verwenden, werden jetzt unterstützt. Außerdem haben wir die WebCrypto API für kryptografische Operationen implementiert (z. B. zum Generieren von Zufallszahlen oder Verschlüsseln von Cookies).

Abgerundet wird diese Version durch die Unterstützung der IBM-System-Z-Architektur (s390x), die Möglichkeit, jede Richtung einer TCP-Verbindung unabhängig voneinander zu schließen, sowie die Unterstützung von Version 2 der Bibliothek für Perl-kompatible reguläre Ausdrücke (PCRE).

Wichtige Verhaltensänderungen

Das NGINX-JavaScript-Modul unterstützt js_include nicht mehr

Wie bei der Veröffentlichung von NGINX Plus R23 angekündigt, wurde in Version 0.4.0 des NGINX JavaScript-Moduls die Direktive js_import anstelle der Direktive js_include eingeführt. Die Direktive js_include wurde damals als veraltet eingestuft und wird ab dieser Version nicht mehr unterstützt.

Ersetzen Sie vor dem Upgrade auf NGINX Plus R26 js_include durch js_import in den NGINX-Konfigurationsdateien und fügen Sie außerdem eine export-Anweisung zu den JavaScript-Dateien für Funktionen hinzu, auf die in der NGINX-Konfiguration verwiesen wird. Führen Sie die folgenden Schritte aus:

1. Bearbeiten Sie die NGINX-Konfigurationsdateien. Ändern Sie beispielsweise:

js_set $foo myFunction;

1. zu:

js_set $foo module_name.myFunction;

• Ersetzen Sie js_include durch js_import und notieren Sie sich den impliziten module_name (den Parameter für den JavaScript-Dateinamen der Direktive, ohne die Dateiendung .js).
• Stellen Sie in jeder Direktive, die auf eine JavaScript-Funktion verweist, dem Funktionsnamen den module_name voran. Der Funktionsname ist der erste Parameter dieser Direktiven. Bei der Direktive js_set[HTTP][Stream] ist er der zweite Parameter.
  • js_body_filter
  • js_content
  • js_filter
  • js_header_filter

1. Bearbeiten Sie die JavaScript-Dateien (module_name.js) mit den Funktionen, auf die in einer NGINX-Konfigurationsdatei verwiesen wird. Fügen Sie jeder Datei eine export-Anweisung wie die folgende hinzu und geben Sie darin die referenzierten Funktionen an.

export default { myFunction, otherFunction }

1. Die export-Anweisung kann an einer beliebigen Stelle in der .js-Datei stehen, wird üblicherweise jedoch entweder direkt über den Funktionen oder am Ende der Datei platziert.

Das Cookie-Flag-Modul ist veraltet

Das Drittanbieter-Modul Cookie-Flag wurde in NGINX Plus R23 als veraltet eingestuft und ist, wie damals angekündigt wurde, ab diesem Release nicht mehr im NGINX-Modul-Repository verfügbar.

Bearbeiten Sie vor dem Upgrade auf NGINX Plus R26 Ihre NGINX-Konfiguration, um alle Vorkommen der Direktive „set_cookie_flag“ (die im veralteten Modul definiert ist) durch die integrierte Direktive „proxy_cookie_flags“ zu ersetzen.

Die TLS-Aushandlung unterstützt das NPN-Protokoll nicht mehr

Die Art und Weise, wie NGINX TLS- und HTTP/2-Verbindungen herstellt, wurde aktualisiert. Im Rahmen des TLS-Handshakes zwischen NGINX und einem Client (in der Regel einem Browser) handeln beide aus, welches Kommunikationsprotokoll in der durch den Handshake hergestellten Sitzung verwendet wird (meist wird die Sitzung dabei von HTTP 1.x auf HTTP/2 aktualisiert). Die TLS-Erweiterung Next Protocol Negotiation (NPN) war die erste zu diesem Zweck verwendete Methode. NPN gilt inzwischen jedoch als veraltet und wurde durch die Erweiterung Application-Layer Protocol Negotiation (ALPN) abgelöst, die als RFC 7301 veröffentlicht wurde.

NGINX Plus R26 unterstützt NPN nicht mehr, daher müssen Clients jetzt ausschließlich ALPN verwenden.

Darüber hinaus wurde unsere ALPN-Implementierung erweitert und gehärtet – siehe „Gehärtete TLS-Handshakes“.

Das alte NGINX Plus-Software-Repository wird nicht mehr aktualisiert

Mit der Veröffentlichung von NGINX Plus R24 wurden die Paket-Repositorys für die gesamte NGINX-Software neu organisiert, wodurch sich das Installationsverfahren für NGINX Plus änderte.

Wenn Sie NGINX Plus installieren oder aktualisieren, wird der Paketmanager des Betriebssystems (apt, yum oder ein vergleichbares Tool) für die Verwendung des Software-Repositorys von NGINX Plus konfiguriert.

Wenn Sie ein vorhandenes System, das für die Verwendung des alten Repositorys plus-pkgs.nginx.com konfiguriert ist (Systeme mit NGINX Plus R23 oder älter), auf NGINX Plus R26 aktualisieren, müssen Sie den Paketmanager so aktualisieren, dass er auf das neue Repository pkgs.nginx.com/plus verweist. Beachten Sie die Anweisungen in der F5 Knowledge Base.

Wenn Sie NGINX Plus R26 erstmalig installieren, lesen Sie NGINX Plus installieren im NGINX Plus-Administratorhandbuch.

NGINX Plus R26 ist im alten Repository nicht verfügbar, das keine weiteren Updates erhalten wird.

Geänderter Zugriff auf die OpenAPI-Spezifikation für die NGINX Plus API

Das Softwarepaket NGINX Plus enthält nicht mehr die im YAML-Format vorliegende OpenAPI-Spezifikation und die Swagger-Benutzeroberfläche für die NGINX Plus API. Sie können nun im NGINX Plus-Administratorhandbuch darauf zugreifen.

Änderungen bei der Plattformunterstützung

Neu unterstützte Betriebssysteme und Architekturen:

• Alpine Linux 3.15 (x86_64, arm64)
• Die IBM Z-Plattform (s390x) mit CentOS 8.1+, RHEL 8.1+ und Ubuntu 20.04; siehe Unterstützung für die IBM Z-s390x-Architektur

Ältere Betriebssysteme wurden entfernt:

• Alpine Linux 3.11 (älteste unterstützte Version ist 3.12)

Ältere Betriebssysteme und Architekturen, die als veraltet eingestuft wurden und deren Unterstützung mit NGINX Plus R27 eingestellt werden soll:

• Power8-Architektur (ppc64le)
• CentOS 8.1+
• Alpine Linux 3.12

Neue Funktionen im Detail

Schnellere JWT-Validierung durch Caching von JSON Web Key Sets

Bei der Validierung von JSON Web Tokens verwendet NGINX ein JSON Web Key Set (JWKS), um die Signatur des Tokens zu überprüfen oder das Token zu entschlüsseln. JWKS können entweder in Konfigurationsdateien gespeichert oder über eine HTTP-Anfrage von externen Diensten abgerufen werden. Darüber hinaus bietet das Zwischenspeichern eines JWKS im Arbeitsspeicher mehrere Vorteile:

• Deutliche Reduzierung der CPU-Auslastung
• Reduzierte Anfragelatenz
• Optimierung der JWT-Validierung, da JWKS-Schlüssel im Rahmen des Caching-Prozesses aus JSON in ein für kryptografische Operationen optimiertes Binärformat konvertiert werden

Um JWKSs im Arbeitsspeicher zwischenzuspeichern, fügen Sie die neue Direktive auth_jwt_key_cache hinzu und geben Sie die Ablaufzeit für jeden Schlüsselsatz an (in diesem Beispiel 3 Stunden):

Codebeispiel wird geladen…

Wenn JWKs von einem externen Server abgerufen werden, empfehlen wir außerdem, das standardmäßige Content-Caching zu konfigurieren und die Direktive proxy_cache_use_stale einzubinden. Diese weist NGINX Plus an, weiterhin einen abgelaufenen JWKS bereitzustellen, während dieser im Hintergrund aktualisiert wird.

Codebeispiel wird geladen…

Die Vorteile des Content-Cachings zusätzlich zum JWKS-Caching sind zweifach:

• Ausfallsicherheit – Der JWKS kann auch nach Ablauf seiner Gültigkeit aus dem Cache abgerufen werden. Dies erhöht die Ausfallsicherheit, wenn der JWKS-Anbieter vorübergehend nicht verfügbar ist, geht jedoch mit einem erhöhten Sicherheitsrisiko einher.
• Auswirkungen auf den Autorisierungsserver – Der Ablauf eines zwischengespeicherten JWKS wirkt sich unterschiedlich auf den Autorisierungsserver aus, je nachdem, ob die JWKS-Zwischenspeicherung allein oder in Kombination mit der Inhaltszwischenspeicherung verwendet wird:
  • Wenn ausschließlich JWKS-Caching verwendet wird, werden alle eingehenden Autorisierungsanfragen an den Autorisierungsserver weitergeleitet, bis der Cache mit einer neuen Version des abgelaufenen JWKS neu befüllt wurde. Wenn der Autorisierungsserver langsam antwortet, kann die Anzahl wiederholter HTTP-Anfragen für das JWKS plötzlich stark ansteigen. Diese zusätzliche Last könnte den Autorisierungsdienst überlasten und das Problem dadurch verschärfen.
  • Wenn das Inhalts-Caching zusammen mit der Bereitstellung abgelaufener JWKS aktiviert ist, wird nur eine Anfrage für den JWKS an den Authentifizierungsserver weitergeleitet. Nachfolgende Anfragen werden in eine Warteschlange gestellt, bis NGINX sie nach dem Befüllen des Inhalts-Caches verarbeiten kann. Dadurch sinkt die Belastung (und somit der Ressourcenverbrauch) des Authentifizierungsdienstes.

Gehärtete TLS-Handshakes

Angriffe auf TLS, wie etwa ALPACA, nehmen zu. Im Rahmen unseres kontinuierlichen Engagements für einen proaktiven Schutz vor Exploits haben wir die Verarbeitung von TLS-Verbindungen durch NGINX gehärtet.

Application-Layer Protocol Negotiation (ALPN) ist eine optionale Erweiterung des TLS-Handshakes, mit der Client und Server während des TLS-Handshakes das Layer-7-Protokoll auswählen, das sie in der durch den Handshake eingerichteten verschlüsselten Sitzung verwenden. Der häufigste Anwendungsfall für ALPN ist das Aushandeln des Upgrades von HTTP/1.x auf HTTP/2 für die Sitzung zwischen einem Browser und einem Web- oder Anwendungsserver.

NGINX Plus lehnt jetzt einen TLS-Handshake ab, wenn der Client über ALPN ein Protokoll vorschlägt, das nicht zum NGINX-Konfigurationskontext der aufzubauenden Sitzung passt. Beispielsweise benötigt ein virtueller Server, der im http{}-Kontext definiert ist, eine ALPN-Protokoll-ID für HTTP, während ein virtueller Server im mail{}-Kontext eine Protokoll-ID für SMTP, POP oder IMAP benötigt.

NGINX Plus R26 führt die Variable „$ssl_alpn_protocol[HTTP][Stream]“ ein, um das ausgehandelte Protokoll zu erfassen. (Die Variable „$ssl_preread_alpn_protocols“, die im Kontext stream{} in NGINX Plus R15 eingeführt wurde, erfasst weiterhin die Liste aller Protokolle, die der Client während des Handshakes angekündigt hat.)

Dieses Snippet definiert das Protokollformat alpn, das $ssl_alpn_protocol verwendet, um das Protokoll in das Feld alpn= der Einträge im Zugriffsprotokoll aufzunehmen.

Codebeispiel wird geladen…

Die neue ssl_alpn-Direktive im stream{}-Kontext legt fest, welche Protokolle NGINX Plus akzeptiert. Lassen Sie die Direktive weg, damit NGINX Plus alle vom Client angebotenen Protokolle berücksichtigt.

Codebeispiel wird geladen…

Verbesserungen am NGINX-JavaScript-Modul

NGINX Plus R26 enthält Version 0.7.2 des NGINX-JavaScript-Moduls (njs) und umfasst zwei Verbesserungen:

• Erweiterte Unterstützung für asynchrone Funktionen mit den Schlüsselwörtern async und await sowie dem in ECMAScript 6 eingeführten Promise-Objekt
• Eine Implementierung der WebCrypto API

Hinweis: In diesem Abschnitt wird vorausgesetzt, dass Sie mit den JavaScript-Konstrukten für asynchrone und kryptografische Operationen vertraut sind. Eine vollständige Analyse der Codeausschnitte würde den Rahmen dieses Blogs sprengen.

[Redaktion – Die in diesem Abschnitt beschriebenen Anwendungsfälle sind nur einige der vielen Einsatzmöglichkeiten des NGINX-JavaScript-Moduls. Eine vollständige Liste finden Sie unter „Anwendungsfälle für das NGINX-JavaScript-Modul“.]

Erweiterte Unterstützung für asynchrone Funktionen

In vielen gängigen Skriptsprachen wie PHP werden Befehle und Funktionen synchron ausgeführt. Das heißt, nachdem ein Skript eine Funktion aufgerufen hat, pausiert es (unterbricht die Ausführung), bis die Funktion ein Ergebnis zurückgibt.

JavaScript kann auch asynchron ausgeführt werden: Wird eine Funktion asynchron aufgerufen, wird das Skript weiter ausgeführt, ohne auf das Ergebnis der Funktion zu warten.

Sehen Sie sich dieses Beispielskript an:

Codebeispiel wird geladen…

Es wird eine leere Antwort zurückgegeben, da die njs-Laufzeitumgebung nicht wartet, bis die festgelegten Zeitüberschreitungen abgelaufen sind (würde sie warten, wäre die Ausgabe b,a):

$ curl http://127.0.0.1/
$ 

Die korrekte Handhabung asynchroner Vorgänge ist natürlich entscheidend, um das gewünschte Ergebnis zu erzielen. JavaScript bietet hierfür verschiedene Möglichkeiten. In typischen NGINX-Anwendungsfällen ist es jedoch oft sinnvoll, eine asynchrone Funktion einfach so zu kapseln, dass der Ausführungsablauf synchron erfolgt. Hier kommen das Promise-Objekt sowie die Schlüsselwörter async und await ins Spiel.

ECMAScript 6 (die sechste Ausgabe der ECMA‑262-Sprachspezifikation für JavaScript) definiert das Promise-Objekt als Rückgabetyp für asynchrone Funktionen. Es befindet sich in einem von drei Zuständen:

• erfüllt – Der Vorgang wurde erfolgreich abgeschlossen
• abgelehnt – Der Vorgang ist fehlgeschlagen
• ausstehend – Der Ausgangszustand (weder erfüllt noch abgelehnt)

Wenn Sie eine JavaScript-Funktion mit dem Schlüsselwort async definieren, wird der Rückgabetyp der Funktion auf Promise festgelegt. Die Schlüsselwörter async und await sind wichtig, wenn Sie njs-Funktionen schreiben, die mit Promise-Objekten arbeiten.

Betrachten Sie dieses Beispiel:

Codebeispiel wird geladen…

Die Funktion „fs.readFile“ (Zeile 12) gibt ein Promise zurück. Sie ist in eine benutzerdefinierte async-Funktion eingebettet, die sicherstellt, dass fs.readFile() nur aufgerufen wird, wenn die Datei user.text heißt. Aufgrund des Schlüsselworts await wartet die umschließende Funktion anschließend auf das Promise und gibt die Daten zurück.

Wenn fs.readFile() in eine andere Funktion eingebettet wird, lassen sich Fehler leichter abfangen. Jede Ausnahme in der async-Funktion setzt den Status des Promise auf rejected. Alternativ kann Zeile 9 durch eine Anweisung ersetzt werden, die ein abgelehntes Promise zurückgibt:

Codebeispiel wird geladen…

Sie können auch direkt mit Promise-Objekten arbeiten. Im folgenden Beispiel geben die Promise.resolve-Funktionen jeweils ein Promise für p1 und p2 zurück. Die Promise.all-Funktion wartet, bis die Promises für p1 und p2 aufgelöst wurden, bevor sie ein Ergebnis zurückgibt.

Codebeispiel wird geladen…

Jetzt entspricht die Ausgabe unseres „curl“-Befehls unseren Erwartungen (beachten Sie, dass „b“ aufgrund des kürzeren Zeitlimits zuerst zurückgegeben wird):

$ curl http://127.0.0.1/b,a
$ 

Neue kryptografische Funktionen mit der WebCrypto API

NGINX JavaScript verfügt jetzt über erweiterte kryptografische Funktionen durch die WebCrypto API. Zu den gängigen kryptografischen Anwendungsfällen für njs gehören:

• Generieren sicherer Zufallszahlen für Sitzungs-IDs
• Verschlüsseln und Entschlüsseln von Nachrichten, Daten und Cookies
• Erstellen oder Validieren digitaler Signaturen mithilfe symmetrischer und asymmetrischer kryptografischer Algorithmen

Dieser njs-Code erzeugt eine Zufallszahl:

Codebeispiel wird geladen…

Und diese NGINX Plus-Konfiguration ruft den njs-Code auf:

Codebeispiel wird geladen…

Die Ausgabe der Funktion ist eine Zufallszahl, die etwa so aussieht:

$ curl 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386

Die Funktion getRandomValues in WebCrypto ist ein hervorragender Einstieg in die Arbeit mit sicheren Zufallszahlen und WebCrypto im Allgemeinen. Ihre Implementierung ist recht einfach, und die Funktion gibt die Ergebnisse direkt zurück, anstatt ein Promise zurückzugeben.

Einige der anderen, rechenintensiveren kryptografischen WebCrypto-Funktionen werden jedoch asynchron ausgeführt. So heißt es beispielsweise in der Dokumentation zu сrypto.subtle.digest() wie folgt:

Erzeugt einen Hashwert der angegebenen Daten. Erwartet als Argumente eine Kennung für den zu verwendenden Hashalgorithmus und die Daten, deren Hashwert berechnet werden soll. Gibt ein Promise zurück, das mit dem Hashwert erfüllt wird.

Ein direkter Aufruf von сrypto.subtle.digest() garantiert daher nicht, dass das Ergebnis im nächsten Schritt verfügbar ist, es sei denn, der Aufruf wird in eine async-Funktion eingebettet. Deshalb betten wir ihn hier in eine Funktion mit den Schlüsselwörtern async und await ein, um sicherzustellen, dass die Variable „hash“ mit einem Ergebnis belegt ist, bevor die Funktion zurückkehrt:

Codebeispiel wird geladen…

Die js_set-Direktive in dieser NGINX Plus-Konfiguration weist der Variablen $hosthash den von der Funktion setReturnValue zurückgegebenen Wert zu (eingebettet in die Funktion host_hash):

Codebeispiel wird geladen…

Hier ist ein Beispiel, in dem der Hostname „example.com“ gehasht wird.

$ curl -H "Host: example.com" 127.0.0.1#
e8e624a82179b53b78364ae14d14d63dfeccd843b026bc8d959ffe0c39fc4ded1f4dcf4c8ebe871e657a12db6f11c3af87c9a1d4f2b096ba3deb56596f06b6f4

Weitere Verbesserungen in NGINX Plus R26

Unterstützung für die IBM-Z-Architektur (s390x)

Da moderne Anwendungen jeden verfügbaren digitalen Lebensraum erobern, ist es wichtig, dass die wesentlichen lebenserhaltenden Komponenten – wie NGINX – sie begleiten. Daher freuen wir uns, NGINX Plus auf der IBM-Z-Architektur (s390x) mit CentOS 8.1+, RHEL 8.1+ und Ubuntu 20.04 zu unterstützen. Unternehmen, die moderne Anwendungen auf ihren vorhandenen Mainframe-Systemen hosten möchten, können NGINX und NGINX Plus jetzt als softwarebasierten Webserver, Load Balancer, Reverse Proxy, Content-Cache und API-Gateway einsetzen.

Unterstützung für TCP-Halbschließungen im Stream-Modul

Die neue proxy_half_close-Direktive ermöglicht das unabhängige Schließen beider Richtungen einer TCP-Verbindung und sorgt so für zusätzliche Effizienz in stream{}-Kontexten.

Unterstützung für die PCRE2-Bibliothek

Frühere Versionen von NGINX Plus verwenden die Bibliothek für Perl-kompatible reguläre Ausdrücke (PCRE) (Version 1), um die in der NGINX-Konfiguration verwendeten regulären Ausdrücke auszuwerten. Dieses bedeutende Open-Source-Projekt hat vor Kurzem das Ende seines Lebenszyklus erreicht und wurde durch PCRE2 ersetzt. NGINX Plus wird mit PCRE2 erstellt, unterstützt jedoch dynamische Module, die sowohl mit PCRE als auch mit PCRE2 erstellt wurden, wobei die im zugrunde liegenden Betriebssystem verfügbare Version verwendet wird. Es sind keine Konfigurationsänderungen erforderlich.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R26 durchzuführen. Dadurch erhalten Sie außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten APIs für Überwachung und Verwaltung. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über den Autor

Robert HaynesManager für technisches Marketing

Weitere Blogbeiträge von Robert Haynes