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