The Java Cryptography Architecture Standard Algorithm Name Documentation page for Java 6 lists ECDHE cipher suites. Thus I would expect they are supported in Java 6. Yet neither OOTB Java 6 nor the addition of the JCE Unlimited Strength policy files is enabling them.
The book Bulletproof SSL and TLS also indicates Java 6 supports ECDHE, with a caveat:
Enable and prioritize ECDHE suites on the server. Java 6 and 7 clients support these, and will happily use them. (But do note that with Java 6 you must switch to using the v3 handshake in order to utilize ECDHE suites at the client level.)
I’m assuming by v3 handshake he means SSLv3? I haven’t tried it but even if this works, SSLv3 is not a viable option due to the POODLE vulnerability.
What am I missing?
Advertisement
Answer
The SSL/TLS implementation “JSSE” in Java 1.6 and later supports ECDHE suites IF there is an available (JCE) provider for needed ECC primitives. Java 1.6 OOTB does NOT include such an ECC provider, but you can add one. Java 7 and 8 do include SunECC provider.
This seems to be a hot topic today. See also https://security.stackexchange.com/questions/74270/which-forward-secrecy-cipher-suites-are-supported-for-tls1-0-protocols and https://superuser.com/questions/848698/testing-cipher-suite-using-openssl-for-tomcat-server-is-resulting-in-wrong-manne (which, suprisingly to me, was migrated from security).
Ristic’s book undoubtedly means the v3 format ClientHello. There was a major format change between SSL2 and SSL3, and SSL2 ClientHello can’t represent the data (particularly extensions) for ECC. All versions of TLS (to date) use the same format as SSL3, with (importantly) different contents. In the early oughties SSL clients often used SSL2 format ClientHello but with content allowing upgrade to SSL3 and even TLS1.0 in order to succeed against both/all servers, because many SSL2 were still in use.
Java 1.6 client circa 2006 was transitional — by default it uses SSL2 format specifying versions up to TLS1.0, but if the server agrees to version SSL2 and not higher, the client aborts with an exception saying in effect “SSL2 is not secure”. This is controlled by a pseudo-protocol string SSLv2Hello, so on Java 1.6 client you should .setEnabledProtocols to remove/exclude that.
Java 7 and 8 still implement SSLv2Hello but no longer enable it by default, so v3 format is used by default, or as long as you specify protocols to be (all) SSL3 or better. 7 and 8 also implement TLS1.1 and 1.2 which 6 did not, although only 8 enables them in client by default. You should only specify SSLv2Hello if you are connecting to way-old SSL2-only servers — which of course you should try very hard not to do at all.