it-swarm.com.de

Ist TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 eine sichere Verschlüsselungssuite?

Ist TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 eine sichere Verschlüsselungssuite für eine TLS 1.2-Verbindung zu einem Tomcat-Server? Was sind mögliche Schwächen oder bessere Alternativen? Ich suche nach einer Chiffre, die von Java 8) unterstützt wird.

11
JRA_TLL

TLS-Ciphersuite-Namen sind so strukturiert, dass Sie erkennen können, welche Algorithmen und Schlüsselgrößen für jeden Teil des Handshakes und der verschlüsselten Sitzung verwendet werden. Lassen Sie uns diesen aufschlüsseln und sehen, ob wir Verbesserungen vornehmen können:

  • TLS - Dies bedeutet nichts an sich, erlaubt mir jedoch zu erwähnen, dass TLS 1.2 die neueste Version von TLS ist und keine bekannten Schwachstellen aufweist.
  • ECDHE - Elliptic Curve Diffie-Hellman mit kurzlebigen Schlüsseln. Dies ist die Schlüsselaustauschmethode. Der Austausch von Diffie-Hellman-Schlüsseln, bei denen kurzlebige (pro Sitzung generierte) Schlüssel verwendet werden, bietet Vorwärtsgeheimnis. Dies bedeutet, dass die Sitzung nachträglich nicht entschlüsselt werden kann, selbst wenn der private Schlüssel des Servers bekannt ist. Die Kryptographie mit elliptischen Kurven bietet die gleiche Stärke wie die herkömmliche Kryptographie mit öffentlichen Schlüsseln und erfordert kleinere Schlüsselgrößen, wodurch die Leistung verbessert werden kann. Darüber hinaus dienen sie als Absicherungswette gegen eine Unterbrechung der RSA.
  • RSA - Das Serverzertifikat muss einen öffentlichen RSA-Schlüssel enthalten und der entsprechende private Schlüssel muss zum Signieren der ECDHE-Parameter verwendet werden. Dies bietet die Serverauthentifizierung. Die Alternative wäre ECDSA, ein weiterer Algorithmus für elliptische Kurven. Möglicherweise sind Sie jedoch durch die Arten von Zertifikaten eingeschränkt, die Ihre Zertifizierungsstelle signiert.
  • AES_128 - Die symmetrische Verschlüsselung ist AES mit 128-Bit-Schlüsseln. Dies ist relativ schnell und nicht fehlerhaft (es sei denn, Sie glauben, NSA hat AES, ein Thema für ein anderes Mal, hinter die Tür gestellt). Abgesehen von AES_256 (was in Bezug auf die Leistung möglicherweise zu kostspielig ist) ist es die beste Wahl der in RFC 5246 definierte symmetrische Chiffren , die anderen sind RC4 (das einige bekannte Schwächen aufweist und möglicherweise relativ bald gebrochen wird) und 3DES_EDE (das je nach abhängig nur eine praktische Bitstärke von 108 bis 112 aufweist Ihre Quelle).
  • CBC - Verkettungsmodus für Chiffrierblöcke. Hier können Sie wahrscheinlich Ihre Auswahl verbessern. Der CBC-Modus ist eine Möglichkeit, eine Blockverschlüsselung zum Verschlüsseln von Daten variabler Länge zu verwenden, und war in der Vergangenheit die Ursache für TLS-Probleme: BEAST, Lucky-Thirteen und POODLE waren alle Angriffe auf TLS im CBC-Modus. Eine bessere Wahl für Leistung und Sicherheit ist AES_128_GCM, eine der neuen AEAD-Chiffren, die in TLS 1.2 eingeführt wurden und gute Leistungs- und Sicherheitseigenschaften aufweisen.
  • SHA256 - Dies ist die Hash-Funktion, die der MAC-Funktion (Message Authentication Code) der TLS-Chiffriersuite zugrunde liegt. Dies garantiert, dass nicht jede Nachricht während der Übertragung manipuliert wurde. SHA256 ist eine gute Wahl und der Standard-Hash-Algorithmus für verschiedene Teile von TLS 1.2. Ich bin mir ziemlich sicher, dass die Verwendung von SHA-1 hier in Ordnung wäre, da das Fenster für die Ausnutzung so viel kleiner ist als z. die Zertifikatsignatur. AEAD-Verschlüsselungssuiten werden zunächst authentifiziert, sodass dieser zusätzliche MAC-Schritt nicht benötigt oder implementiert wird.

Im Wesentlichen haben Sie sich für eine gute Chiffriersuite entschieden, die derzeit keine praktischen Probleme aufweist. Möglicherweise möchten Sie jedoch zu einer AEAD-Chiffriersuite (AES-GCM oder ChaCha20-Poly1305 von Google) wechseln, um die Leistung zu verbessern und sich vor zukünftigen CBC-Schwachstellen zu schützen .

20
bonsaiviking

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ist so "sicher" wie jede Verschlüsselungssuite sein kann: Es ist keine Protokollschwäche im Zusammenhang mit TLS 1.2 mit dieser Verschlüsselungssuite bekannt. Jede bestimmte Implementierung kann natürlich Dinge verpfuschen und Schwächen von selbst einführen. Sie können auch Ihre eigene Sicherheit mit Füßen treten, indem Sie beispielsweise den Speicher Ihres Server-RSA-Schlüssels nicht ordnungsgemäß schützen. oder Verwenden der Erzeugung schwacher Schlüsselpaare für diesen RSA-Schlüssel; oder Deaktivieren der Zertifikatsvalidierung im Client; oder eine andere von zig dummen Handlungen, die machbar sind, wenn Sie nicht pass auf dich auf.

7
Thomas Pornin

Es gab ein kürzlich aktualisiertes Update auf allen CBC-Chiffren, die in den meisten Situationen unsicher machen könnten. Daher sollten Sie Ihre Serversicherheit wahrscheinlich neu bewerten, indem Sie eine Prüfung ausführen. (Mehr Infos von SSLLabs )

Was zu verwenden ist, hat cfieber richtig kommentiert, und Ihre besten (und einzigen) Wetten für Java 8 sind jetzt TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Und TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 abhängig vom Zertifikatstyp. (Entnommen aus hier )

1
Stoinov