disabled SSL3 not reflected in "supported protocols"

Bradford Wetmore bradford.wetmore at oracle.com
Thu Jan 29 01:44:09 UTC 2015



On 1/27/2015 9:50 AM, Bernd wrote:

 > with the Java 7u76 update the default security setting is, that SSL3 is
 > banned.

As you saw (and for those that haven't yet), SSLv3 has been disabled 
(deactivated) by default, but it can be reenabled by removing "SSLv3" 
from the list of disabled algorithms in the Security Property 
"jdk.tls.disabledAlgorithms".  (See <JAVA-HOME>/lib/security/java.security)

     jdk.tls.disabledAlgorithms=SSLv3

SSLv3 is still available, but you have to really jump through hoops to 
get it back.

 > At first I thought, this would reflect in enabled and supported
 > protocols, however the list of supported protocols still contain SSL3
 > and I can also enable SSL3 and this is reflected on the
 > getEnabledProtocols():
 >
 > 1.7.0_76 Oracle Corporation jdk.tls.disabledAlgorithms=SSLv3
 > Default Protocols, enabled: [TLSv1] supported: [SSLv2Hello, SSLv3,
 > TLSv1, TLSv1.1, TLSv1.2]
 > Set SSL3+TLSv1, enabled: [SSLv3, TLSv1]
 > Set SSL3, enabled: [SSLv3]
 > Now handshaking...
 > Exception in thread "main" javax.net.ssl.SSLHandshakeException: No
 > appropriate protocol (protocol is disabled or cipher suites are
 > inappropriate)
 >
 > Only at handshake time it looks, like the disabled check is done.

Correct.  It uses the new AlgorithmConstraints class internally, and 
there's a lookup of the Security Property for older releases.

 > I wonder would it be cleaner to remove it from the supported set and not
 > keep it in the enabled set (but accept the setEnabled for backward
 > compatibility).

We went back and forth on this trying to balance the complete removal of 
the SSLv3 code vs. your suggestion to something in between, and it had 
to be something that a System Admin could configure.

We decided for those applications that had hard-coded SSLv3, we should 
not introduce an unexpected IllegalArgumentException Runtime exception 
on set().  We also had to balance in JCK assumptions that a set() 
followed by a get() were expected to return the same values.  (e.g. no 
new JCK failures.)

All of the SSLContexts leave SSLv3 out of the default protocol list 
(including the "SSLv3" SSLContext which leaves only "TLSv1" enabled), so 
the only people who would be potentially impacted are those who are 
intentionally trying to set SSLv3, and they should be asking themselves 
different questions.

This approach is a little confusing/surprising, but gave us the best 
compromise between the competing goals.

Brad


More information about the security-dev mailing list