Hello, For icedtea and icedtea-bin this crypto is not available, required to i2p work: Warning: Crypto ECDSA_SHA256_P256 is not available Warning: Crypto ECDSA_SHA384_P384 is not available Warning: Crypto ECDSA_SHA512_P521 is not available Cheers, Reproducible: Always
Using same I2P application, so having the same need: I2P version: 0.9.16-0 Java version: Oracle Corporation 1.7.0_55 (OpenJDK Runtime Environment 1.7.0_55-b14) Crypto: ECDSA_SHA256_P256 unavailable Crypto: ECDSA_SHA384_P384 unavailable Crypto: ECDSA_SHA512_P521 unavailable I2P developpers make it clear that this support is going to be mandatory soon: "If you run an eepsite or a service and you are not running a recent release, or your Java or OS does not support ECDSA (as noted in the logs and on the /logs page in the console), please fix the issue as soon as possible or your users will soon be unable to connect. Red Hat platforms in particular are reported to be missing ECDSA support. "
Andrew, any idea about this? Thanks.
New version of icedtea-bin-7.2.5.3, same issue. Latest version of I2P-0.9.17 getting really firm about this: "There is now a warning in the console sidebar if ECDSA is not available." Indeed: "Warning: ECDSA is not available. Update your Java or OS" That feels really weird, being advised to update something we can't, concidering we are using Gentoo ;)
What USE flags are being used to build icedtea? Is there a simple reproducer for this?
dev-java/icedtea-bin USE="X alsa cjk nsplugin -cups -doc -examples -source -webstart"
I don't know how icedtea-bin is built. Do you get the same error with dev-java/icedtea and, if so, with what USE flags?
With: dev-java/icedtea-7.2.5.3:7 USE="X alsa cjk -cacao -cups -debug -doc -examples -infinality -jamvm -javascript -jbootstrap -kerberos -nsplugin -nss -pax_kernel -pulseaudio (-selinux) -smartcard -source -sunec {-test} -webstart -zero" Same here.
Ok, the problem is that you have neither USE="nss" or USE="sunec" enabled. For the time being, USE="nss" is recommended. A correctly configured IcedTea will have the following ciphers: Supported ciphers: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] I'll attach a testcase so you can see how your installation compares.
Created attachment 390968 [details] Testcase from IcedTea PR2094 Run: $ javac DHHandshakerTest.java $ java DHHandshakerTest An IcedTea java with ECDSA will include it in the list of ciphers and successfully connect to fedoraproject.org. An IcedTea without it will fail, as the current release (2.5.3) does not yet support DH keys of a big enough size (PR2094 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2094)
(In reply to Andrew John Hughes from comment #9) > Created attachment 390968 [details] > Testcase from IcedTea PR2094 > > Run: > > $ javac DHHandshakerTest.java > $ java DHHandshakerTest > > An IcedTea java with ECDSA will include it in the list of ciphers and > successfully connect to fedoraproject.org. An IcedTea without it will fail, > as the current release (2.5.3) does not yet support DH keys of a big enough > size (PR2094 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2094) Great! Thanks for this testing tool. I can confirm icedtea-bin-7.2.5.3 fails this test: ~/tmp $ java -version java version "1.7.0_71" OpenJDK Runtime Environment (IcedTea 2.5.3) (Gentoo package icedtea-7.2.5.3) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) ~/tmp $ java DHHandshakerTest Supported ciphers: [TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Tusting all certificates! Exception in thread "main" java.lang.RuntimeException: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at DHHandshakerTest.main(DHHandshakerTest.java:31) Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1884) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1842) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1825) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1346) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at DHHandshakerTest.establish(DHHandshakerTest.java:59) at DHHandshakerTest.main(DHHandshakerTest.java:29) Caused by: java.lang.RuntimeException: Could not generate DH keypair at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:136) at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:681) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:261) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:878) at sun.security.ssl.Handshaker.process_record(Handshaker.java:814) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) ... 3 more Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 2048 (inclusive) at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120) at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:658) at sun.security.ssl.DHCrypt.<init>(DHCrypt.java:127) ... 10 more
Work with icedtea, but I need solution for icedtea-bin
(In reply to BRULE Herman from comment #11) > Work with icedtea, but I need solution for icedtea-bin Indeed, is there any way to get the equivalent of USE="nss" into icedtea-bin for future releases?
I've reported an issue with regard to this and I2P upstream: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2497
(In reply to stanley - Security Padawan from comment #13) > I've reported an issue with regard to this and I2P upstream: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2497 I need to start building the next icedtea-bin right now. You seem to be saying that enabling nss isn't sufficient and you need to disable sunec as well. I don't want to do that without further guidance from gnu_andrew but it looks like you can solve it another way by tweaking the java.security file. https://www.assetbank.co.uk/support/documentation/knowledge-base/oracle-jdk-7-nss/ I will therefore enable both and hope that works for you.
I need confirmation from gnu_andrew but it appears to me that all the nss flag actually does it uncomment the SunPKCS11 line in java.security. gnu_andrew says this provider currently has memory leaks, which is why we don't currently enable it. It is the least preferred in the list so I doubt whether it is normally used but given that you seemingly need to disable SunEC for I2P to work anyway, there's little point in me enabling nss in my builds.
I'm going to mark this fixed because the nss flag is now present on both icedtea and icedtea-bin. It has the same effect on both in that it simply comments or uncomments a single line in java.security as mentioned above. This may not be enough for I2P but that should be resolved in the upstream bug.