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

Owen GarrettSenior Director, Produktmanagement

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

Hierbei handelt es sich nicht um eine Schwachstelle in einer bestimmten SSL/TLS-Implementierung, sondern um eine Schwachstelle im Design des SSLv3-Protokolls bei der Verwendung von Blockchiffren. Da auch alle alternativen Stromchiffren Schwächen aufweisen, besteht die einzige Maßnahme darin, SSLv3 in Ihren NGINX- und NGINX Plus-Konfigurationen zu deaktivieren.

SSLv3 in NGINX deaktivieren

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

[Redaktion – Proxying und Lastverteilung von TCP-Datenverkehr wurden zum Zeitpunkt der ursprünglichen Veröffentlichung dieses Artikels noch nicht vollständig unterstützt. Der Vollständigkeit halber wurden die folgenden Schritte aktualisiert und umfassen nun auch den Schutz von TCP-Datenverkehr.]

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

1. Entfernen Sie SSLv3 aus den für HTTP-Datenverkehr verwendeten Protokollen. Fügen Sie die folgende ssl_protocols-Direktive zum http{}-Block hinzu, falls sie noch nicht vorhanden ist, oder bearbeiten Sie die vorhandene Direktive, um SSLv3 aus der Parameterliste zu entfernen.

# in the http{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Erstellen oder bearbeiten Sie dieselbe Direktive im Konfigurationsblock mail{}, wenn Ihre NGINX- oder NGINX Plus-Instanzen E-Mail-Datenverkehr verarbeiten.

# in the mail{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Erstellen oder bearbeiten Sie dieselbe Direktive im Konfigurationsblock stream{}, wenn Ihre NGINX- oder NGINX Plus-Instanzen TCP-Datenverkehr verarbeiten.

# in the stream{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Suchen Sie alle weiteren Vorkommen der ssl_protocols-Direktive 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. Entfernen Sie jedoch zumindest SSLv3 aus der Parameterliste:

# in every server{} block ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omit SSLv3 because of POODLE (CVE‑2014‑3566)

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

# nginx –s reload

Welche Auswirkungen hat diese Änderung?

Alle modernen Browser und API-Clients unterstützen TLSv1 und höher. Die Deaktivierung von SSLv3 führt zu Einschränkungen für WindowsXP-Nutzer, die mit Internet Explorer 6 surfen; CloudFlare schätzt, dass 1,12 % der WindowsXP-Nutzer (die 3,12 % des Datenverkehrs ausmachen) davon betroffen sein werden – dies entspricht etwa 1 von 3000 Nutzern.

Die Änderung könnte sich auch auf Webcrawler und anderen automatisierten Bot-Traffic auswirken.

Die Zukunft

Bei einem SSL-Downgrade-Angriff kann der Angreifer SSL/TLS-Handshakes stören und Client und Server dazu bringen, eine ältere Version von SSL/TLS auszuwählen. Wird dadurch die Auswahl von SSLv3 erzwungen, kann die SSL/TLS-Verbindung für den POODLE-Angriff anfällig werden. Durch die Deaktivierung von SSLv3 auf dem Server wird dieser 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. [Redaktion – Die Erweiterung wurde im April 2015 als RFC 7507 verabschiedet.] Diese Erweiterung könnte schließlich in OpenSSL aufgenommen und die entsprechende clientseitige Unterstützung in gängige Browser integriert werden. Dadurch können Webdienste SSLv3 unterstützen, ältere Clients bleiben jedoch weiterhin anfällig.

Dennoch könnte diese Sicherheitslücke das endgültige Aus für SSLv3 bedeuten – insgesamt eine einfachere und zuverlässigere Lösung.

Was kann ich sonst noch tun?

Wir empfehlen Ihnen, Ihre Clientsoftware zu aktualisieren, sodass sie SSLv3 nicht mehr unterstützt. Dadurch sind Sie vor diesem Angriff geschützt, wenn Sie auf Dienste zugreifen, die noch nicht aktualisiert wurden, um SSLv3 zu deaktivieren.

Weiterführende Informationen

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

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett