SSL/TLS-Offloading, Verschlüsselung und Zertifikate mit NGINX und NGINX Plus

NGINX und NGINX Plus bieten zahlreiche Funktionen, mit denen die meisten SSL/TLS-Anforderungen erfüllt werden können. Sie nutzen OpenSSL und die Leistung von Standardprozessorchips, um eine kostengünstige SSL/TLS-Leistung bereitzustellen. Da die Leistungsfähigkeit von Standardprozessorchips ständig zunimmt und Chiphersteller Unterstützung für kryptografische Beschleunigung hinzufügen, wird auch der Kostenvorteil von Standardprozessorchips gegenüber spezialisierten SSL/TLS-Chips immer größer.

Es gibt drei Hauptanwendungsfälle für NGINX und NGINX Plus mit SSL/TLS.

SSL/TLS-Offloading

Wenn NGINX als Proxy verwendet wird, kann es die Backend-Server von der Verarbeitung der SSL-Entschlüsselung entlasten. Die Entschlüsselung über den Proxy bietet zahlreiche Vorteile:

• Verbesserte Leistung – Der größte Leistungseinbruch bei der SSL-Entschlüsselung ist der anfängliche Handshake. Um die Leistung zu verbessern, speichert der Server, der die Entschlüsselung durchführt, SSL-Sitzungs-IDs im Cache und verwaltet TLS-Sitzungstickets. Wenn dies beim Proxy erfolgt, können alle Anfragen desselben Clients die zwischengespeicherten Werte verwenden. Wenn dies auf den Backend-Servern erfolgt, muss sich der Client jedes Mal erneut authentifizieren, wenn seine Anfragen an einen anderen Server gehen. Die Verwendung von TLS-Tickets kann zur Minderung dieses Problems beitragen, sie werden jedoch nicht von allen Clients unterstützt und können schwierig zu konfigurieren und zu verwalten sein.
• Bessere Auslastung der Backend-Server – Die SSL/TLS-Verarbeitung ist sehr CPU-intensiv und wird mit zunehmender Schlüsselgröße noch intensiver. Durch die Entlastung der Backend-Server von dieser Arbeit können sie sich auf das konzentrieren, was sie am effizientesten können: die Bereitstellung von Inhalten.
• Intelligentes Routing – Durch die Entschlüsselung des Datenverkehrs erhält der Proxy Zugriff auf den Inhalt der Anfrage, beispielsweise Header, URI usw., und kann diese Daten zum Weiterleiten der Anfragen verwenden.
• Zertifikatsverwaltung – Zertifikate müssen nur erworben und auf den Proxyservern installiert werden, nicht auf allen Backend-Servern. Das spart Zeit und Geld.
• Sicherheitspatches – Wenn im SSL/TLS-Stack Schwachstellen auftreten, müssen die entsprechenden Patches nur auf die Proxyserver angewendet werden.

Weitere Einzelheiten finden Sie unter „NGINX SSL-Terminierung“ im NGINX Plus-Administratorhandbuch.

SSL/TLS-Verschlüsselung für die Ursprungsserver

Manchmal muss NGINX möglicherweise den an Backend-Server gesendeten Datenverkehr verschlüsseln. Diese Anfragen können beim NGINX-Server als Klartext oder als verschlüsselter Datenverkehr ankommen, den NGINX entschlüsseln muss, um eine Routing-Entscheidung treffen zu können.  Die Verwendung eines Pools von Keepalive-Verbindungen zu den Backend-Servern minimiert die Anzahl der SSL/TLS-Handshakes und maximiert so die SSL/TLS-Leistung. Dies lässt sich ganz einfach erreichen, indem NGINX so konfiguriert wird, dass es als Proxy zu „https“ fungiert und so automatisch den Datenverkehr verschlüsselt, der noch nicht verschlüsselt ist.

Ende-zu-Ende-Verschlüsselung

Da NGINX sowohl Entschlüsselung als auch Verschlüsselung durchführen kann, können Sie eine End-to-End-Verschlüsselung aller Anfragen erreichen, wobei NGINX weiterhin die Layer-7-Routing-Entscheidungen trifft. In diesem Fall kommunizieren die Clients über HTTPS mit NGINX. Dieses entschlüsselt die Anfragen und verschlüsselt sie dann erneut, bevor sie an die Backend-Server gesendet werden. Dies kann wünschenswert sein, wenn der Proxyserver nicht zusammen mit den Backend-Servern in einem Rechenzentrum untergebracht ist. Da immer mehr Server in die Cloud verschoben werden, wird die Verwendung von HTTPS zwischen einem Proxy und Backend-Servern immer notwendiger.

Client-Zertifikate

NGINX kann SSL/TLS-Clientzertifikate verarbeiten und kann so konfiguriert werden, dass sie optional oder erforderlich sind . Mithilfe von Client-Zertifikaten können Sie den Zugriff auf Ihre Systeme auf ausschließlich vorab genehmigte Clients beschränken, ohne dass ein Kennwort erforderlich ist. Außerdem können Sie die Zertifikate steuern, indem Sie widerrufene Zertifikate einer Zertifikatssperrliste (Certificate Revocation List , CRL) hinzufügen. Diese Liste wird von NGINX überprüft, um zu ermitteln, ob ein Client-Zertifikat noch gültig ist.

Zusätzliche Sicherheitsfunktionen

Es gibt eine Reihe weiterer Funktionen, die diese Anwendungsfälle unterstützen, einschließlich (jedoch nicht beschränkt auf) die Folgenden:

• Mehrere Zertifikate – Eine einzelne NGINX-Instanz kann viele Zertifikate für verschiedene Domänen unterstützen und lässt sich auf Hunderttausende von Zertifikaten skalieren. Ein häufiger Anwendungsfall ist eine NGINX-Instanz, die viele IP-Adressen und Domänen bedient, wobei jede Domäne ein eigenes Zertifikat benötigt.
• OCSP-Stapling – Wenn dies aktiviert ist, schließt NGINX eine mit Zeitstempel versehene, von der Zertifizierungsstelle signierte OCSP-Antwort ein, die der Client zum Überprüfen des Serverzertifikats verwenden kann. Dadurch werden Leistungseinbußen vermieden, die durch eine direkte Kontaktaufnahme mit dem OCSP-Server entstehen.
• SSL/TLS-Chiffren – Sie können angeben, welche Chiffren aktiviert werden.
• SSL/TLS-Protokolle – Sie können angeben, welche Protokolle aktiviert sind, einschließlich SSLv2, SSLv3, TLSv1, TLSv1.1 und TLSv1.2.
• Verkettete Zertifikate – NGINX unterstützt Zertifikatsketten , die verwendet werden, wenn das Zertifikat der Website nicht direkt vom Stammzertifikat einer Zertifizierungsstelle (CA, Certification Authority) signiert ist, sondern von einer Reihe von Zwischenzertifikaten. Der Webserver präsentiert eine „Zertifikatskette“, die die Zwischenzertifikate enthält, sodass der Webclient die Vertrauenskette überprüfen kann, die das Website-Zertifikat mit einem vertrauenswürdigen Stammzertifikat verknüpft.
• HTTPS-Serveroptimierungen – Die SSL/TLS-Leistung von NGINX lässt sich durch Konfigurieren der Anzahl von Arbeitsprozessen, Verwenden von Keepalive-Verbindungen und Verwenden eines SSL/TLS-Sitzungscache maximieren.

Weitere Einzelheiten finden Sie in diesen Ressourcen:

• NGINX SSL-Terminierung im NGINX Plus-Administratorhandbuch
• Konfigurieren von HTTPS-Servern bei nginx.org
• Referenzdokumentation zu ngx_http_ssl_module unter nginx.org

Beispiele

Hier sind einige Beispiele für die Sicherheitsfunktionen von NGINX. Diese Beispiele setzen ein grundlegendes Verständnis der NGINX-Konfiguration voraus.

Die folgende Konfiguration verarbeitet den HTTP-Verkehr für www.example.com und leitet ihn an eine Upstream-Gruppe weiter:

Upstream-Backends {
Server 192.168.100.100:80;
Server 192.168.100.101:80;
}

Server {
Listen 80;
Servername www.example.com;

Standort / {
Proxy-Passwort http://backends;
}
}

Fügen Sie nun HTTPS-Unterstützung hinzu, damit NGINX den Datenverkehr mithilfe des Zertifikats und des privaten Schlüssels entschlüsselt und über HTTP mit den Backend-Servern kommuniziert:

Upstream-Backends { Server 192.168.100.100:80; Server 192.168.100.101:80; } Server { Listen 80; Listen 443 SSL ; # Der Parameter „SSL“ weist NGINX an, den Datenverkehr zu entschlüsseln. Servername www.example.com; SSL-Zertifikat www.example.com.crt ; # Die Zertifikatsdatei SSL-Zertifikatschlüssel www.example.com.key ; # Der Speicherort der privaten Schlüsseldatei / { Proxy-Passwort http://backends; } }

Oder wenn Sie stattdessen Datenverkehr über HTTP empfangen und ihn über HTTPS an die Backend-Server senden:

Upstream-Backends { Server 192.168.100.100:443; Server 192.168.100.101:443; } Server { Listen 80; Servername www.example.com; Standort / { Proxy-Passwort https ://backends; # Das Präfix „https“ weist NGINX an, den Datenverkehr zu verschlüsseln. } }

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.