Ankündigung von NGINX Plus R17

NGINX | 11. Dezember 2018

Liam CrillySenior Director, Produktmanagement

[Redaktion – Das NGINX ModSecurity WAF-Modul für NGINX Plus wurde zum 1. April 2022 offiziell aus dem Verkauf genommen und erreicht am 31. März 2024 sein Lebensende. Weitere Informationen finden Sie unter „F5 NGINX ModSecurity WAF erreicht das Lebensende<.htmla>“ in unserem Blog.]

Wir freuen uns, Ihnen mitteilen zu können, dass NGINX Plus Release 17 (R17) ab sofort verfügbar ist. NGINX Plus ist der einzige Load Balancer, Content-Cache, Webserver und API-Gateway in einer Komplettlösung. NGINX Plus basiert auf NGINX Open Source und bietet exklusive erweiterte Funktionen sowie preisgekrönten Support.

Neu in dieser Version ist die Unterstützung für TLS 1.3, die neueste Version des Protokolls, das für den gesamten sicheren Datenverkehr im Internet verantwortlich ist. Seit der Veröffentlichung von TLS 1.2 sind über zehn Jahre vergangen, und seitdem hat sich viel verändert. In TLS 1.2 wurden zahlreiche Sicherheitslücken entdeckt, darunter FREAK, Heartbleed, POODLE und ROBOT. Viele dieser Schwachstellen waren auf zu viele unsichere Konfigurationsoptionen in TLS 1.2 zurückzuführen, durch die Websites Angriffen ausgesetzt waren.

TLS 1.3 erreicht mehr durch weniger. Viele unsichere Verschlüsselungsverfahren wurden entfernt, und der Diffie-Hellman-Schlüsselaustausch ist nun obligatorisch. Das Ergebnis ist ein schlankeres, schnelleres und sichereres TLS. Zum Zeitpunkt der Erstellung dieses Artikels unterstützen Alpine Linux 3.9, FreeBSD 12.0 und Ubuntu 18.10 TLS 1.3, sodass Sie diese Betriebssysteme mit NGINX Plus R17 für TLS 1.3 in Ihrer Produktionsumgebung verwenden können. Andere Betriebssystemanbieter werden TLS 1.3 zweifellos in zukünftigen Versionen unterstützen. Beachten Sie, dass F5 BIG-IP und andere Hardware-Load-Balancer TLS 1.3 derzeit nicht vollständig unterstützen.

NGINX Plus R17 umfasst außerdem die folgenden neuen Funktionen:

Zweistufige Anfrageratenbegrenzung – Die Anfrageratenbegrenzung gehört zu den beliebtesten Funktionen von NGINX Open Source und NGINX Plus. Sie kann zur Abwehr von DDoS-Angriffen eingesetzt werden und schützt Anwendungsserver generell davor, durch zu viele Anfragen überlastet zu werden. Der neue Parameter delay hilft der Anfrageratenbegrenzung von NGINX Plus, typische Anfragemuster von Browsern besser zu berücksichtigen. Die bestehenden Durchsetzungsmethoden zum Verzögern und Ablehnen können nun zu einer zweistufigen Anfrageratenbegrenzung kombiniert werden. Dabei werden überzählige Anfragen zunächst verzögert und schließlich abgelehnt, wenn die zulässige Anfragerate weiterhin überschritten wird.
Einfachere OpenID-Connect-Konfiguration – Mit NGINX Plus R15 haben wir die OpenID-Connect-Integration eingeführt, mit der unsere Kunden ihre Anwendungen um Single Sign-on (SSO) erweitern können. In R17 haben wir die Konfiguration vereinfacht, sodass JSON Web Keys (JWKs) automatisch vom Identitätsanbieter (IdP) abgerufen werden.
NGINX ModSecurity WAF ist doppelt so schnell – NGINX ModSecurity WAF, ein auf ModSecurity v3 basierendes dynamisches Modul für NGINX Plus, bietet zuverlässigen Schutz vor Angriffen auf Layer 7. ModSecurity wird aktiv weiterentwickelt, und die neueste Version von NGINX ModSecurity WAF bietet die doppelte Leistung sowie eine Reihe weiterer Verbesserungen.

Weitere Verbesserungen in NGINX Plus R17 umfassen TCP-Keepalives für Upstream-Server, SNI-Unterstützung in Cluster-Umgebungen und mehr.

Wichtige Verhaltensänderungen

Mit NGINX Plus R13 wurde die völlig neue NGINX Plus API zur Erfassung von Metriken und dynamischen Neukonfiguration von Upstream-Gruppen eingeführt. Sie ersetzte die Status- und Upstream-Conf-APIs, die diese Funktionen zuvor bereitstellten. Wie seinerzeit angekündigt, blieben die veralteten APIs noch über einen längeren Zeitraum verfügbar und wurden weiterhin unterstützt. Dieser Zeitraum endete mit NGINX Plus R16. Wenn Ihre Konfiguration die Direktiven status und/oder upstream_conf enthält, müssen Sie diese im Rahmen des Upgrades auf R17 durch die Direktive api ersetzen. Hinweise und Unterstützung bei der Migration zur NGINX Plus API finden Sie im Migrationsleitfaden in unserem Blog. Alternativ können Sie sich an unser Supportteam wenden.
Neu unterstützte Betriebssysteme:
- Alpine Linux 3.8
- Alpine Linux 3.9
- FreeBSD 11.2
- FreeBSD 12.0
- SUSE Linux Enterprise Server 15
- Ubuntu 18.10 (Cosmic)
Ältere Betriebssysteme, die entfernt wurden oder zur Entfernung vorgesehen sind:
- FreeBSD 10.4 und 11.1 werden nicht mehr unterstützt.
- Die Unterstützung für CentOS/Oracle/RHEL 7.3 und ältere Versionen wird mit NGINX Plus R18 eingestellt.
- Die Unterstützung für Ubuntu 14.04 wird mit NGINX Plus R19 eingestellt.

Neue Funktionen im Detail

TLS 1.3: Mehr durch weniger

Seit der letzten größeren Aktualisierung von TLS sind über 10 Jahre vergangen. TLS 1.2 wurde im August 2008 als RFC 5246 definiert, und das Internet hat sich seitdem erheblich verändert. TLS 1.3 wurde im August 2018 als RFC 8446 ratifiziert, um viele der in TLS 1.2 festgestellten Probleme zu beheben und eine besser skalierbare Plattform für die Zukunft zu schaffen.

Sicherer

Im Laufe der Jahre wurden zahlreiche Sicherheitslücken in TLS 1.2 bekannt, darunter FREAK, Heartbleed, POODLE und ROBOT. FREAK ermöglicht es einem Angreifer beispielsweise, eine TLS-Verbindung auf eine Exportverschlüsselung mit einer Schlüssellänge von 40 Bit herabzustufen, die sich durch Brute-Force-Angriffe knacken lässt. In TLS 1.3 wurden Exportverschlüsselungen vollständig entfernt.

Viele der Probleme, die bei TLS 1.2 und früheren Spezifikationen aufgetreten sind, sind auf die große Anzahl benutzerkonfigurierbarer Optionen zurückzuführen. Die unsachgemäße Verwendung dieser Optionen führte häufig zu unsicheren Konfigurationen, die von Angreifern ausgenutzt werden konnten. TLS 1.3 schafft einige dieser Optionen ab:

AES‑CBC
Beliebige Diffie-Hellman-Gruppen
Export-Chiffren
DES/3DES
MD5
PKCS#1-v1.5-Padding
RC4
RSA-Schlüsseltransport (Diffie-Hellman ist obligatorisch)
SHA‑1

Bessere Leistung

Besonders hervorzuheben unter den entfernten Funktionen ist der RSA-Schlüsseltransport. Dieser Modus wurde hauptsächlich verwendet, weil er schneller als Diffie-Hellman war, das einen zusätzlichen Roundtrip erforderte, um die Verbindung mit Perfect Forward Secrecy (PFS) aufzubauen. Mit TLS 1.3 ist dieser zusätzliche Roundtrip nicht mehr erforderlich. Da es weniger Konfigurationsoptionen gibt, müssen weniger Informationen ausgetauscht werden, und der Diffie-Hellman-Handshake benötigt nur einen einzigen Roundtrip (das Diagramm zeigt außerdem eine auf den Handshake folgende GET-Anfrage).

TLS 1.3 verbessert die Leistung, indem die Anzahl der Roundtrips zum Aufbau einer sicheren Verbindung reduziert wird.

Darüber hinaus unterstützt TLS 1.3 die Sitzungswiederaufnahme. Diese beschleunigt den Verbindungsaufbau, da bei der Rückkehr eines Clients zu einer zuvor besuchten Website der TLS-Handshake nicht erneut durchgeführt werden muss. Dies wird auch als 0‑RTT-Wiederaufnahme (Zero Round Trip Time) bezeichnet, da für die wiederaufgenommene Sitzung keine Handshake-Nachrichten zwischen Client und Server ausgetauscht werden müssen. Die Sitzungswiederaufnahme wird umgesetzt, indem während der ursprünglichen Sitzung ein gemeinsames Geheimnis erstellt und in einem Sitzungsticket gespeichert wird. Wenn der Client zurückkehrt, übermittelt er das Sitzungsticket zusammen mit seiner Anfrage, die mit dem im Ticket enthaltenen gemeinsamen Geheimnis verschlüsselt ist.

TLS 1.3 ermöglicht die schnelle Wiederaufnahme von TLS-Sitzungen

Die Verwendung von 0‑RTT birgt das Risiko eines Replay-Angriffs, wie unten dargestellt. In diesem Szenario sendet der Angreifer ein Paket erneut, das eine Zustandsänderung bewirkt, beispielsweise eine Aufforderung, Geld zwischen zwei Bankkonten zu überweisen.

Ein Replay-Angriff mit 0-RTT

Zum Schutz vor Replay-Angriffen sollten Clients in den 0‑RTT-Daten (den mit dem gemeinsamen Geheimnis verschlüsselten Daten) ausschließlich HTTP-Anfragen des Typs GET senden. HTTP-GET-Anfragen sind per Definition idempotent (RFC 7231), sodass ihre erneute Übertragung keine Auswirkungen hat. Beim erneuten Besuch einer Website lädt ein Client in der Regel zuerst eine Seite, und die meisten Seitenaufrufe beginnen mit einer GET-Anfrage. Daher beschleunigt die Aktivierung der Sitzungswiederaufnahme einen großen Teil der Anfragen an die meisten Websites. Wenn Sie NGINX Plus als API-Gateway bereitstellen, sollten Sie die 0‑RTT-Wiederaufnahme jedoch möglicherweise nicht aktivieren, da wiederaufgenommene TLS-Sitzungen bei API-Datenverkehr mit höherer Wahrscheinlichkeit nicht idempotente Anfragetypen enthalten.

TLS 1.3 selbst schützt ebenfalls vor Replay-Angriffen, indem sowohl das Sitzungsticket als auch die Clientanfrage mit Zeitinformationen versehen werden. So kann der Server feststellen, ob die Anfrage innerhalb eines angemessenen Zeitraums nach dem Absenden durch den Client eingegangen ist. Da Angreifer die Zeitinformationen nicht verändern können, wurde eine Anfrage, deren Übertragung zu lange gedauert hat, wahrscheinlich erneut abgespielt.

So aktivieren Sie TLS 1.3 in NGINX Plus

TLS 1.3 und 0‑RTT sind standardmäßig nicht aktiviert.

Um TLS 1.3 zu aktivieren, fügen Sie der Direktive TLSv1.3 den Parameter ssl_protocols hinzu. Wir empfehlen, auch TLSv1.2 einzubeziehen, da zum Zeitpunkt der Erstellung dieses Artikels nicht alle Browser TLS 1.3 unterstützen (siehe nächster Abschnitt). NGINX Plus verwendet TLS 1.3, wenn der Client es unterstützt, und greift andernfalls auf TLS 1.2 zurück.

Um 0‑RTT zu aktivieren, setzen Sie außerdem die Direktive „ssl_early_data“ auf „on“.

Diese Konfiguration aktiviert beide Funktionen:

server {    listen 443 ssl;
    ssl_certificate     /etc/ssl/my_site_cert.pem;
    ssl_certificate_key /etc/ssl/my_site_key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_early_data on; # Enable 0-RTT (TLS 1.3)

    location / {
        proxy_pass http://my_backend;
    }
}

Unterstützte Plattformen

Auf der Serverseite erfordert TLS 1.3 OpenSSL 1.1.1 oder höher. Zum Zeitpunkt der Erstellung dieses Textes werden nur Alpine Linux 3.9, FreeBSD 12.0 und Ubuntu 18.10 mit OpenSSL 1.1.1 ausgeliefert.

Auf der Clientseite empfehlen wir Chrome 70 oder Firefox 63. Beide unterstützen die endgültige Version von TLS 1.3, aktivieren sie jedoch nicht standardmäßig. Befolgen Sie diese Anleitung, um TLS 1.3 im Browser zu aktivieren. Zum Zeitpunkt der Erstellung dieses Artikels unterstützen andere beliebte Browser (darunter Firefox für Android und Safari für iOS und Mac) TLS 1.3 noch nicht. Aktuelle Informationen zum Status finden Sie unter Can I Use: TLS 1.3.

Zweistufige Ratenbegrenzung

Bisher konnte NGINX Plus Anfrageraten auf zwei Arten begrenzen: durch die sofortige Ablehnung überzähliger Anfragen oder durch deren Einreihung in eine Warteschlange, bis sie unter Einhaltung der festgelegten Ratenbegrenzung verarbeitet werden konnten. Mit NGINX Plus R17 können Sie beide Durchsetzungsmethoden zu einer zweistufigen Ratenbegrenzung kombinieren, bei der überzählige Anfragen zunächst verzögert und schließlich abgelehnt werden, wenn die Ratenbegrenzung weiterhin überschritten wird.

Bei der Anwendung von Ratenbegrenzungen muss unbedingt das typische Verhalten legitimer Clients berücksichtigt werden. Webbrowser versuchen beispielsweise in der Regel, mehrere Ressourcen gleichzeitig herunterzuladen. Daher ist es normal, dass auf eine Anfrage nach dem HTML-Inhalt kurz darauf Anfragen nach Stylesheets, JavaScript-Code und Bildern folgen. Aus diesem Grund empfiehlt es sich, zunächst eine Lastspitze von 10 bis 20 schnell aufeinanderfolgenden Anfragen zuzulassen, bevor die Ratenbegrenzung greift.

Mit NGINX Plus R17 können Sie nun einen Burst zulassen, um das typische Anfragemuster von Webbrowsern zu berücksichtigen, und anschließend weitere übermäßige Anfragen bis zu einem bestimmten Punkt verzögern, ab dem sie abgelehnt werden. Die zweistufige Anfrageratenbegrenzung wird mit dem neuen Parameter „delay“ für die Direktive „limit_req“ aktiviert.

Zur Veranschaulichung der zweistufigen Anforderungsbegrenzung konfigurieren wir NGINX Plus hier so, dass eine Website durch eine Begrenzung auf 5 Anfragen pro Sekunde geschützt wird (rate=5r/s). Die Website umfasst üblicherweise 4–6 Ressourcen pro Seite und nie mehr als 12 Ressourcen. Die Konfiguration lässt Spitzen von bis zu 12 Anfragen zu, wobei die ersten 8 ohne Verzögerung verarbeitet werden. Nach 8 überzähligen Anfragen wird eine Verzögerung eingeführt, um die Begrenzung auf 5 Anfragen/s durchzusetzen. Nach 12 überzähligen Anfragen werden alle weiteren Anfragen abgelehnt.

limit_req_zone $binary_remote_addr zone=ip:10m rate=5r/s;
server {
    listen 80;
    location / {
        limit_req zone=ip burst=12 delay=8;
        proxy_pass http://website;
    }
}

Der Parameter delay legt fest, ab welchem Punkt innerhalb der Burst-Größe übermäßige Anfragen gedrosselt (verzögert) werden, um die festgelegte Ratenbegrenzung einzuhalten. Bei dieser Konfiguration zeigt ein Client, der kontinuierlich 8 Anfragen pro Sekunde sendet, das folgende Verhalten.

Darstellung des Verhaltens der Anfrageratenbegrenzung mit rate=5r/s burst=12 delay=8

Die ersten 8 Anfragen (der Wert von delay) werden von NGINX Plus ohne Verzögerung weitergeleitet. Die nächsten 4 Anfragen (burst - delay) werden verzögert, damit die festgelegte Rate von 5 Anfragen/s nicht überschritten wird. Die nächsten 3 Anfragen werden abgelehnt, da die Gesamtgröße des Bursts überschritten wurde. Nachfolgende Anfragen werden verzögert.

Beachten Sie, dass diese Abbildung den Prozess vereinfacht darstellt, da sie die Auswirkungen abgeschlossener Anfragen auf die Berechnung der Anzahl der verarbeiteten überzähligen Anfragen außer Acht lässt. Tatsächlich gibt jede abgeschlossene Anfrage einen Platz in der Verzögerungswarteschlange frei, sodass eine weitere überzählige Anfrage innerhalb der konfigurierten Burst-Größe aufgenommen werden kann. Weitere Informationen zur Implementierung der Anfrageratenbegrenzung finden Sie im Beitrag „Anfrageratenbegrenzung mit NGINX und NGINX Plus“ in unserem Blog.

Einfachere OpenID-Connect-Konfiguration

Bei der JWT-Validierung kann NGINX Plus R17 jetzt so konfiguriert werden, dass der Satz von JSON Web Keys (JWKs) von dem entfernten Speicherort abgerufen wird, der durch die neue Direktive auth_jwt_key_request angegeben wird. Dabei handelt es sich in der Regel um einen Identitätsanbieter (Identity Provider, IdP). Der automatische Abruf ist besonders praktisch bei der Integration mit einem IdP, der seine Schlüssel häufig wechselt.

Die meisten IdPs stellen eine feste URL bereit, über die der aktuelle Schlüsselsatz abgerufen werden kann, insbesondere wenn sie OpenID Connect Discovery unterstützen. In diesem Fall wird die URL für die Schlüssel durch den Wert jwks_uri definiert.

# Create a directory to cache the keys received from IdPproxy_cache_path /var/cache/nginx/jwk levels=1 keys_zone=jwk:1m max_size=10m;

server {
    listen 80; # Use SSL/TLS in production

    location / {
        auth_jwt "closed site";
        auth_jwt_key_request /_jwks_uri; # Keys will be fetched by subrequest

        proxy_pass http://my_backend;
    }

    location = /_jwks_uri {
        internal;
        proxy_cache jwk; # Cache responses
        proxy_pass https://idp.example.com/oauth2/keys; # Obtain keys from here
    }
}

Mit zusätzlichen Caching-Direktiven können die vom Subrequest zurückgegebenen Header Expires und Cache-Control überschrieben werden. Durch die Verwendung von proxy_cache_use_stale kann NGINX Plus weiterhin zwischengespeicherte Schlüssel verwenden, wenn die Schlüssel-URL nicht verfügbar ist.

Unsere OpenID-Connect-Referenzimplementierung wurde aktualisiert und unterstützt nun auth_jwt_key_request sowie die automatische Konfiguration für IdPs, die OpenID Connect Discovery unterstützen.

Die JWT-Unterstützung wurde außerdem um zwei Varianten des Edwards-Kurven-Algorithmus für digitale Signaturen (EdDSA) erweitert: Ed448 und Ed25519. Beachten Sie, dass EdDSA OpenSSL 1.1.1 oder höher erfordert, das zum Zeitpunkt der Erstellung dieses Textes nur in Ubuntu 18.10 und FreeBSD 12.0 verfügbar ist.

Hinweis: OpenID-Connect-Unterstützung ist ausschließlich in NGINX Plus verfügbar.

Doppelt so schnelle NGINX ModSecurity WAF

Das NGINX ModSecurity WAF-Modul für NGINX Plus ist unsere unterstützte Version der Open-Source-Web Application Firewall (WAF) ModSecurity, die von über einer Million Websites eingesetzt wird. Wir arbeiten aktiv mit dem TrustWave-SpiderLabs-Team zusammen, um die Leistung von ModSecurity mit NGINX Plus zu verbessern, und freuen uns, berichten zu können, dass die neueste Version doppelt so leistungsfähig ist wie frühere Versionen.

Die NGINX WAF schützt vor Angriffen auf Layer 7

Diese Version unterstützt außerdem pdateActionById, ctl:requestBodyProcessor=URLENCODED sowie die Aktion setenv.

Der neue NGINX ModSecurity WAF-Build basiert auf ModSecurity 3.0.3. Weitere Informationen finden Sie im TrustWave SpiderLabs-Blog.

Hinweis: NGINX ModSecurity WAF ist ausschließlich für NGINX Plus verfügbar.

Weitere neue Funktionen in NGINX Plus R17

TCP-Keepalives zu Upstream-Servern

Die neue proxy_socket_keepalive-Direktive steuert, ob TCP-Keepalives zwischen NGINX Plus und dem Proxy-Server aktiviert werden. TCP-Keepalives verbessern die Leistung von Protokollen (wie WebSocket), wenn sich zwischen NGINX und dem Proxy-Server ein zustandsbehaftetes TCP-Netzwerkgerät befindet und die Verbindungen langlebig und häufig inaktiv sind. Ohne TCP-Keepalives schließen solche Geräte inaktive TCP-Verbindungen möglicherweise häufiger, wodurch der zusätzliche Aufwand entsteht, sie von Grund auf neu aufzubauen.

Die Direktive ist auch in den Modulen FastCGI, gRPC, memcached, SCGI und uwsgi verfügbar.

Zeitüberschreitung und Anfragelimit für HTTP-Keepalive-Verbindungen zu Upstream-Servern

Die neue keepalive_timeout-Direktive legt fest, wie lange eine HTTP-Keepalive-Verbindung zwischen NGINX Plus und dem Proxy-Server maximal inaktiv bleiben darf, bevor sie geschlossen wird. Darüber hinaus legt die keepalive_requests-Direktive fest, wie viele Anfragen maximal über eine Keepalive-Verbindung gesendet werden können (danach wird sie geschlossen und eine neue Verbindung hergestellt).

Begrenzte Größe von Upstream-UDP-Sitzungen

Die neue proxy_requests-Direktive (Stream-Modul) legt die maximale Anzahl von UDP-Paketen fest, die von NGINX Plus an den Proxy-Server gesendet werden, bevor eine neue UDP-„Sitzung“ erstellt wird. Dies ermöglicht eine gleichmäßigere Lastverteilung der UDP-Pakete, wenn ein einzelner Client innerhalb kurzer Zeit eine große Anzahl von UDP-Paketen sendet (was beispielsweise bei einem nachgelagerten Proxy vorkommen kann).

Verbesserung der gemeinsamen Nutzung des Clusterstatus

Bei der Verwendung der Statusfreigabe in einem Cluster können Sie nun den Servernamen überprüfen, wobei der Servername beim Herstellen einer Verbindung zu Clusterknoten über SNI übermittelt wird. Dies wird mit den Direktiven zone_sync_ssl_name und zone_sync_ssl_server_name umgesetzt.

Hinweis: Clustering und das zone_sync-Modul sind ausschließlich in NGINX Plus verfügbar

Aktualisierungen im NGINX Plus-Ökosystem

Verbesserungen am Ingress Controller

Der offizielle NGINX Ingress Controller für Kubernetes wurde auf Version 1.4.0 aktualisiert. Im Änderungsprotokoll sind alle Änderungen, Fehlerbehebungen und Verbesserungen aufgeführt. Die wichtigsten davon werden in unserem Blog vorgestellt:

Erweiterte Prometheus-Unterstützung
TCP/UDP-Lastverteilung
Der Lastverteilungsalgorithmus „Random with Two Choices“ ist jetzt der Standard
Benutzerdefinierte Annotationen

Erfahren Sie mehr über den offiziellen NGINX Ingress Controller für Kubernetes auf unserer Website und im GitHub-Repository.

Verbesserungen am JavaScript-Modul

NGINX Plus R17 enthält eine Reihe von Verbesserungen, die den Umfang der Unterstützung für die JavaScript-Sprache erweitern:

arguments-Objekte
Nicht ganzzahlige Brüche
Zusätzliche Methoden zur Zeitmessung: console.time() und console.timeEnd()
Variablen und Funktionen können jetzt erneut deklariert werden

Die Integration mit dem NGINX-Stream-Modul für TCP/UDP-Anwendungen wurde überarbeitet und verwendet nun verschiedene Rückgabefunktionen, darunter eine send()-Methode zum Ändern des eingehenden Datenverkehrs. Der ausgehende Datenverkehr ist jetzt über eine Callback-Funktion verfügbar.

Eine vollständige Liste der Änderungen finden Sie im Änderungsprotokoll des NGINX JavaScript-Moduls.

NGINX Plus aktualisieren oder testen

NGINX Plus R17 unterstützt TLS 1.3, das sicherer und leistungsfähiger als TLS 1.2 ist. Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 17 und TLS 1.3 zu aktualisieren. Dadurch erhalten Sie außerdem eine Reihe zusätzlicher Fehlerbehebungen und Verbesserungen und erleichtern NGINX, Inc. die Unterstützung, wenn Sie ein Support-Ticket erstellen müssen.

Bitte lesen Sie sich die neuen Funktionen und Verhaltensänderungen in diesem Blogbeitrag sorgfältig durch, bevor Sie mit dem Upgrade fortfahren.

Wenn Sie NGINX Plus oder die NGINX ModSecurity WAF noch nicht ausprobiert haben, empfehlen wir Ihnen, sie zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Starten Sie noch heute kostenlos mit einer kostenlosen 30‑Tage-Testversion. Überzeugen Sie sich selbst davon, wie NGINX Plus Sie bei der Bereitstellung und Skalierung Ihrer Anwendungen unterstützen kann.

[Redaktion – Der Verkauf von NGINX ModSecurity WAF wurde zum 1. April 2022 offiziell eingestellt. Zum 31. März 2024 erreicht das Produkt das Ende seines Lebenszyklus. Weitere Informationen finden Sie im Beitrag F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> in unserem Blog.]