Ankündigung von NGINX Plus R26

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 26 (R26) bekannt zu geben. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Software-Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.

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

• Schnellere JWT-Validierung mit JSON Web Key Set-Caching – In Fortsetzung der Reihe von Verbesserungen der JSON Web Tokens (JWT)-Unterstützung, die in den letzten Versionen hinzugefügt wurden, führen wir das In-Memory-Caching von JSON Web Key Sets (JWKS) ein, was den Aufwand für die JWT-Validierung erheblich reduziert.
• Gehärtete TLS-Handshakes – NGINX Plus lehnt den TLS-Handshake ab, wenn der Client über ALPN ein Kommunikationsprotokoll vorschlägt, das nicht mit dem NGINX-Konfigurationskontext für die herzustellende Sitzung übereinstimmt (schlägt beispielsweise einem virtuellen Server im http{} -Kontext das IMAP-E-Mail-Protokoll vor).
• Verbesserungen am NGINX JavaScript-Modul – Asynchrone Funktionen, die die Schlüsselwörter „async“ und „ await“ sowie das Promise -Objekt verwenden, werden jetzt unterstützt, und wir haben die WebCrypto-API für kryptografische Operationen (wie das Generieren von Zufallszahlen oder das Verschlüsseln von Cookies) implementiert.

Abgerundet wird diese Version durch die Unterstützung der IBM System Z-Architektur (s390x) , die Möglichkeit, jede Richtung einer TCP-Verbindung unabhängig zu schließen, und die Unterstützung für Version 2 der Perl Compatible Regular Expression (PCRE)-Bibliothek.

Wichtige Verhaltensänderungen

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

Wie bei der Veröffentlichung von NGINX Plus R23 angekündigt, in der Version0.4.0 des NGINX-JavaScript-Moduls wurde die Direktive js_include durch die Direktive js_import ersetzt. Die Direktive js_include war zu diesem Zeitpunkt veraltet 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 den JavaScript-Dateien außerdem eine Exportanweisung für Funktionen hinzu, auf die in der NGINX-Konfiguration verwiesen wird. Gehen Sie folgendermaßen vor:

1. NGINX-Konfigurationsdateien bearbeiten:

   • Ersetzen Sie js_include durch js_import und notieren Sie sich den impliziten Modulnamen (den JavaScript-Dateinamenparameter der Direktive ohne die Erweiterung .js ).

   • Stellen Sie in jeder Direktive, die auf eine JavaScript-Funktion verweist, dem Funktionsnamen den Modulnamen voran. Der Funktionsname ist der erste Parameter dieser Anweisungen:

     • js_body_filter
     • js_inhalt
     • js_filter
     • js_header_filter

     Es ist der zweite Parameter der Direktive js_set [ HTTP ][ Stream ].

   Ändern Sie beispielsweise:

   js_set $foo meineFunktion;
   

   Zu:

   js_set $foo Modulname .meineFunktion;
   

2. Bearbeiten Sie die JavaScript-Dateien ( Modulname .js ), die Funktionen definieren, auf die in einer NGINX-Konfigurationsdatei verwiesen wird. Fügen Sie jeder Datei eine Exportanweisung wie die folgende hinzu und benennen Sie die referenzierten Funktionen.

   export default { meineFunktion, andereFunktion }
   

   Die Exportanweisung kann an einer beliebigen Stelle in der JS- Datei erscheinen, wird jedoch üblicherweise entweder direkt über den Funktionen oder am Ende der Datei platziert.

Cookie-Flag-Modul ist veraltet

Das Cookie-Flag-Modul eines Drittanbieters wurde in NGINX Plus R23 verworfen und ist, wie damals angekündigt, ab dieser Version 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“ (definiert im veralteten Modul) durch die integrierte Direktive „proxy_cookie_flags“ zu ersetzen.

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

Die Art und Weise, wie NGINX TLS- und HTTP/2-Verbindungen herstellt, wurde aktualisiert. Als Teil des TLS-Handshakes zwischen NGINX und einem Client (normalerweise ein Browser) wird ausgehandelt, welches Kommunikationsprotokoll in der durch den Handshake hergestellten Sitzung verwendet wird (meistens wird die Sitzung durch die Aushandlung von HTTP 1. x auf HTTP/2 aktualisiert). Die Next Protocol Negotiation (NPN)-Erweiterung für TLS war die erste Methode, die zu diesem Zweck verwendet wurde. NPN gilt mittlerweile jedoch als veraltet und wurde durch die Application-Layer Protocol Negotiation (ALPN)-Erweiterung ersetzt, 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

Bei der Veröffentlichung von NGINX Plus R24 wurden die Paket-Repositorys für die gesamte NGINX-Software neu organisiert, was zu Änderungen am Installationsverfahren von NGINX Plus führte.

Wenn Sie NGINX Plus installieren oder aktualisieren, wird der Paketmanager des Betriebssystems ( apt , yum oder gleichwertig) mit dem Software-Repository für NGINX Plus konfiguriert.

Wenn Sie auf einem vorhandenen System, das für die Verwendung des alten Repository plus-pkgs.nginx.com konfiguriert ist (auf dem NGINX Plus R23 oder früher ausgeführt wird), ein Upgrade auf NGINX Plus R26 durchführen, müssen Sie den Paketmanager aktualisieren, damit er auf das neue Repository pkgs.nginx.com/plus verweist. Anweisungen finden Sie in der F5-Wissensdatenbank .

Wenn Sie eine Erstinstallation von NGINX Plus R26 durchführen, finden Sie weitere Informationen unter Installieren von NGINX Plus im NGINX Plus-Administratorhandbuch .

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

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

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

Änderungen an der Plattformunterstützung

Unterstützte neue 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 entfernt:

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

Ältere Betriebssysteme und Architekturen, die veraltet sind und deren Entfernung in NGINX Plus R27 vorgesehen ist:

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

Neue Features im Detail

Schnellere JWT-Validierung mit JSON Web Key Set Caching

Beim Validieren 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. JWKSs können entweder in Konfigurationsdateien gespeichert oder über eine HTTP-Anfrage von externen Diensten bezogen werden. Darüber hinaus bietet das Zwischenspeichern eines JWKS im Speicher mehrere Vorteile:

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

Um JWKSs im Speicher zwischenzuspeichern, schließen Sie die neue Direktive auth_jwt_key_cache ein und geben Sie die Ablaufzeit für jeden Schlüsselsatz an (in diesem Beispiel 3 Stunden):

Wenn JWKs von einem externen Server bezogen werden, empfehlen wir außerdem, die Standardinhaltszwischenspeicherung zu konfigurieren und die Direktive proxy_cache_use_stale einzuschließen, die NGINX Plus anweist, einen abgelaufenen JWKS weiterhin bereitzustellen, während er im Hintergrund aktualisiert wird.

Die Vorteile der Inhaltszwischenspeicherung zusätzlich zur JWKS-Zwischenspeicherung sind zweifach:

• Ausfallsicherheit – Das JWKS kann aus dem Cache abgerufen werden, auch wenn es abgelaufen ist. Dadurch wird die Ausfallsicherheit erhöht, wenn der JWKS-Anbieter vorübergehend nicht verfügbar ist, allerdings geht der Preis dafür ein höheres Sicherheitsrisiko einher.

• Auswirkungen auf den Autorisierungsserver – Das Ablaufen eines zwischengespeicherten JWKS wirkt sich auf den Authentifizierungsserver unterschiedlich aus, je nachdem, ob das JWKS-Caching allein oder in Kombination mit dem Inhalts-Caching verwendet wird:

  • Wenn nur JWKS-Caching verwendet wird, werden alle eingehenden Autorisierungsanfragen an den Authentifizierungsserver weitergeleitet, bis der Cache mit einer neuen Version des abgelaufenen JWKS aufgefüllt wird. Wenn der Authentifizierungsserver langsam antwortet, kann es zu einem plötzlichen Anstieg wiederholter HTTP-Anfragen für das JWKS kommen. Diese zusätzliche Belastung könnte den Authentifizierungsdienst überfordern und das Problem verschlimmern.

  • Wenn die Inhaltszwischenspeicherung mit Bereitstellung abgelaufener JWKSs aktiviert ist, wird nur eine Anforderung für die JWKS an den Authentifizierungsserver weitergeleitet, wobei nachfolgende Anforderungen in die Warteschlange gestellt werden, bis NGINX sie erfüllen kann, nachdem der Inhaltscache aufgefüllt wurde. Dies führt zu einer geringeren Nachfrage (und somit zu einem geringeren Ressourcenverbrauch) beim Authentifizierungsdienst.

Gehärtete TLS-Handshakes

Angriffe gegen TLS, beispielsweise ALPACA , nehmen zu. Als Teil unseres fortwährenden Engagements zur proaktiven Abwehr von Exploits haben wir die Handhabung von TLS-Verbindungen durch NGINX gehärtet.

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

NGINX Plus lehnt jetzt einen TLS-Handshake ab, wenn der Client über ALPN ein Protokoll vorschlägt, das nicht mit dem NGINX-Konfigurationskontext der herzustellenden Sitzung übereinstimmt. Beispielsweise erfordert ein im http{}- Kontext definierter virtueller Server eine ALPN-Protokoll-ID für HTTP, während ein virtueller Server im mail{} -Kontext eine Protokoll-ID für SMTP, POP oder IMAP erfordert.

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

Dieser Codeausschnitt definiert das Alpn -Protokollformat, das $ssl_alpn_protocol verwendet, um das Protokoll in das Feld „alpn= “ der Einträge im Zugriffsprotokoll aufzunehmen.

Die neue Direktive ssl_alpn im Kontext stream{} definiert, welche Protokolle NGINX Plus akzeptiert. Lassen Sie die Anweisung weg, damit NGINX Plus alle vom Client bereitgestellten Protokolle berücksichtigen kann.

Erweiterungen des NGINX JavaScript-Moduls

NGINX Plus R26 enthält Version0.7.2 des NGINX JavaScript-Moduls (njs) und beinhaltet zwei Erweiterungen:

• Verbesserte Unterstützung für asynchrone Funktionen mit den Schlüsselwörtern „async“ und „await“ und dem Promise- Objekt, das in ECMAScript 6 eingeführt wurde
• Eine Implementierung der WebCrypto API

Notiz: Dieser Abschnitt setzt voraus, dass Sie die JavaScript-Konstrukte für asynchrone und kryptografische Vorgänge verstehen. Eine vollständige Analyse der Codeausschnitte geht über den Rahmen dieses Blogs hinaus.

[ Herausgeber – Die in diesem Abschnitt beschriebenen Anwendungsfälle sind nur einige der vielen Anwendungsfälle für das NGINX JavaScript-Modul. Eine vollständige Liste finden Sie unter Anwendungsfälle für das NGINX JavaScript-Modul . ]

Erweiterte Unterstützung für asynchrone Funktionen

In vielen häufig verwendeten Skriptsprachen wie PHP werden Befehle und Funktionen synchron ausgeführt, d. h. nachdem ein Skript eine Funktion aufgerufen hat, wird es angehalten (die Ausführung wird gestoppt), bis die Funktion ein Ergebnis zurückgibt.

JavaScript kann auch asynchron arbeiten: Wenn eine Funktion asynchron aufgerufen wird, wird das Skript weiterhin ausgeführt, ohne auf die Rückgabe des Ergebnisses der Funktion zu warten.

Nehmen Sie dieses Beispielskript:

Es gibt eine leere Antwort zurück, da die njs-Laufzeit nicht auf den Ablauf der definierten Timeouts wartet (wenn sie warten würde, wäre die Ausgabe b,a ):

$ locken http://127.0.0.1/ $ 

Um das gewünschte Ergebnis zu erzielen, ist es offensichtlich entscheidend, asynchrone Vorgänge richtig zu handhaben. JavaScript bietet hierfür mehrere Möglichkeiten, in den gängigen NGINX-Anwendungsfällen ist es jedoch häufig wünschenswert, eine asynchrone Funktion einfach so zu verpacken, dass der Ausführungsfluss synchron ist. Hier kommen das Promise -Objekt und 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 existiert 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.

Nehmen Sie dieses Beispiel:

Die Funktion fs.readFile (Zeile 12) gibt ein Promise zurück. Es ist in eine benutzerdefinierte asynchrone Funktion gepackt, die sicherstellt, dass fs.readFile() nur aufgerufen wird, wenn die Datei user.text heißt. Aufgrund des Schlüsselworts „await“ wartet die Wrapping-Funktion dann auf das Promise und gibt die Daten zurück.

Durch das Einbinden von fs.readFile() in eine andere Funktion können Fehler leichter erkannt werden. Jede Ausnahme in der asynchronen Funktion setzt den Status des Promise auf rejected . Eine andere Möglichkeit besteht darin, Zeile 9 durch eine Anweisung zu ersetzen, die ein abgelehntes Promise zurückgibt:

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

Jetzt entspricht die Ausgabe unseres Curl -Befehls unseren Wünschen (beachten Sie, dass aufgrund des kürzeren Timeout-Werts zuerst „b“ zurückgegeben wird):

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

Neue kryptografische Funktionen mit der WebCrypto-API

NGINX JavaScript hat jetzt über die WebCrypto-API Zugriff auf erweiterte kryptografische Funktionen. Zu den üblichen Anwendungsfällen für NJS-Kryptografie gehören:

• Generieren sicherer Zufallszahlen für Sitzungs-IDs
• Verschlüsseln und Entschlüsseln von Nachrichten, Daten und Cookies
• Erstellen oder Validieren digitaler Signaturen mit symmetrischen und asymmetrischen Kryptoalgorithmen

Dieser NJS-Code generiert eine Zufallszahl:

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

Die Ausgabe der Funktion ist eine Zufallszahl, die in etwa wie folgt aussieht:

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

Die Funktion getRandomValues in WebCrypto ist ein hervorragender Einstiegspunkt für den Einstieg in sichere Zufallszahlen und WebCrypto im Allgemeinen. Die Implementierung ist recht einfach und die Funktion gibt Ergebnisse direkt zurück, anstatt ein Promise zurückzugeben.

Einige der anderen intensiveren kryptografischen Funktionen von WebCrypto arbeiten jedoch asynchron. In der Dokumentation für сrypto.subtle.digest() heißt es beispielsweise:

Generiert einen Digest der angegebenen Daten. Nimmt als Argumente eine Kennung für den zu verwendenden Digest-Algorithmus und die zu verdauenden Daten. Gibt ein Versprechen zurück , das mit dem Digest erfüllt wird.

Der direkte Aufruf von сrypto.subtle.digest() garantiert daher nicht, dass das Ergebnis im nächsten Schritt verfügbar ist, es sei denn, es ist in eine asynchrone Funktion gekapselt. Daher verpacken wir es hier in eine Funktion mit den Schlüsselwörtern „async“ und „ await “, um sicherzustellen, dass die Hash-Variable mit einem Ergebnis gefüllt ist, bevor die Funktion zurückkehrt:

Die js_set- Direktive in dieser NGINX Plus-Konfiguration füllt die Variable $hosthash mit dem von der Funktion setReturnValue zurückgegebenen Wert (wie in der Funktion host_hash gepackt):

Hier ist ein Beispiel, das den Hostnamen example.com hasht.

$ 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 jedes verfügbare digitale Biom besiedeln, ist es wichtig, dass die wesentlichen lebenserhaltenden Komponenten – wie NGINX – mit ihnen reisen. 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. Organisationen, die moderne Anwendungen auf ihren vorhandenen Mainframe-Ressourcen hosten möchten, können NGINX und NGINX Plus jetzt als softwarebasierten Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway einsetzen.

TCP Half-Close-Unterstützung im Stream-Modul

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

PCRE2-Bibliotheksunterstützung

Frühere Versionen von NGINX Plus verwenden die PCRE-Bibliothek (Perl Compatible Regular Expression) (Version 1), um in der NGINX-Konfiguration verwendete reguläre Ausdrücke auszuwerten. Dieses bedeutende Open-Source-Projekt hat vor Kurzem das Ende seiner Lebensdauer erreicht und wurde durch PCRE2 ersetzt. NGINX Plus basiert auf PCRE2, unterstützt jedoch dynamische Module, die sowohl mit PCRE als auch mit PCRE2 erstellt wurden, und verwendet dabei die Version, die mit dem zugrunde liegenden Betriebssystem verfügbar ist. Es sind keine Konfigurationsänderungen erforderlich.

Upgrade oder Testen von NGINX Plus

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R26 zu aktualisieren. Sie erhalten außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen.