it-swarm-eu.dev

Welche Chiffren sollte ich auf meinem Webserver verwenden, nachdem ich mein SSL-Zertifikat konfiguriert habe?

Es gibt viele gute Fragen , die fragen, welches Zertifikat für eine Website am besten geeignet ist. Sobald das Zertifikat gekauft wurde, besteht jedoch auch die Möglichkeit, die Verschlüsselungsliste auszuwählen oder zu bearbeiten.

Obwohl jeder Anbieter diese Einstellung möglicherweise etwas anders nennt, wird meines Erachtens die Verschlüsselungsliste verwendet, um Verschlüsselungsprotokolle zwischen dem Client und dem Server auszuhandeln.

  1. Was sind die Grundlagen für die Auswahl einer Verschlüsselungsliste für meine Website? Wenn die Standardeinstellungen geändert werden müssen Wohin sollten "Anfänger" gehen, um zuverlässige Ratschläge zu erhalten?

  2. Hat sich eine der traditionellen Empfehlungen seit dem BEAST- oder CRIME-Angriff im September 2011 geändert?

  3. Unterhält jemand eine Liste von Chiffren, die von OS/Vendor/und Version unterstützt werden? Ist es richtig zu sagen, dass so etwas nützlich wäre?

  4. Sind einige Zertifikate mit bestimmten Chiffren nicht kompatibel oder werden sie nicht bevorzugt?

  5. Wo kann ich mehr lernen? Wie kann ich konkret die Fähigkeit erhalten, Chiffren zu vergleichen, ohne einige postsekundäre Mathematikklassen wiederholen zu müssen?

30

In SSL/TLS wählt die Verschlüsselungssuite eine Reihe von Algorithmen für verschiedene Aufgaben aus: Schlüsselvereinbarung, symmetrische Verschlüsselung, Integritätsprüfung.

Der Zertifikatstyp wirkt sich auf die Auswahl der Schlüsselvereinbarung aus. Zwei Parameter müssen berücksichtigt werden: der Schlüsseltyp und der Schlüsselnutzung:

  • Mit einem RSA-Schlüssel können Sie nominell die Verschlüsselungssuite "RSA" und "DHE_RSA" verwenden. Wenn das Serverzertifikat jedoch eine Key Usage-Erweiterung hat, die nicht Das Flag "keyEncipherment" enthält, sind Sie nominell auf "DHE_RSA" beschränkt.
  • Mit einem DSA-Schlüssel können Sie nur eine "DHE_DSS" -Verschlüsselungssuite verwenden.
  • Mit einem Diffie-Hellman-Schlüssel können Sie je nach Schlüsseltyp der ausstellenden Zertifizierungsstelle nur einen von "DH_RSA" oder "DH_DSS" verwenden.

Die meisten SSL-Serverzertifikate verfügen über einen RSA-Schlüssel, der nicht durch eine Key Usage-Erweiterung eingeschränkt ist. Sie können also sowohl die Schlüsseltypen "RSA" als auch "DHE_RSA" verwenden.

"DHE" steht für "Diffie-Hellman Ephemeral". Dies ermöglicht Perfect Forward Secrecy . PFS bedeutet, dass ein Angreifer, wenn er den privaten Serverschlüssel stiehlt (der in einer Datei gespeichert ist und daher plausibel für Hintergedanken anfällig ist), vergangene aufgezeichnete Transaktionen immer noch nicht entschlüsseln kann. Dies ist eine wünschenswerte Eigenschaft, insbesondere wenn Sie möchten, dass Ihr System während eines Audits gut aussieht.

Für die Integritätsprüfung sollten Sie MD5 nicht verwenden und nach Möglichkeit auch SHA-1 vermeiden. Keine der derzeit bekannten Schwachstellen von MD5 und SHA-1 wirkt sich auf die Sicherheit von TLS aus (außer möglicherweise, wenn sie in einem Zertifikat verwendet werden, dies wird jedoch von der Zertifizierungsstelle ausgewählt, nicht von Ihnen). Die Verwendung von MD5 (oder in geringerem Maße von SHA-1) ist jedoch schlecht für die Öffentlichkeitsarbeit. MD5 ist "kaputt". Wenn Sie MD5 verwenden, müssen Sie sich möglicherweise rechtfertigen. Niemand würde die Wahl von SHA-256 in Frage stellen. Der allgemeine Konsens ist, dass SHA-1 aus alten Gründen "tolerierbar" ist.

Für symmetrische Verschlüsselung haben Sie die Wahl zwischen (meistens) RC4, 3DES und AES (für letzteres ist die 256-Bit-Version übertrieben; AES- 128 ist schon in Ordnung). Folgende Punkte können gemacht werden:

  • RC4 und 3DES werden überall unterstützt. Die ältesten Clients unterstützen AES möglicherweise nicht (z. B. scheint Internet Explorer 6.0 nicht in der Lage zu sein, AES-basierte Cipher Suites auszuhandeln).

  • Es sind Schwachstellen in RC4 bekannt. Keiner ist sofort tödlich. Die Situation ist der von SHA-1 etwas ähnlich: akademisch "kaputt", aber momentan kein Problem. Dies ist immer noch ein guter Grund, RC4 nicht zu verwenden, wenn dies vermieden werden kann.

  • 3DES ist eine 64-Bit-Blockverschlüsselung. Dies impliziert einige (akademische) Schwachstellen, wenn Sie mehr als ein paar Gigabyte in einer einzigen Sitzung verschlüsseln.

  • 3DES kann Ihre CPU stark belasten. Auf einem 2,7-GHz-Intel i7 erreicht OpenSSL mit AES-128 eine Verschlüsselungsgeschwindigkeit von 180 MB/s (es könnte viel besser sein, wenn es AES-NI-Anweisungen verwendet), aber nur 25 MB/s mit 3DES. 25 MB/s sind immer noch gut (das ist das 2,5-fache, was eine 100-Mbit/s-Verbindung verarbeiten kann und einen einzelnen Kern verwendet), aber je nach Ihrer Situation möglicherweise nicht vernachlässigbar.

  • Der BEAST-Angriff ist eine alte akademische Schwäche, von der kürzlich gezeigt wurde, dass sie in der Praxis anwendbar ist. Es erfordert, dass der Angreifer den Link ausspioniert und feindlichen Code auf dem Client ausführt (und dieser Code muss mit dem externen Spionagesystem kommunizieren); Die BEAST-Autoren haben es geschafft, es auszuführen, wenn der feindliche interne Code Java oder Javascript) verwendet. Die generische Lösung besteht darin, auf TLS 1.1 oder 1.2 umzuschalten, die immun sind. Dies betrifft auch nur Blockchiffren im CBC-Modus ist RC4 immun.

  • Bei einem SSL/TLS-Handshake kündigt der Client seine unterstützten Cipher Suites an (bevorzugte Suites stehen an erster Stelle), und der Server wählt die Suite aus, die verwendet werden soll. Es ist traditionell, dass der Server die Clienteinstellungen berücksichtigt - d. H. Die erste Suite in der Liste auswählt, die vom Client gesendet wird und die der Server verarbeiten kann. Ein Server kann jedoch seine eigene Reihenfolge der Einstellungen erzwingen.

  • DHE impliziert einen etwas höheren CPU-Verbrauch auf dem Server (aber es macht keinen merklichen Unterschied, wenn Sie nicht mehrere hundert neue SSL-Sitzungen pro Sekunde einrichten).

  • Es gibt keine DHE-Verschlüsselungssuite, die RC4 verwendet.

Zusammenfassung: Dies führt mich zu der folgenden bevorzugten Liste von Chiffresuiten. Wenn der BEAST-Angriff auf Sie zutrifft (d. H. Der Client ist ein Webbrowser), verwenden Sie Folgendes:

  • Wenn die Sitzung SSL-3.0 oder TLS-1.0 verwendet, versuchen Sie, TLS_RSA_WITH_RC4_128_SHA Zu verwenden.
  • Wenn der Client TLS 1.1+ unterstützt oder wenn er TLS_RSA_WITH_RC4_128_SHA Nicht unterstützt oder wenn Sie PFS für Sie wichtiger halten als BEAST-ähnliche aktive Angriffe (z. B. sind Sie am meisten besorgt über die langfristige Vertraulichkeit, keine unmittelbaren Verstöße), verwenden Sie dann TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (Fallback auf TLS_DHE_RSA_WITH_AES_128_CBC_SHA, wenn der Client SHA-256 nicht unterstützt).
  • Wenn DHE-Verschlüsselungssuiten vom Client nicht unterstützt werden, verwenden Sie die entsprechende Nicht-DHE-Suite.
  • Generischer Fallback ist TLS_RSA_WITH_3DES_EDE_CBC_SHA, Der überall funktionieren sollte.

Beachten Sie, dass bei den obigen Auswahlmöglichkeiten davon ausgegangen wird, dass Sie die Suite-Auswahl abhängig von der ausgehandelten Protokollversion ändern können. Dies ist möglicherweise eine verfügbare Option für Ihren bestimmten SSL-Server.

Wenn BEAST nicht auf Sie zutrifft (der Client führt keinen feindlichen Code aus), beenden Sie die RC4-Unterstützung vollständig. Konzentrieren Sie sich auf AES-128 und SHA-256. Fallback auf 3DES bzw. SHA-1; Verwenden Sie DHE, falls verfügbar.

29
Thomas Pornin

Ich mag die von Mozilla vorgeschlagene Chiffresuite (im Januar 2014):

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

quelle: https://wiki.mozilla.org/Security/Server_Side_TLS

es versucht, Leistung und Sicherheit in Einklang zu bringen. Allerdings wie von meinem Microsoft empfohlen würde ich mich von RC4 fernhalten

2
VP.

Wo sind Korrekturen und wie könnten sie aussehen? Die einzige Lösung wäre, dass alle Browser auf allen relevanten Plattformen TLS 1.1 oder 1.2 implementiert bekommen. Ich glaube jedoch nicht, dass dies bei älteren Plattformen wie der Fall sein wird.

Daher habe ich RC4 vorerst nur als Problemumgehung gesehen, da die meisten SW-Entwickler in der Vergangenheit die Implementierung der neuesten TLS-Standards verpasst haben und wir jetzt in der aktuellen Situation gefangen sind.

2
Jui

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

Schauen wir uns zuerst die Chiffren an, die den BEAST-Angriff ignorieren.

Ich würde empfehlen, nur "aktuelle" Chiffren mit starken Schlüsseln zu verwenden und keine historischen Chiffren zu unterstützen, die sowieso niemand verwendet. Also zum Beispiel kein RC4. Außerdem würde ich Chiffren auf Exportniveau empfehlen, da diese sehr schwache Schlüssel haben, damit die US-Regierung sie möglicherweise brechen kann. Obwohl ich glaube, dass das Exportieren von höherwertiger Krypto nicht mehr illegal ist, existiert das Konzept immer noch in Ihrer Serverkonfiguration. Vermeiden Sie schließlich Hashing-Algorithmen mit großen Problemen wie MD5.

Jetzt der BEAST-Angriff. Anscheinend ist AES im CBC-Modus, wie er in TLS 1.0 verwendet wird, anfällig für einen ausgewählten Klartext-Wiederherstellungsangriff. mail.google.com verteidigte sich dagegen, indem es diese Woche schnell auf 128-Bit-RC4 umstellte. Wenn Sie in den kommenden zwei Wochen sehr besorgt über diesen Angriff sind (wie es bei Google der Fall wäre), können Sie dieselbe Problemumgehung anwenden. In anderen Fällen würde ich einfach auf eine Korrektur warten und Ihre Chiffren konfigurieren, ohne diesen Angriff zu berücksichtigen.

0
chris

Hier finden Sie einige interessante Konfigurationen für die Auswahl von Apache2 und starken SSL-Algorithmen:

Mozilla SSL-Konfigurationsgenerator https://mozilla.github.io/server-side-tls/ssl-config-generator/

Die Empfehlung 2019.02 für moderne Browser lautet:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: ECDHE-ECDSA-AES12: -AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA256

lesbar:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
0
amprantino