2015-08-12 14 views
10

Wenn jetty-distribution-9.3.0.v20150612 mit openjdk 1.8.0_51 auf einem EC2 Amazon Linux-Rechner gestartet wird, wird gedruckt, dass alle konfigurierten ECDHE-Suites nicht unterstützt werden.ECDHE Cipher Suites werden nicht von OpenJDK 8 auf EC2 Linux Maschine unterstützt

2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA not supported 

Diese werden in jetty/etc/jetty-ssl-context.xml aktiviert -

<Set name="IncludeCipherSuites"> 
<Array type="java.lang.String"> 
<!-- TLS 1.2 AEAD only (all are SHA-2 as well) --> 
    <Item>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256</Item> 
    <Item>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256</Item> 
    <Item>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</Item> 
    <Item>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</Item> 
    <Item>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</Item> 
    <Item>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</Item> 
... 

Ich lese Oracle Java 8 should support these protocols, aber das ist vielleicht nicht von OpenJDK unterstützt? Oder sollte ich es irgendwie aktivieren?

aktualisieren

Oracle JCE Verschlüsselungs-Provider unter jre/lib/security/ installiert ist, aber es hat nicht geholfen.

+0

Die Installation der JCE-Verschlüsselung von Oracle auf einer OpenJDK-Installation hat keine Auswirkungen, da die ECDHE-Verschlüsselungen in nativem C-Code implementiert sind und nur im Oracle JDK ausgeliefert werden (siehe http://armoredbarista.blogspot.co.uk/2013/10/). how-to-use-ecc-with-openjdk.html) – glidester

Antwort

12

Also ich laufe ein ähnliches Setup, mit einer AWS-Box läuft Openjdk-1.8.0.51. , was es für mich gelöst ist als Anbieter hinzuzufügen bouncycastle wie so:

  • In der bcprov-<verion>.jar zu /usr/lib/jvm/jre/lib/ext

  • bearbeiten /usr/lib/jvm/jre/lib/security/java.security die folgende Zeile in die Liste der Anbieter:

    security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider 
    

(Ich habe es als 6. Eintrag hinzugefügt, aber Sie können höher in der Reihenfolge hinzufügen, wenn Sie bevorzugen)

Neustart meiner Anwendung und konnte EC-basierte Chiffre-Suiten wie TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 verwenden.

+3

Sie müssen auch 'EC, ECDHE, ECDH' aus der jdk.tls.disabledAlgorithms-Definition in Ydieser java.security-Datei in den aktuellen CentOS-OpenJDK-Distributionen entfernen, andernfalls wird es verwendet werde immer noch nicht diese Ziffern verwenden – lenswipe

+0

Ich möchte nur bestätigen, dass die Installation des Bouncycastle-Providers ein ähnliches Problem für mich gelöst hat. Auf der Bouncycastle-Seite sind 2 Provider-Jars verfügbar: 'bcprov-jdk15on- .jar' und' bcprov-ext-jdk15on- .jar'. Nicht sicher, was der Unterschied ist, aber ich benutzte das ehemalige und es hat gut funktioniert. –

+0

Ich erhalte immer noch nicht die EC-Algs, nachdem ich das BouncyCastle-Glas v1.55 in/usr/lib/jvm/jre/lib/ext eingefügt und @lenswipe vorgeschlagen habe und "EC, ECDHE, ECDH" aus der jdk.tls entfernt habe. disabledAlgorithms. Ich bin auf OpenJDK 1.8.0_101 auf RHEL7.2. BTW - Ich benutze nicht Jetty - nur eine benutzerdefinierte Java-App erstellen. Die Art und Weise, wie ich auf die Verfügbarkeit der Algs testet, ist der Aufruf von SSLServerSocket.getSupportedCipherSuites(). Die zurückgegebene Liste enthält keine EC-Chiffren. Irgendwelche anderen Dinge, die die EG-Alge blockieren könnten? –

1

Versuchen Sie, die JCE Unlimited Strength Jurisdiction Policy Files Installation (diese mit Ihrem höheren Bit-Verschlüsselungen helfen sollte)

Beachten Sie auch, in the link you provided about java 8 cipher protocol support sagt

Cipher Suiten, die verwenden Elliptic Curve Cryptography (ECDSA, ECDH, ECDHE, ECDH_anon) Benötigen Sie einen JCE-Verschlüsselungs-Provider ...

Haben Sie einen solchen Provider auf Ihrer Java 8-VM installiert?

+0

Ja, JARs ersetzt unter 'jre-1.8.0-openjdk.x86_64/lib/security', Server neu gestartet, aber es heißt immer noch" nicht unterstützt ". Ich versuche herauszufinden, ob es sich um ein OpenJDK-Problem (läuft auf einem EC2-Linux-Rechner) handelt. – Kof

+1

Die Installation von Oracle JDK 1.8 mit dem JCE-Kryptografiedienstanbieter hat dies funktioniert. Die Frage ist also, wie man diese Verschlüsselung in OpenJDK aktivieren kann? Ich werde Jetty vom Fragentitel entfernen. – Kof

+0

Sie möchten diese Stack-Trace-Zeichenfolge nur zum Post hinzufügen, damit andere diesen Post finden, wenn sie nach dem Fehler suchen. javax.net.ssl.SSLHandshakeException: Empfangene fatale Warnung: handshake_failure – glidester

-1
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA not supported 
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA not supported 

Thes-e aktiviert ist in Anlegesteg/etc/Anlegestelle-ssl-context.xm

+0

Ist das ein Versuch, die Frage zu beantworten? Wenn ja, formatieren Sie es bitte korrekt. Wenn nicht, und es ist eine Frage, sollte es als Frage (wieder mit korrekter Formatierung) gepostet werden. –

4

Die Ursache ist, dass OpenJDK auf CentOS/RHEL/Amazon Linux mit OpenJDK auf sie einfach nicht tun versenden die erforderlichen nativen Bibliotheken zur Unterstützung von EC. Die Unlimited Policy Dateien sind ein Red Hering, wie alle Versuche sind un -disable verschiedene Algorithmen usw. Wenn die Bibliotheken nicht da sind, können Sie die Funktionen nicht verwenden.

Die akzeptierte Antwort von "Install Bouncy Castle" funktioniert, weil BC eine reine Java-Implementierung aller gewünschten Algorithmen bietet. Idealerweise würde das JDK native Implementierungen bereitstellen, die eine höhere Leistung erbringen würden.

Es sieht aus wie OpenJDK auf Amazon Linux muss nur warten. :(

Ref: http://armoredbarista.blogspot.de/2013/10/how-to-use-ecc-with-openjdk.html

auch: https://security.stackexchange.com/questions/117975/how-to-enable-ecdhe-in-openjdk-1-8-0-in-centos-6-7

UPDATE 2016-11-09

Es scheint, dass Elliptische-Kurven-Oracle native Bibliothek (libsunec.so) unter der GPL lizenziert ist Sie. Sie können dies bestätigen, indem Sie auf Oracle's download page gehen, auf Third Party Licenses klicken und die README-Datei für Ihre Version von Java überprüfen

Das bedeutet, wenn Sie eine Kopie von JRE/JDK von Oracle für die Zielplattform und -architektur erhalten, können Sie die libsunec.so-Bibliothek daraus nehmen und sie legal in die OpenJDK-Installation installieren.

Für mich bedeutete das, die Datei $JAVA_HOME/jre/lib/amd64/libsunec.so von einem Oracle Java 8 JRE zu greifen und es in z. /usr/lib/jvm/jre-1.8.0/lib/amd64/. Das ist alles, was benötigt wird, um Elliptic-Curve-Algorithmen zu ermöglichen.

UPDATE 2018-03-08

Oracle Java 9 wird die "unbegrenzte Stärke Kryptographie" Bibliotheken sind enabled by default, so das ist schön. Offenbar benötigt OpenJDK weiterhin set a system property to enable "unlimited strength cryptography".

+1

Aktualisieren Sie Ihre Instanzen auf Amazon Linux 2016.09 AMIs oder höher behebt das Problem. Diese AMIs enthalten openjdk 1.8.0_121, das standardmäßig 'libsunec.so' liefert. –

+0

@AlexGrigorovitch Das sind großartige Neuigkeiten. Ich habe das selbst nicht verifiziert, aber es sieht so aus, als würde die Java-Welt endlich die kryptografischen Regeln der limitierten Kryptographie der 1990er-Ära überwinden und in die Moderne ziehen. –