Schutz von NGINX und NGINX Plus vor dem POODLE-Angriff auf SSLv3 (CVE-2014-3566)

Eine kürzlich gemeldete Sicherheitslücke in Version 3 des SSL-Protokolls (SSLv3) kann in einem Man-in-the-Middle- Angriff ausgenutzt werden, um Teile einer mit HTTPS verschlüsselten Klartextübertragung zu extrahieren. Google-Forscher haben eine detaillierte Erklärung veröffentlicht, in der beschrieben wird, wie ein solcher Angriff durchgeführt werden könnte.

Dies ist keine Sicherheitslücke in irgendeiner Implementierung von SSL/TLS, sondern vielmehr eine Sicherheitslücke im Design des SSLv3-Protokolls bei der Verwendung von Blockchiffren. Da alle alternativen Stromchiffren auch Schwächen aufweisen, besteht die einzige Maßnahme darin, SSLv3 in Ihren NGINX- und NGINX Plus-Konfigurationen zu deaktivieren.

Deaktivieren von SSLv3 in NGINX

SSLv3 ist in NGINX und NGINX Plus standardmäßig aktiviert und wird möglicherweise von HTTP- und E-Mail-Diensten verwendet.

[Editor – Proxy und Lastausgleich des TCP-Verkehrs wurden zum Zeitpunkt der ursprünglichen Veröffentlichung dieses Artikels nicht vollständig unterstützt. Der Vollständigkeit halber wurden die folgenden Schritte aktualisiert, um den Schutz des TCP-Verkehrs einzuschließen.]

Führen Sie diese Schritte auf allen NGINX- und NGINX Plus-Instanzen aus:

1. Eliminieren Sie SSLv3 aus dem Satz der für den HTTP-Verkehr verwendeten Protokolle. Fügen Sie dem http{}- Block die folgende ssl_protocols -Direktive hinzu, falls sie nicht vorhanden ist, oder bearbeiten Sie die vorhandene Direktive, um SSLv3 aus der Parameterliste zu entfernen.

   # in der http{}-Konfiguration blocksl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 weglassen wegen POODLE (CVE‑2014‑3566)

2. Erstellen oder bearbeiten Sie dieselbe Anweisung im Konfigurationsblock „mail{}“ , wenn Ihre NGINX- oder NGINX Plus-Instanzen E-Mail-Verkehr verarbeiten.

   # in der mail{}-Konfiguration blocksl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 weglassen wegen POODLE (CVE‑2014‑3566)

3. Erstellen oder bearbeiten Sie dieselbe Anweisung im Konfigurationsblock „stream{}“ , wenn Ihre NGINX- oder NGINX Plus-Instanzen TCP-Verkehr verarbeiten.

   # in der stream{}-Konfiguration blocksl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 weglassen wegen POODLE (CVE‑2014‑3566)

4. Suchen Sie alle anderen Instanzen der Direktive ssl_protocols in Ihrer Konfiguration (sie kann in einem Server{} -Konfigurationsblock innerhalb der Blöcke http{} , mail{} und stream{} enthalten sein). Wir empfehlen, diese SSL_Protocols -Direktiven zu entfernen, aber zumindest SSLv3 aus der Parameterliste zu entfernen:

   # in jedem Server{}-Block SSL-Protokolle TLSv1 TLSv1.1 TLSv1.2;# SSLv3 wegen POODLE (CVE-2014-3566) weglassen

5. Führen Sie den folgenden Befehl aus, um die Konfiguration neu zu laden:

   # nginx –s neu laden

Welche Auswirkungen hat diese Änderung?

Alle modernen Browser und API-Clients unterstützen TLSv1 und höher. Das Deaktivieren von SSLv3 wird für Windows XP-Benutzer, die Internet Explorer 6 verwenden, zu Unannehmlichkeiten führen. CloudFlare schätzt, dass 1,12 % der Windows XP-Benutzer (die 3,12 % ihres Datenverkehrs ausmachen) davon betroffen sein werden – dies entspricht etwa 1 von 3000 Benutzern.

Die Änderung kann sich auch auf Webcrawler und anderen automatisierten Bot-Verkehr auswirken.

Die Zukunft

Bei einem SSL-Downgrade-Angriff kann der Angreifer SSL/TLS-Handshakes stören und Client und Server dazu veranlassen, eine frühere Version von SSL/TLS auszuwählen. Wenn es verwendet wird, um die Auswahl von SSLv3 zu erzwingen, kann es die SSL/TLS-Verbindung für den POODLE-Angriff anfällig machen. Das Deaktivieren von SSLv3 auf dem Server macht diesen Angriff unmöglich.

Google hat eine Erweiterung für SSL/TLS mit dem Namen TLS_FALLBACK_SCSV vorgeschlagen, die erzwungene Herabstufungen von SSL/TLS verhindern soll. [Anm.: Die Erweiterung wurde im April 2015 als RFC 7507 angenommen.] Diese Erweiterung könnte irgendwann in OpenSSL aufgenommen und die entsprechende clientseitige Unterstützung den wichtigsten Browsern hinzugefügt werden. Dadurch können Webdienste SSLv3 unterstützen, ältere Clients sind jedoch weiterhin anfällig.

Dennoch könnte diese Sicherheitslücke den letzten Nagel im Sarg für SSLv3 bedeuten – insgesamt eine einfachere und zuverlässigere Lösung.

Was kann ich sonst noch tun?

Wir empfehlen, Ihre Client-Software so zu aktualisieren, dass sie SSLv3 nicht unterstützt. Dies schützt Sie vor diesem Angriff, wenn Sie auf Dienste zugreifen, bei denen SSLv3 nicht deaktiviert wurde.

Weitere Informationen

• Der ursprüngliche Schwachstellenbericht
• Eine prägnantere Erklärung von ImperialViolet
• Mehrere Hersteller haben Empfehlungen veröffentlicht; die von Ubuntu sind besonders umfassend