Ankündigung von NGINX Plus R32

Prabhat Dixit

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

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

• Caching von SSL-Zertifikaten — NGINX Plus R32 verbessert die Startzeit von NGINX und die Speichernutzung bei Konfigurationen mit einer großen Anzahl von Locations, in denen dieselben SSL-Zertifikat-/Schlüsselpaarungen wiederholt verwendet werden, erheblich.
• Stream_pass-Modul — NGINX Plus R32 ermöglicht es dem Stream-Modul nun, als Router zu fungieren, sodass Verbindungen abhängig von bestimmten Bedingungen vom Stream-Modul an andere Module wie HTTP oder Mail oder zurück an das Stream-Modul selbst weitergeleitet werden können.
• Offizielle NGINX Plus-Container-Images — Mit NGINX Plus R32 sind nun offizielle NGINX Plus-Container-Images sowohl für privilegierte als auch für nicht privilegierte Container-Laufzeitumgebungen verfügbar. Darüber hinaus werden für beide Bereitstellungsmethoden optionale Container-Images angeboten, die den NGINX Agent enthalten – einen begleitenden Daemon, der eine nahtlose Integration in Lösungen der NGINX-Verwaltungsebene ermöglicht.

Abgerundet wird das Release durch neue Funktionen und Fehlerbehebungen aus NGINX Open Source sowie Aktualisierungen des NGINX-JavaScript-Moduls.

Wichtige Verhaltensänderungen

Hinweis: Wenn Sie ein Upgrade von einer anderen Version als NGINX Plus R31 durchführen, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den früheren Ankündigungsbeiträgen für alle Versionen zwischen Ihrer aktuellen Version und dieser Version.

Veraltung des OpenTracing-Moduls

Das mit NGINX Plus R18 eingeführte OpenTracing-Modul gilt künftig als veraltet und soll in NGINX Plus R34 entfernt werden. Die zugehörigen Pakete werden bis dahin mit allen Versionen von NGINX Plus bereitgestellt. Wir empfehlen dringend, das OpenTracing-Modul durch das OpenTelemetry-Modul zu ersetzen, das mit NGINX Plus R29 eingeführt wurde.

Entfernung des ModSecurity-Moduls

Der Support für das ModSecurity-Modul endete am 31. März 2024. Daher wurden die modsec-Pakete aus dem NGINX Plus-Repository entfernt und werden dort künftig nicht mehr verfügbar sein.

Aktualisierung des PGP-Schlüssels

Pakete von NGINX Open Source und NGINX Plus werden mit einem PGP-Schlüssel signiert. Dieser Schlüssel läuft am 16. Juni 2024 ab. Wir haben das Ablaufdatum des Schlüssels aktualisiert, damit bestehende Pakete auch nach dem 16. Juni 2024 weiterhin verifiziert werden können. Für die Signierung von Paketen für kommende Releases werden wir neue Schlüsselpaare generieren.

Alle NGINX-Benutzer sollten den aktualisierten PGP-Schlüssel herunterladen und installieren. Führen Sie dazu die folgenden Schritte aus:

Unter Ubuntu/Debian:

wget -qO - https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

Unter RHEL/CentOS:

sudo rpm -e gpg-pubkey-7bd9bf62-5762b5f8
sudo rpm --import https://nginx.org/keys/nginx_signing.key

Nach dem 16. Juni 2024 können Sie Ihre Softwaresignaturen erst wieder verifizieren, wenn Sie Ihren Schlüssel aktualisiert haben.

Künftige Richtlinie für Paketierung und Veröffentlichungen

In zukünftigen Versionen von NGINX Plus werden wir unsere Paketierungs- und Veröffentlichungsrichtlinien vereinfachen. NGINX Plus wird nur noch für die neuesten Versionen der unterstützten Betriebssystemdistributionen erstellt und getestet. Wenn Sie NGINX Plus auf älteren Distributionen installieren, schlägt Ihr Paketmanager möglicherweise vor, die erforderlichen Bibliotheken und Pakete zu aktualisieren.

Änderungen bei der Plattformunterstützung

In dieser Version wurden die folgenden Änderungen an den unterstützten Plattformen vorgenommen.

Neu unterstützte Betriebssysteme:

• Ubuntu 24.04

Ältere Betriebssysteme entfernt:

• FreeBSD 12, dessen Support am 31. Dezember 2023 endete

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

• CentOS7/RHEL7/Oracle Linux 7
• Alpine Linux 3.16

Neue Funktionen im Detail

Caching von SSL-Zertifikaten zur Verbesserung des Lastverhaltens von NGINX

Bisher lud NGINX ein Zertifikat, einen Schlüssel oder eine Zertifikatsperrliste jedes Mal neu, wenn in der NGINX-Konfiguration darauf verwiesen wurde. Mehrere Verweise auf dasselbe Objekt führten somit dazu, dass dieses Objekt entsprechend oft neu geladen wurde. Diese Verzögerung verstärkte sich bei der Vererbung von Direktiven wie Listen vertrauenswürdiger Zertifikate. Unter bestimmten Bedingungen beeinträchtigte dieses Verhalten die Startzeit von NGINX erheblich und konnte große Mengen an Arbeitsspeicher zum Speichern der Konfigurationen erfordern.

Mit dem neuen Verhalten verweisen SSL-Direktiven nun auf zwischengespeicherte Zertifikatsdateien und zugehörige Objekte. Dadurch werden der Speicherbedarf und die Ladezeiten von Konfigurationen, die wiederholt auf dieselben Zertifikatsobjekte verweisen, drastisch reduziert. Der Vorteil zeigt sich am deutlichsten bei umfangreichen NGINX-Konfigurationen, in denen eine kleine Gruppe vertrauenswürdiger Zertifikate in einer großen Anzahl von Location-Blöcken referenziert wird.

Hier sehen Sie eine Visualisierung der Verbesserung der Ladezeit bei einer NGINX-Konfiguration mit etwa 5.400 Location-Blöcken (auf oberster Ebene und verschachtelt) und 878 Zertifikaten.

Beachten Sie den deutlichen Rückgang der Ladezeiten auf der rechten Seite des Diagramms: Die durchschnittliche Ladezeit sinkt von etwa 40 Sekunden vor der Änderung auf ca. 6 Sekunden mit dem neuen Verhalten.

Verbindungen vom Stream-Modul an andere Module weitergeben

NGINX Plus R32 übernimmt eine Funktion aus NGINX Open Source 1.25.5, die NGINX eine neue Konfigurationsebene hinzufügt. Insbesondere kann das NGINX-stream-Modul nun als Router fungieren und als Proxy Verbindungen aus dem stream-Kontext an andere Kontexte wie http oder mail oder an einen separaten virtuellen Server innerhalb des stream-Kontexts selbst weiterleiten.

Diese Funktionalität ist Bestandteil des Moduls ngx_stream_pass_module, das mit dieser Version eingeführt wurde. Das Modul verfügt über eine einzige Direktive namens „pass“, mit der die Adresse angegeben werden kann, an die Clientverbindungen weitergeleitet werden sollen. Die Adresse kann als Kombination aus IP-Adresse und Port oder als Socket-Pfad angegeben oder über NGINX-Variablen referenziert werden.

Mit dieser Funktionalität können Kunden, die ihren gesamten Datenverkehr über einen einzigen L4-Endpunkt leiten möchten, SSL-Verbindungen nun im L4-Stream-Kontext terminieren und an andere Module (HTTP, Mail) oder andere virtuelle Server innerhalb des Stream-Kontexts weiterleiten. Darüber hinaus können SSL-Verbindungen abhängig von Servernamen oder Protokollen bedingt terminiert werden, während der verbleibende Datenverkehr per Proxy an anderer Stelle weitergeleitet wird. Dies eröffnet neue Konfigurationsmöglichkeiten für die Verwaltung des Datenverkehrs über einen einzigen Endpunkt.

Der folgende Konfigurationsausschnitt terminiert SSL-Verbindungen im Stream-Modul und leitet sie abhängig vom angeforderten Servernamen an den HTTP-Kontext oder einen anderen virtuellen Server im Stream-Kontext weiter.

http {
    server {
        listen 8000;

        location / {
            return 200 foo;
        }
    }
}

stream {
	 map $ssl_server_name $pass_port {
		foo.example.com 8000;
		default 9001;
	
	}

    server {
        listen 9000 ssl;

        ssl_certificate     domain.crt;
        ssl_certificate_key domain.key;

        pass 127.0.0.1:$pass_port;
    }
	server{
		listen 9001;
		return bar\n;
	}

}

In diesem Beispiel werden alle SSL-Verbindungen im stream-Serverblock terminiert. Abhängig vom Servernamen in der eingehenden Anfrage werden die Verbindungen entweder an den http-Server, der Port 8000 überwacht, oder an den virtuellen stream-Server, der Port 9001 überwacht, weitergeleitet.

Eine weitere Anwendung des Moduls betrifft Anwendungsfälle, in denen ein Drittanbietermodul keine SSL-Terminierung unterstützt. In solchen Szenarien kann das stream_pass-Modul TLS-verschlüsselte Verbindungen terminieren, bevor es sie an das Drittanbietermodul weiterleitet.

Dieses Beispiel zeigt, wie das RTMP-Modul, das SSL nicht nativ unterstützt, mithilfe des stream_pass-Moduls TLS-verschlüsselten Datenverkehr annehmen kann.

rtmp {
    server {
        listen 1935;#rtmp
	
	application foo{
		
		live on;
        }
    }
}

stream {
    server {
        listen 1936 ssl; #rtmps

        ssl_certificate     domain.crt;
        ssl_certificate_key domain.key;

        pass 127.0.0.1:1935;
    }
}

In diesem Konfigurationsausschnitt wird die SSL-Verbindung im stream-Serverblock terminiert und an rtmp weitergeleitet. Für das RTMP-Modul erscheint die Verbindung unverschlüsselt, sodass keine zusätzlichen Anpassungen oder zusätzlicher Verarbeitungsaufwand zur Unterstützung von SSL-Verbindungen erforderlich sind.

NGINX Plus-Container-Images

NGINX Plus R32 bietet offiziell NGINX Plus-Container-Images für die privilegierte und nicht privilegierte Ausführung von NGINX Plus. Beide Containertypen sind außerdem mit optionalen Installationen von NGINX Agent verfügbar, um eine einfache Verbindung zu den von NGINX unterstützten Management-Plattformen zu ermöglichen. Die Images können aus der NGINX-Registry unter private-registry.nginx.com heruntergeladen werden. Befolgen Sie diese Anweisungen für den Zugriff auf das Image mit Ihrem NGINX Plus-Zertifikat und -Schlüssel oder einem JSON Web Token (JWT).

Weitere Verbesserungen und Fehlerbehebungen in NGINX Plus R32

Fehlerbehebung im MQTT-Modul

• Fehlerhafte Pakete bei Verwendung von Standardeigenschaften: Diese Version enthält eine Fehlerbehebung für ein Problem, das zu fehlerhaften Paketen im Message Queuing Telemetry Transport (MQTT)-Modul führte und mit NGINX Plus R29 eingeführt wurde. Wenn das Eigenschaftenfeld vorhanden war und für alle Eigenschaften in der MQTT-Connect-Nachricht Standardwerte enthielt, wurde das Feld für die Eigenschaftenlänge (1 Byte) bei der Berechnung der Länge des ausgehenden Pakets bisher nicht berücksichtigt. Dadurch war die Paketlänge 1 Byte kürzer als erwartet, was zu einem fehlerhaften Paket führte. Dieses Problem wurde in R32 behoben.

Fehlerbehebung im Modul zone_sync

• Speicherleck beim Neuladen der Konfiguration: Zuvor verwendeten ausstehende Synchronisierungsvorgänge in der Warteschlange Kettenglieder, die aus einem separaten Pool zugewiesen wurden, der nie freigegeben wurde. Dies führte zu Speicherlecks im Masterprozess sowie in allen Worker-Prozessen. Mit der Fehlerbehebung in dieser Version wird wieder eine frühere Implementierung der Zonensynchronisierung verwendet, die für die Warteschlange mit ausstehenden Vorgängen einen Zyklus-Pool nutzt.

Sicherheitskorrekturen

Die folgenden potenziellen Sicherheitsprobleme wurden in der experimentellen HTTP3/QUIC-Implementierung identifiziert und behoben.

• Heap-Überlauf mit Schreibzugriff (CVE-2024-32760): Nicht offengelegte HTTP/3-Encoder-Anweisungen können dazu führen, dass NGINX-Worker-Prozesse beendet werden, oder andere mögliche Auswirkungen haben.
• Stacküberlauf/Use-after-free (CVE-2024-31079): Nicht offengelegte HTTP/3-Anfragen können dazu führen, dass NGINX-Worker-Prozesse beendet werden, oder andere mögliche Auswirkungen haben. Für diesen Angriff muss eine Anfrage während des Verbindungsabbaus zu einem ganz bestimmten Zeitpunkt erfolgen, auf den der Angreifer keine Einsicht und nur begrenzten Einfluss hat.
• Nullzeiger-Dereferenzierung bei leerem Header (CVE-2024-35200): Nicht offengelegte HTTP/3-Anfragen können dazu führen, dass NGINX-Worker-Prozesse beendet werden, oder andere mögliche Auswirkungen haben.
• Offenlegung von Speicherinhalten während des QUIC-Handshakes (CVE-2024-34161): Wenn die Netzwerkinfrastruktur eine maximale Übertragungseinheit (Maximum Transmission Unit, MTU) von mindestens 4096 ohne Fragmentierung unterstützt, können nicht näher beschriebene QUIC-Nachrichten dazu führen, dass NGINX-Worker-Prozesse beendet oder zuvor freigegebene Speicherinhalte offengelegt werden.

Von NGINX Open Source übernommene Änderungen

NGINX Plus R32 basiert auf NGINX Open Source 1.25.5 und übernimmt funktionale Änderungen, neue Funktionen und Fehlerbehebungen, die seit der Veröffentlichung von NGINX Plus R31 vorgenommen wurden (in NGINX 1.25.4 und 1.25.5).

Funktionen:

• Virtuelle Server im Stream-Modul.
• Das Modul ngx_stream_pass_module.
• Die Parameter „deferred“, „accept_filter“ und „setfib“ der Direktive „listen“ im Stream-Modul.
• Erkennung der Cache-Zeilengröße für einige Architekturen.
• Unterstützung für Homebrew auf Apple Silicon.

Fehlerbehebungen:

• Fehlerbehebungen und Verbesserungen bei der Cross-Kompilierung für Windows.
• Unerwarteter Verbindungsabbruch bei der Verwendung von 0-RTT in QUIC.
• Verbindungen mit ausstehenden AIO-Vorgängen werden beim ordnungsgemäßen Herunterfahren alter Worker-Prozesse möglicherweise vorzeitig geschlossen.
• Warnungen zu Socket-Leaks werden nicht mehr protokolliert, wenn nach dem ordnungsgemäßen Herunterfahren alter Worker-Prozesse ein schnelles Herunterfahren angefordert wurde.
• Wenn AIO in einer Unteranfrage verwendet wurde, konnte in einem Worker-Prozess (beim SSL-Proxying) ein Socket-Deskriptorfehler, ein Socket-Leck oder ein Segmentierungsfehler auftreten.
• In einem Worker-Prozess konnte ein Segmentierungsfehler auftreten, wenn SSL-Proxying zusammen mit der Direktive „image_filter“ verwendet wurde und Fehler mit dem Code 415 mithilfe der Direktive „error_page“ umgeleitet wurden.
• Fehlerbehebungen und Verbesserungen in HTTP/3.

Sicherheit:

• Bei der Verwendung von HTTP/3 kann in einem Worker-Prozess während der Verarbeitung einer speziell präparierten QUIC-Sitzung ein Segmentierungsfehler auftreten (CVE-2024-24989, CVE-2024-24990).

Eine vollständige Liste der Neuerungen, Funktionen, Fehlerbehebungen und Problemumgehungen aus den letzten Versionen finden Sie in der NGINX-Datei „changes“.

Änderungen am NGINX-JavaScript-Modul

NGINX Plus R32 enthält Änderungen aus Version 0.8.4 des NGINX-JavaScript-Moduls (njs). Im Folgenden sind die wichtigsten Änderungen in njs seit Version 0.8.2 aufgeführt (der mit NGINX Plus R31 ausgelieferten Version).

Funktionen

• Funktion: Der Server-Header für ausgehende Header kann festgelegt werden.
• Funktion: Unterstützung der QuickJS-Engine in der CLI.

Änderungen

• Verbesserung: Validierung der Argumente URI und args in r.subrequest().
• Verbesserung: Prüfung auf doppelte js_set-Variablen.

Fehlerbehebungen

• Fehlerbehebung: Headers.set() wurde korrigiert.
• Fehlerbehebung: js_set mit Buffer-Werten korrigiert.
• Fehlerbehebung: Die Methode clear() eines gemeinsam genutzten Dictionarys wurde korrigiert, wenn kein Timeout angegeben ist.
• Fehlerbehebung: Die stub_status-Statistiken wurden korrigiert, wenn js_periodic aktiviert ist.
• Fehlerbehebung: Kompilierung mit libxml2 2.12 und höher korrigiert.
• Fehlerbehebung: Der Date-Konstruktor wurde für Überläufe und NaN-Werte korrigiert.
• Fehlerbehebung: Unterlauf in querystring.parse() behoben.
• Fehlerbehebung: Ein potenzielles Überlesen des Puffers in String.prototype.match() wurde behoben.
• Fehlerbehebung: Das Parsen von for-in-Schleifen wurde korrigiert.
• Fehlerbehebung: Das Parsen von hexadezimalen, oktalen und binären Literalen ohne Ziffern wurde korrigiert.
• Fehlerbehebung: Die in 0.8.3 eingeführte fehlerhafte clear()-Methode eines gemeinsam genutzten Dictionarys ohne Zeitüberschreitung wurde korrigiert.
• Fehlerbehebung: Die Methode r.send() eines gemeinsam genutzten Dictionarys ohne Zeitüberschreitung wurde bei Verwendung eines Buffer-Arguments korrigiert.
• Fehlerbehebung: atob() funktioniert nun auch mit Base64-Zeichenfolgen ohne Auffüllzeichen.

Eine vollständige Liste aller Funktionen, Änderungen und Fehlerbehebungen finden Sie im njs-Änderungsprotokoll.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R32 durchzuführen. Neben all den großartigen neuen Funktionen erhalten Sie damit auch mehrere zusätzliche Fehlerbehebungen und Verbesserungen, sodass NGINX Sie leichter unterstützen kann, falls Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht nutzen, empfehlen wir Ihnen, es auszuprobieren. Sie können es für Sicherheits-, Lastverteilungs- und API-Gateway-Anwendungsfälle oder als vollständig unterstützten Webserver mit erweiterten APIs für Überwachung und Verwaltung einsetzen. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über den Autor

Prabhat Dixit

Weitere Blogbeiträge von Prabhat Dixit