it-swarm.com.de

Welche SSL / TLS-Verschlüsselungssuiten sollten seit 2015 in einer Hochsicherheits-HTTPS-Umgebung verwendet werden?

Es ist ziemlich schwierig geworden, einen HTTPS-Dienst zu konfigurieren, der "die ideale Transportschicht" beibehält. Wie sollte ein HTTPS-Dienst so konfiguriert werden, dass ein angemessenes Maß an Kompatibilität möglich ist, ohne auch nur geringfügigen Angriffen ausgesetzt zu sein?

TLS-Downgrade-Angriffe in Kombination Beast, Crime, Breach und Poodle schlägt die meisten, wenn nicht alle SSLv3- und früheren Versionen aus. Microsoft deaktiviert SSLv3 standardmäßig , was für mich nach einem guten Schritt klingt. Aufgrund von Schwächen in RC4 , MD5 und SHA1 stehen noch weniger Chiffresuiten zur Auswahl.

Würde ein "idealer" HTTPS-Dienst nur TLS 1.0, 1.1 und 1.2 mit Schlüsselgrößenvarianten nach Chiffren aktivieren? Was sollte die am meisten bevorzugte Cipher Suite sein?

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
103
rook

Würde ein "idealer" HTTPS-Dienst nur TLS 1.0, 1.1 und 1.2 mit Schlüsselgrößenvarianten nach Chiffren aktivieren?

Nein, ein "idealer" HTTPS-Dienst würde nur TLS 1.2 und nur AEAD-basierte (Authenticated Encryption with Associated Data) -basierte Verschlüsselungssuiten mit SHA-2, 4096-Bit-DH-Parametern und 521-Bit-EC-Kurven eines Typs aktivieren, der Ihren Anforderungen entspricht (Regierung) genehmigt oder nicht von der Regierung generiert).

Dieser Dienst kann auch keine Verbindung herstellen, die von einer Vielzahl älterer Clients verwendet werden kann, einschließlich Android 4.3 und früher, IE 10 und früher, Java 7 (mindestens u25) und früher ), OpenSSL 0.9.8y und früher (OpenSSL 1.0.0 ist in meiner Quelle einfach nicht aufgeführt) und so weiter. Es wäre jedoch immun gegen jeden Angriff, der nur mit TLS 1.1 und darunter funktioniert, gegen jeden Angriff, der auf SHA-1 beruht, und gegen jeden Angriff, der auf dem CBC-Modus oder veralteten Chiffren wie RC4 beruht.

Einschränkungen der Client-Verschlüsselungssuite gemäß https://www.ssllabs.com .

Was sollte die am meisten bevorzugte Cipher Suite sein?

Es hängt davon ab, ob!

Ich gehe davon aus, dass Foward-Geheimhaltung eine Voraussetzung ist.

Ich gehe davon aus, dass "zu diesem Zeitpunkt für einigermaßen sicher gehalten wird" eine Voraussetzung ist.

Ich gehe davon aus, dass "tatsächlich von mindestens einem Hauptdarsteller implementiert" eine Voraussetzung ist.

Alle Anforderungen bezüglich müssen/können einige oder eine andere Teilmenge von Chiffren verwenden (müssen X verwenden, können Y nicht verwenden usw.).

Daher würde ich die folgenden Listen als vernünftigen Anfang vorschlagen. Beginnen Sie mit der obersten Kategorie (TLS 1.2 AEAD), gehen Sie die Liste weiter durch und fügen Sie Kategorien hinzu, bis Sie eine Stufe erreicht haben, die mit Ihrer Nutzerbasis funktioniert, oder das Ende Ihrer Komfortzone erreicht haben, je nachdem, was zuerst eintritt.

Schließen Sie so viele Chiffresuiten jeder Kategorie wie möglich ein, damit Sie beim nächsten Angriff die betroffenen Chiffresuiten entfernen und mit dem Rest fortfahren können.

Behalten Sie die Bedrohungsumgebung im Auge, damit Sie weiterhin Cipher Suites entfernen können, die Schwachstellen aufweisen.

Bitte bestellen oder sortieren Sie die Chiffresuiten innerhalb jeder Hauptkategorie nach Ihrem Geschmack: DHE ist natürlich langsamer als ECDHE, nimmt jedoch die Herkunft der elliptischen Kurven vollständig heraus und so weiter. Derzeit scheint die Bestellung ein Kompromiss zu sein. Wenn Sie jedoch Geschwindigkeit wünschen, bevorzugen oder benötigen Sie TLS_ECDHE_ *. Wenn Sie den derzeit häufig implementierten elliptischen Kurven nicht vertrauen oder aufgrund der NSA Suite B-Anleitung vom August 2015 Bedenken hinsichtlich elliptischer Kurven haben, die darauf hinweisen, dass eine Abkehr von früheren elliptischen Suite B-Kurven in Kürze bevorsteht future und sind bereit, CPU zu brennen, bevorzugen oder benötigen sogar TLS_DHE_ * -Suiten.

Beachten Sie, dass "normale" Zertifikate RSA-Zertifikate sind, die sowohl mit TLS_ECDHE_RSA_ * als auch mit TLS_DHE_RSA_ * Cipher Suites funktionieren. DSA-Zertifikate, die mit TLS_ECDHE_ECDSA_ * Cipher Suites funktionieren, sind bisher sehr selten und werden von vielen Zertifizierungsstellen nicht angeboten.

  • Nur TLS 1.2 AEAD (alle sind auch SHA-2)
    • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (neu 0xcca9, Pre-RFC7905 0xcc14)
    • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (neu 0xcca8, Pre-RFC7905 0xcc13)
    • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (neues 0xccaa, Pre-RFC7905 0xcc15)
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
      • Für US-Bürger, die an der NIST-Konformität interessiert sind, ist dies eine TLS 1.2 sollte Kategorie-Verschlüsselungssuite für Server, die private RSA-Schlüssel und RSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3 verwenden -3
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
      • Für US-Amerikaner, die an der NIST-Konformität interessiert sind, ist dies eine TLS 1.2 sollte Kategorie-Verschlüsselungssuite für Server, die private Schlüssel mit elliptischer Kurve und ECDSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle verwenden 3-5
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
      • Für US-Amerikaner, die an der NIST-Konformität interessiert sind, ist dies eine TLS 1.2 sollte Kategorie-Verschlüsselungssuite für Server, die private Schlüssel mit elliptischer Kurve und ECDSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle verwenden 3-5
    • Dies ist die höchste Sicherheitsstufe, die mir derzeit in gängigen TLS-Implementierungen bekannt ist.
    • Ab Januar 2017 behandeln große moderne Browser diese Stufe, einschließlich, aber nicht beschränkt auf Android mit 6.0, das AES-GCM unterstützt, und - allein von den wichtigsten - alten CHACHA20-POLY1305 und 7.0, die neues CHACHA20-POLY1305 unterstützen. Chrome mit AES-GCM und CHACHA20-POLY1305, Firefox mit AES-GCM und CHACHA20-POLY1305, IE und Edge nur mit AES-GCM, Java nur mit AES-GCM, OpenSSL 1.1.0 mit AES-GCM und CHACHA20-POLY1305, Safari nur mit AES-GCM).
    • Viele gängige Browser können dies nicht verarbeiten, selbst Vintage-Browser von 2015 (Safari 7 unter OSX 10.9, Android 4.3 und früher, IE 10 unter Win7 (IE 11 unterstützt sogar unter Win7 0x9f und 0x9e, wenn Windows verwendet wurde) gepatcht)
  • TLS 1.2 SHA2-Familie (nicht AEAD)
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
      • Für US-Bürger, die an der NIST-Konformität interessiert sind, ist dies eine TLS 1.2 sollte Kategorie-Verschlüsselungssuite für Server, die private RSA-Schlüssel und RSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3 verwenden -3
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
      • Für US-Amerikaner, die an der NIST-Konformität interessiert sind, ist dies eine Verschlüsselungssuite der Kategorie TLS 1.2 für Server, die private Schlüssel mit elliptischer Kurve und ECDSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3-5 verwenden
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
      • Für US-Amerikaner, die an der NIST-Konformität interessiert sind, ist dies eine TLS 1.2 sollte Kategorie-Verschlüsselungssuite für Server, die private Schlüssel mit elliptischer Kurve und ECDSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle verwenden 3-5
    • TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077)
    • TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076)
    • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0xc4)
    • Beachten Sie, dass Sie den AEAD-Modus verloren haben und den viel älteren CBC-Modus verwenden. das ist weniger als ideal. Der CBC-Modus hat in der Vergangenheit zu mehreren Angriffen beigetragen, darunter Lucky Thirteen und BEAST, und es ist nicht unangemessen zu glauben, dass der CBC-Modus auch mit zukünftigen Sicherheitslücken zusammenhängt.
    • Einige moderne Browser, die keine AEAD-Verschlüsselungssuiten haben, haben eine weitere, die für diese Kategorie besser geeignet ist. Beispielsweise kann IE 11 unter Win7 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 verwenden und Safari 6 und 7 können einige dieser
      • auch dies ist der Fall, wenn die GCM-Suiten ECDHE_ECDSA nicht funktionieren.
  • TLS 1.0 und 1.1 mit modernen Chiffren (und veralteten Hashes, da das alles ist, was verfügbar ist)
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
      • Für US-Bürger, die an der NIST-Konformität interessiert sind, ist dies eine Verschlüsselungssuite der Kategorie Mai für Server, die private RSA-Schlüssel und RSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3-2 verwenden
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
      • Für US-Leute, die an NIST-Konformität interessiert sind, ist dies eine Verschlüsselungssuite der Kategorie sollte für Server, die private RSA-Schlüssel und RSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3-2 verwenden
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
    • TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
    • TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    • Sobald Sie Cipher Suites ab dieser Ebene einbinden, werden Sie wahrscheinlich etwas finden, das mit fast allen modernen Implementierungen funktioniert.
    • Auf dieser Ebene verwenden Sie nicht nur den CBC-Modus, sondern auch SHA-1. NIST SP800-131A empfahl, SHA-1 nach dem 31. Dezember 2013 (heute vor einem Jahr) für die Erzeugung digitaler Signaturen nicht mehr zuzulassen.
  • TLS 1.0 und 1.1 mit älteren, aber immer noch vernünftigen Chiffren und veralteten Hashes
    • TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
    • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
      • Für US-Leute, die an NIST-Konformität interessiert sind, ist dies eine Verschlüsselungssuite der Kategorie sollte für Server, die private RSA-Schlüssel und RSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3-2 verwenden
    • TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
      • Für US-Leute, die an NIST-Konformität interessiert sind, ist dies eine Verschlüsselungssuite der Kategorie sollte für Server, die private Schlüssel mit elliptischer Kurve und ECDSA-Zertifikate gemäß NIST SP800-52 Revision 1 Tabelle 3 verwenden. 4
    • IE 8 unter Windows XP hat immer noch kein Glück, ebenso wie Java 6u45 aufgrund von DH-Parametermaxima.
    • Dies ist absolut das Mindestniveau, das ich empfehlen würde.
  • Beachten Sie, dass für Server mit privaten RSA-Schlüsseln und RSA-Zertifikaten, die NIST SP800-52 Revision 1 Compliance benötigen, Sie [~ # ~] [~ # ~] , sollte und kann bestimmte andere TLS_RSA_ * -Verschlüsselungssuiten implementieren, die KEINE Vorwärtsgeheimnis bieten. Daher würde ich dies nur empfehlen, wenn diese Konformität erforderlich ist.
    • Beachten Sie auch, dass in Abschnitt 3.3.1 dieses Dokuments spezifisch angegeben ist: "Der Server muss so konfiguriert sein, dass nur Verschlüsselungssuiten verwendet werden, die vollständig aus genehmigten Algorithmen bestehen. A. Eine vollständige Liste der zulässigen Chiffresuiten für den allgemeinen Gebrauch finden Sie in diesem Abschnitt ... "
  • Andere nationale und industrielle Anforderungen variieren natürlich.
    • und kann miteinander in Konflikt stehen; Lesen Sie alle für Sie zutreffenden sorgfältig durch.

Ich werde hier den üblichen Stecker einstecken - probieren Sie Ihre Verschlüsselungsliste mit Ihren eigenen Tools aus (openssl-Chiffren -v '...' für openssl-basierte Systeme), gehen Sie zu https://www.ssllabs.com/index .html Überprüfen Sie zuerst die von verschiedenen Clients unterstützten Cipher Suites, richten Sie dann Ihre Site ein und kehren Sie dann zu www.ssllabs.com zurück, um den Servertest auszuführen.

Beachten Sie, dass _ ECDSA _ Cipher Suites natürlich ECDSA-Zertifikate erfordern und diese immer noch sehr schwer zu finden sind.

ETA: NSA Suite B EC-Ratschläge und IE 11/Win7 unterstützen jetzt 0x9f und 0x9e.

ETA: Ab Januar 2016 ist NIST SP800-52r1 unverändert, und eine neue Verschlüsselungssuite (0xc00a) wurde der Liste hinzugefügt.

ETA: Ab Januar 2017 hat RFC7905 die drei TLS 1.2 AEAD CHACHA20-POLY1305-Chiffren geändert, und "moderne" Browser haben die AEAD-Unterstützung drastisch verbessert, wie in der neuen Aufzählung erwähnt. Aktuelle IANA-Verschlüsselungssuiten finden Sie unter https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 .

106

Normalerweise antworte ich nicht nur mit einem Link, aber da sich die Antworten auf diese Fragen so oft ändern, tue ich dies. Außerdem hängt die "ideale" Verschlüsselungssuite vollständig von der Anwendung und der Zielgruppe ab. Welche steuern Sie, welche Entscheidungen können Sie treffen und können Sie es sich leisten (z. B. müssen Sie IE6 unterstützen?), All dies beeinflusst die „ideale“ Antwort.

Wie auch immer, https://cipherli.st/ hat eine schöne Zusammenfassung von Chiffresuiten und Konfigurationsbeispielen für beliebte Anwendungen. Wie andere betonten, verfügt Qualys SSLLabs über ein nützliches Tool zum Testen Ihrer Konfiguration und einige nützliche Erklärungen.

13
Teun Vink

Ein guter Ausgangspunkt ist von Mozilla empfohlene TLS-Chiffren .

Eine gute Möglichkeit, die Sicherheit öffentlicher HTTPS-Websites zu testen, ist Qualys SSL Labs . Diese Website enthält auch viele Artikel zu TLS/SSL (mit Schwerpunkt auf HTTPS).

7
DavisNT

Update 2016 über SSL Labs:

Sie sollten sich hauptsächlich auf die AEAD-Suiten verlassen, die eine starke Authentifizierung und Schlüsselaustausch, Weiterleitungsgeheimnis und Verschlüsselung von mindestens 128 Bit bieten. Einige andere, schwächere Suiten werden möglicherweise weiterhin unterstützt, sofern sie nur mit älteren Kunden ausgehandelt werden, die nichts Besseres unterstützen.

Es gibt mehrere veraltete kryptografische Grundelemente, die vermieden werden müssen:

Anonyme Diffie-Hellman (ADH) -Suiten bieten keine Authentifizierung.

  • NULL-Chiffresuiten bieten keine Verschlüsselung.
  • Export-Cipher-Suites sind unsicher, wenn sie in einer Verbindung ausgehandelt werden. Sie können jedoch auch gegen einen Server verwendet werden, der stärkere Suites bevorzugt (FREAK-Angriff).
  • Suiten mit schwachen Chiffren (normalerweise 40 und 56 Bit) verwenden eine Verschlüsselung, die leicht beschädigt werden kann.
  • RC4 ist unsicher.
  • 3DES ist langsam und schwach.

Verwenden Sie als Ausgangspunkt die folgende Suite-Konfiguration, die sowohl für RSA- als auch für ECDSA-Schlüssel entwickelt wurde:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

Hinweis In dieser Beispielkonfiguration werden nicht standardmäßige Suite-Namen verwendet, die von OpenSSL benötigt werden. Für die Bereitstellung in anderen Umgebungen (z. B. IIS) müssen Sie die Standardnamen der TLS-Suite verwenden.

Referenz: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

1
bhushan5640