☰

Entfernen von SSLv3-spezifischen CBC-Chiffren

tag-icon • tag-icon ssl openssl
Entfernen von SSLv3-spezifischen CBC-Chiffren

Ich muss SSLv3-spezifische CBC-Chiffren als vorübergehende Lösung für die POODLE-Sicherheitslücke deaktivieren, da es Legacy-Anwendungen gibt, die SSLv3 verwenden müssen. Nach Durchsicht der OPENSSL-Dokumente scheint es gemeinsame Chiffren zwischen SSLv3 und TLSV1 zu geben, wie zum Beispiel:

  • SSL_DHE_RSA_WITH_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA
  • TLS_DHE_RSA_MIT_DES_CBC_SHA
  • DHE-RSA-DES-CBC-SHA

Meine Frage ist, gibt es eine Möglichkeit, beispielsweise zu deaktivieren,DHE-RSA-DES-CBC-SHAspeziell für SSLv3 und wird diese Aktion Auswirkungen auf TLSv1 haben?

Ich verwende nginx, Varnish und Apache mit OPENSSL

Antwort1

Diese Konfiguration sollte auf Ihrem Webserver vorgenommen werden. OpenSSL erlaubt Ihnen nur die programmgesteuerte Angabe von Chiffren, wie in diesemSE-Antwort.

Da Sie sagten, dass Sie Apache und Nginx verwenden (der Webcache Varnish unterstützt kein SSL), habe ich diese Seiten gefunden, die sich mit demselben Thema befassen, obwohl sie sich an BEAST richten:

  1. Konfigurieren von Apache-Nginx und OpenSSL
  2. Härten der OpenSSL-Chiffre-Suiten Ihres Webservers

Hier geht es um dieSSL-TerminierungDadurch kann Varnish Ihren Inhalt zwischenspeichern:


Sehr wichtiges PS:

PS1 - Nicht vergessenHSTS
PS2 - Setzen Sie bei Cookies, die innerhalb verschlüsselter Verbindungen generiert werden, immer das Flag „Sicher“. Wenn Sie dies vergessen, können Angreifer ganz leicht Informationen verlieren.

Antwort2

Die kanonische Antwort isthttps://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerabilityund zieht es vor, auszuschließenProtokollSSLv3, keine Chiffren.

Vorläufig verwenden die beiden unterschiedlichen Ciphersuites, die Sie nennen, das ursprüngliche DES, retronymisiertEinzel-DESund sindunsicher in ALLEN Protokollversionen. Das ursprüngliche DES wurde vor einem Jahrzehnt ersetzt und zurückgezogen. (Genauer gesagt wurde FIPS46-3 2001 durch FIPS197 AES ersetzt, dann 2005 zurückgezogen, und nur Triple-DEA, NICHT Single-DEA, wurde 2004 als genehmigt, aber nicht als Standard, als SP800-67 neu veröffentlicht.) Sie werden in der Verschlüsselungskonfiguration von OpenSSL als LOW klassifiziert und sollten zusammen mit EXPORT (noch weniger sicher) und eNULL (völlig unsicher)niemalskonfiguriert werden, es sei denn, Sie haben es mit einem ernsthaft veralteten System zu tun, das nicht aktualisiert, ersetzt oder mit einem Front-End ausgestattet werden kann, wie beispielsweise einer der älteren Marslander.

Zu Ihrer Frage: Es gibt keine wirklich SSLv3-spezifischen CBC-Chiffren, obwohl es einige gibtnicht-SSLv3-Versionen. In OpenSSL ist die Konfiguration der zulässigen Cipher Suites und Protokolle getrennt und nahezu unabhängig. Soweit ich weiß, sind die einzigen Einschränkungen, dass Chiffren, die neue TLSv1.2-Funktionen verwenden (authentifizierte Verschlüsselung GCM oder SHA-2-Hashes), in keinem älteren Protokoll ausgewählt werden können und dass einige Chiffren, die in SSLv2 verwendet werden, denen aber keine SSLv3+-Codes zugewiesen wurden, weil sie bereits 1996 unsicher waren, in SSL3+ nicht verwendet werden können. Sogarnach Standards, die einzigen Unterschiede für Chiffrenzwischen SSL3 und TLS1 oder 1.1 sind:

  • die 40-Bit EXPORT-Chiffren wurden offiziell mit 1.1 gelöscht -- aber OpenSSL unterstützt sie trotzdem noch in 1.1 und 1.2 als Erweiterung. Aber sie waren und sind unsicher und Sie sollten sie nicht verwenden, es sei denn, Sie reisen in die 1990er Jahre zurück und unterliegen den rechtlichen Beschränkungen inmancheOrte dann.

  • Der Fortezza-Schlüsselaustausch, der zur Beschwichtigung der US-Regierung während der „Krypto ist eine Waffe“-Periode hinzugefügt wurde und von niemandem außer vielleicht der NSA verwendet wurde, wurde von TLS1 gelöscht. Er wird von OpenSSL nicht implementiert inbeliebigProtokoll.

  • die erste Charge von ECC-Chiffren inhttps://www.rfc-editor.org/rfc/rfc4492gelten offiziell nur für TLS1+, da sie auf Erweiterungen im ClientHello undhttps://www.rfc-editor.org/rfc/rfc3546für Erweiterungen konnte SSL3 nicht ändern, aber openssl >=1.0.0 (oder eine 0.9.8, wenn optimiert) implementiert sie in SSL3, indem es die Erweiterungen als standardmäßig „keine Einschränkung“ behandelt – aber nur, wenn der Peer zustimmt, was Peers, die nicht absichtlich das aktuelle openssl manipuliert haben, wahrscheinlich nicht tun werden. Dies ist dieeinziger möglicherweise nützlicher Chiffreunterschied.Unter der Annahme eines RSA-Zertifikats und privaten Schlüssels könnten Sie ECDHE-RSA verwenden und hoffen, dass es nur auf TLS1+ funktioniert.

Aus diesem Grund openssl ciphers -v [$cipherstring]zeigt das Befehlszeilenprogramm für die meisten Chiffren SSLv3 als „Version“ an; es bedeutet SSLv3 UND HÖHER.

Kurz zusammengefasst:WENN Ihre SSL3-only-Clients keine ECC-Chiffren aushandeln (und die meisten sehr alten Clients tun dies wahrscheinlich nicht, obwohl manipulierte neuere dies möglicherweise tun) UND ALLE Ihre TLS1+-ClientsTUN(was viel weniger sicher ist) und unter der Annahme des üblichen Falls eines RSA-Zertifikats und eines privaten Schlüssels könnten Sie ECDHE-RSA-(3DES oder AES)-CBC aktivieren, aber DHE-RSA-anything-CBC und RSA-anything-CBC deaktivieren. Dadurch erhalten Sie auch Perfect Forward Secrecy.

Wenn Sie möchten, können Sie RC4 auch für alle SSL3+ aktivieren, mit oder ohne PFS, aber auch hier gibt es Bedenken:

Sind Ihre „Legacy-Anwendungen“ Webanwendungen oder etwas anderes? Wenn Webanwendungen, können Sie keinen halbwegs anständigen Browser bekommen? Wenn eine benutzerdefinierte App nicht dazu gebracht werden kann, immer wieder dieselben vertraulichen Daten NACH den Angreiferdaten erneut zu senden, ist sie von vornherein nicht „angreifbar“.

verwandte Informationen