it-swarm-eu.dev

Welche SSL / TLS-Chiffren können als sicher angesehen werden?

Die OpenSSL-Website bietet eine lange Liste verschiedener Chiffren, die für SSL und TLS verfügbar sind. Meine Frage ist, welche dieser Chiffren heutzutage als sicher angesehen werden können. Ich interessiere mich besonders für HTTPS, wenn dies wichtig sein sollte, obwohl ich denke, dass dies nicht der Fall ist. Mir ist die Apache-Empfehlung zur Verwendung von SSLCipherSuite HIGH:MEDIUM Bekannt und ich stimme zu, dass dies die beste Vorgehensweise ist.

Was ich suche, ist ein offizieller Standard oder ein aktuelles Papier aus einer anerkannten und anerkannten Quelle wie einer bekannten Sicherheitsorganisation. Wenn ein solches Papier existiert, das Schätzungen darüber enthält, wie lange bestimmte Chiffren mit einer bestimmten Schlüssellänge als sicher gelten, wäre dies sogar noch besser. Gibt es so etwas?

33
Demento

Die Cipher Suites mit einem "NULL" bieten keine Datenverschlüsselung, sondern nur eine Integritätsprüfung. Dies bedeutet für die meisten Verwendungen "nicht sicher".

Die Cipher Suites mit "EXPORT" sind von Natur aus schwach. Sie sind verschlüsselt, jedoch nur mit Schlüsseln, die klein genug sind, um selbst mit Amateurhardware geknackt zu werden (z. B. einem einfachen Heim-PC - symmetrische Verschlüsselung mit 40- Bitschlüssel). Diese Suiten wurden so definiert, dass sie den US-Exportregeln für kryptografische Systeme entsprechen, die vor 2000 recht streng waren. Heutzutage wurden diese Einschränkungen aufgehoben, und es macht wenig Sinn, die Chiffresuiten "EXPORT" zu unterstützen.

Die Chiffresuiten mit "DES" (nicht "3DES ") stützen sich für die symmetrische Verschlüsselung auf DES , eine alte Blockverschlüsselung, die technisch einen 56-Bit-Schlüssel ( verwendet verwendet einen 64-Bit-Schlüssel, ignoriert jedoch 8 dieser Bits, sodass die effektive Schlüsselgröße 56 Bit beträgt. Ein 56-Bit-Schlüssel ist knackbar, wenn auch nicht in fünf Minuten mit ein PC. Deep Crack war eine Spezialmaschine, die 1998 für etwa 250.000 US-Dollar gebaut wurde und einen 56-Bit-Schlüssel DES) innerhalb von durchschnittlich 4,5 Tagen knacken konnte. Die Technologie hat Fortschritte gemacht, und dies kann mit ein paar Dutzend FPGAs reproduziert werden. Immer noch keine Standardhardware von Walmart, aber für viele Menschen erschwinglich.

Alle anderen von OpenSSL unterstützten Cipher Suites sind nicht schwach. Wenn Sie ein Problem mit ihnen haben, liegt dies nicht an einer kryptografischen Schwäche der Algorithmen selbst. Möglicherweise möchten Sie Verschlüsselungssuiten mit der Funktion "MD5 ", nicht wegen einer tatsächlich bekannten Schwäche, sondern für die Öffentlichkeitsarbeit. MD5 ist als Hash-Funktion" kaputt ", weil wir effizient viele Kollisionen für diese Funktion finden können. Dies ist keine Problem für MD5, wie es in SSL verwendet wird, aber das ist genug für MD5, um einen schlechten Ruf zu haben, und Sie sollten es besser vermeiden.

Beachten Sie, dass die Verschlüsselungssuite nichts an der Größe des Serverschlüssels (des öffentlichen Schlüssels im Serverzertifikat) erzwingt, der groß genug sein muss, um eine ausreichende Robustheit zu gewährleisten (für RSA oder DSS mindestens 1024 Bit, 1536 Bit) besser sein - aber nicht zu viel drücken, da der Rechenaufwand mit der Schlüsselgröße stark ansteigt).


NIST , eine US-Bundesorganisation, die so anerkannt und bekannt ist wie jede andere Sicherheitsorganisation, hat einige Empfehlungen veröffentlicht (siehe insbesondere die Tabellen auf den Seiten 22 und 23); Dies ist aus dem Jahr 2005, aber noch heute gültig. Beachten Sie, dass NIST auf einer "genehmigten/nicht genehmigten" Basis arbeitet: Sie behaupten in keiner Weise, dass Algorithmen, die "nicht genehmigt" sind, in irgendeiner Weise schwach sind; nur, dass sie als Organisation nicht für sie bürgen.

37
Thomas Pornin

Haben Sie SSL und TLS: Entwerfen und Erstellen sicherer Systeme von Eric Rescorla gelesen? Es ist der akzeptierte Klassiker für SSL, der von einem der führenden Autoren der IETF-Arbeitsgruppe für SSL-Standards geschrieben wurde. Ich würde erwarten, dass es geeignete Aussagen über die Stärke verschiedener SSL-Chiffren enthält.

Wenn dies nicht Ihren Anforderungen entspricht, können Sie in Ihre freundliche Bibliothek gehen und alle vorhandenen Kryptografie- und Sicherheitslehrbücher lesen und die auf SSL/TLS geschriebenen Abschnitte lesen.

Wenn Sie nach einer Referenz suchen, um Fakten zu dokumentieren, die jeder Sicherheitsexperte bereits kennt, müssen Sie möglicherweise selbst einige Schritte unternehmen, um das beste Zitat zu finden.

4
D.W.

Einige kleine Ergänzungen zu Thomas Pornins Antwort: Während NIST SP800-52 für TLS im Allgemeinen offiziell bleibt (wenn auch etwas veraltet), wird es für Schlüsselgrößen speziell von SP800-57 abgelöst: Teil 1 behandelt Schlüsselgrößen und Lebensdauern im Allgemeinen, die zuletzt überarbeitet wurden Jahr 2012; Teil 3 behandelt einige spezifische Anwendungen, einschließlich TLS, herausgegeben 2010. Kurz gesagt, sie haben 2011 versucht, RSA DSA und DH 2048 Bit und ECC 224 Bit zu benötigen, aber es gab zu viel Pushback, also ist es jetzt 2014 - bald! (DSA bei 2048 oder 3072 Bit wird durch FIPS 186-3 im Jahr 2009 angegeben, aber ich sehe noch nicht viel Implementierung. Sogar openssl hat es ziemlich ungeschickt gemacht.) Www.CABforum.org stimmt zu mit RSA 2048 im Jahr 2014: Während Sie Ihr Zertifikat nicht von einer "offiziellen" Zertifizierungsstelle erhalten müssen, werden Sie mit Skepsis behandelt, wenn Sie sichtbar weniger als die übliche "Standard" -Praxis anwenden. FWIW NIST sagt derzeit, dass Stärke (Z_n 2048, ECC 224, symmetrisch 112) ist bis 2030 "akzeptabel", danach ist 3072/256/128 erforderlich; selbst wenn sie sich als falsch herausstellen, haben Sie, wenn Sie mit ihnen gehen, eine so gute Entschuldigung, wie Sie finden können, und Sie werden auf jeden Fall viel gute Gesellschaft haben. Schließlich ist csrc.nist.gov eine bessere Start-URL für Cybsersecurity (NIST als Ganzes macht einige andere Dinge).

3
Dave Thompson

Das Einholen der offiziellen Empfehlungen kann für die meisten Benutzer eine entmutigende Aufgabe sein.

Der schnellste Weg, um eine aktuelle Liste moderner Chiffren zu erhalten, besteht darin, regelmäßig den Mozilla SSL Configuration Generator zu überprüfen.

Ab August 2016 lautet die (geordnete) Liste:

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

Stellen Sie neben dem einfachen Anwenden dieser Chiffren Folgendes sicher:

  • stellen Sie die TLS-Version auf 1.2 (oder höher) ein.
  • verwenden Sie eine sichere Kurve (wie unter safecurves.cr.yp.to definiert.

Hinweis: Alle diese Chiffren sind mit dem (kommenden) TLS1.3 kompatibel.

2
ATo