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

Rick NelsonRegional Vice President, Solution Engineering

NGINX und NGINX Plus bieten zahlreiche Funktionen, mit denen sich die meisten SSL/TLS-Anforderungen erfüllen lassen. Sie nutzen OpenSSL und die Leistungsfähigkeit von Standardprozessoren, um eine kosteneffiziente SSL/TLS-Performance zu erzielen. Da die Leistungsfähigkeit von Standardprozessoren kontinuierlich steigt und Chiphersteller zunehmend Unterstützung für kryptografische Beschleunigung integrieren, wächst auch der Kostenvorteil von Standardprozessoren gegenüber spezialisierten SSL/TLS-Chips weiter.

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

SSL/TLS-Auslagerung

Wenn NGINX als Proxy eingesetzt wird, kann es die SSL-Entschlüsselung von den Backend-Servern übernehmen. Die Entschlüsselung auf dem Proxy bietet eine Reihe von Vorteilen:

• Verbesserte Leistung – Die größte Leistungseinbuße bei der SSL-Entschlüsselung entsteht beim anfänglichen Handshake. Um die Leistung zu verbessern, speichert der entschlüsselnde Server SSL-Sitzungs-IDs zwischen und verwaltet TLS-Sitzungstickets. Erfolgt dies auf dem Proxy, können alle Anfragen desselben Clients die zwischengespeicherten Werte verwenden. Erfolgt dies hingegen auf den Backend-Servern, muss sich der Client jedes Mal erneut authentifizieren, wenn seine Anfragen an einen anderen Server weitergeleitet werden. TLS-Tickets können dieses Problem zwar abmildern, 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 rechenintensiv und wird mit zunehmender Schlüssellänge noch aufwendiger. Wenn diese Aufgabe von den Backend-Servern übernommen wird, können sie sich auf das konzentrieren, was sie am effizientesten leisten: die Bereitstellung von Inhalten.
• Intelligentes Routing – Durch die Entschlüsselung des Datenverkehrs erhält der Proxy Zugriff auf die Inhalte der Anfrage, wie etwa Header, URI usw., und kann diese Daten zum Weiterleiten von Anfragen verwenden.
• Zertifikatsverwaltung – Zertifikate müssen nur für die Proxyserver erworben und auf diesen installiert werden, nicht auf allen Backend-Servern. Das spart sowohl Zeit als auch Geld.
• Sicherheitspatches – Wenn Schwachstellen im SSL/TLS-Stack auftreten, müssen die entsprechenden Patches nur auf den Proxyservern installiert werden.

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

SSL/TLS-Verschlüsselung zu den Ursprungsservern

In manchen Fällen muss NGINX den Datenverkehr verschlüsseln, den es an Backend-Server sendet. Diese Anfragen können den NGINX-Server entweder als Klartext oder als verschlüsselter Datenverkehr erreichen, den NGINX entschlüsseln muss, um eine Routing-Entscheidung treffen zu können. Durch die Verwendung eines Pools von Keepalive-Verbindungen zu den Backend-Servern wird die Anzahl der SSL/TLS-Handshakes minimiert und somit die SSL/TLS-Leistung maximiert. Dies lässt sich ganz einfach erreichen, indem NGINX so konfiguriert wird, dass Anfragen über „https“ weitergeleitet werden. Dadurch wird noch nicht verschlüsselter Datenverkehr automatisch verschlüsselt.

Ende-zu-Ende-Verschlüsselung

Da NGINX sowohl entschlüsseln als auch verschlüsseln kann, lässt sich eine Ende-zu-Ende-Verschlüsselung aller Anfragen erreichen, während NGINX weiterhin Routing-Entscheidungen auf Layer 7 trifft. In diesem Fall kommunizieren die Clients über HTTPS mit NGINX. NGINX entschlüsselt die Anfragen und verschlüsselt sie erneut, bevor sie an die Backend-Server weitergeleitet werden. Dies kann sinnvoll sein, wenn sich der Proxyserver nicht im selben Rechenzentrum wie die Backend-Server befindet. Da immer mehr Server in die Cloud verlagert werden, wird die Verwendung von HTTPS zwischen einem Proxy und den Backend-Servern zunehmend erforderlich.

Client-Zertifikate

NGINX kann mit SSL/TLS-Clientzertifikaten umgehen und so konfiguriert werden, dass diese optional oder erforderlich sind. Clientzertifikate bieten die Möglichkeit, den Zugriff auf Ihre Systeme ohne Passwort auf vorab genehmigte Clients zu beschränken. Sie können die Zertifikate verwalten, indem Sie widerrufene Zertifikate einer Zertifikatsperrliste (CRL) hinzufügen, anhand derer NGINX prüft, ob ein Clientzertifikat noch gültig ist.

Zusätzliche Sicherheitsfunktionen

Es gibt eine Reihe weiterer Funktionen, die diese Anwendungsfälle unterstützen, darunter unter anderem die folgenden:

• Mehrere Zertifikate – Eine einzelne NGINX-Instanz kann zahlreiche Zertifikate für verschiedene Domains unterstützen und auf Hunderttausende von Zertifikaten skaliert werden. Ein typischer Anwendungsfall ist eine NGINX-Instanz, die viele IP-Adressen und Domains bedient, wobei jede Domain ein eigenes Zertifikat benötigt.
• OCSP-Stapling – Wenn diese Funktion aktiviert ist, fügt NGINX eine mit einem Zeitstempel versehene und von der Zertifizierungsstelle signierte OCSP-Antwort hinzu, anhand derer der Client das Zertifikat des Servers überprüfen kann. Dadurch werden die Leistungseinbußen vermieden, die durch eine direkte Kontaktaufnahme mit dem OCSP-Server entstehen.
• SSL/TLS-Verschlüsselungsverfahren – Sie können festlegen, welche Verschlüsselungsverfahren aktiviert sind.
• SSL/TLS-Protokolle – Sie können festlegen, welche Protokolle aktiviert sind, darunter SSLv2, SSLv3, TLSv1, TLSv1.1 und TLSv1.2.
• Zertifikatsketten – NGINX unterstützt Zertifikatsketten, die verwendet werden, wenn das Zertifikat der Website nicht direkt vom Stammzertifikat einer Zertifizierungsstelle (Certificate Authority, CA), sondern von einer Reihe von Zwischenzertifikaten signiert wurde. Der Webserver stellt eine „Zertifikatskette“ mit den Zwischenzertifikaten bereit, sodass der Webclient die Vertrauenskette überprüfen kann, die das Zertifikat der Website mit einem vertrauenswürdigen Stammzertifikat verbindet.
• HTTPS-Serveroptimierungen – NGINX kann durch die Konfiguration der Anzahl der Worker-Prozesse, die Verwendung von Keepalive-Verbindungen und den Einsatz eines SSL/TLS-Sitzungscaches auf maximale SSL/TLS-Leistung optimiert werden.

Weitere Einzelheiten finden Sie in diesen Ressourcen:

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

Beispiele

Hier finden Sie einige Beispiele für die Sicherheitsfunktionen von NGINX. Diese Beispiele setzen grundlegende Kenntnisse der NGINX-Konfiguration voraus.

Die folgende Konfiguration verarbeitet den HTTP-Datenverkehr 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;
    server_name www.example.com;

    location / {
        proxy_pass 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; # 'ssl' parameter tells NGINX to decrypt the traffic
    server_name         www.example.com;
    ssl_certificate www.example.com.crt; # The certificate file
    ssl_certificate_key www.example.com.key; # The private key file
  

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

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

upstream backends {
    server 192.168.100.100:443;
    server 192.168.100.101:443;
}

server {
    listen      80;
    server_name www.example.com;

    location / {
        proxy_pass https://backends; # 'https' prefix tells NGINX to encrypt the traffic
    }
}

Wenn Sie NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Rick NelsonRegional Vice President, Solution Engineering

Weitere Blogbeiträge von Rick Nelson