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

Reply via email to