SSLSocketFactory provides getDefaultCipherSuites (ciphers that are enabled by default on sockets) and getSupportedCipherSuites (ciphers that can be enabled, if desired).
However, SSLSocketFactory does not offer setEnabledCipherSuites to configure the cipher list once to provide the preference on subsequent sockets.
In fact, I think making setEnabledCipherSuites part of SSLSocket really complicates wok flows. For example, HttpsURLConnection does not provide a getSocket, and it really breaks this flow:
...
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, trustManager.getTrustManagers(), null);
HttpsURLConnection connection = (HttpsURLConnection) url.openConnection();
connection.setSSLSocketFactory(context.getSocketFactory());
I think the same can be said about SSLContext since it has methods like getDefaultSSLParameters and getSupportedSSLParameters.
I’m trying to come up with a sound security engineering reason for the (in)ability, but I can’t. Perhaps there’s a software engineering reason for the decision. (I suspect there’s a good reason, and I lack the insight to see it at the moment).
Why does Java lack the ability to configure the SSLSocketFactory? Its clearly a design decision, and I’m trying to understand why it was made at the expense of security in a relevant portion of the library.
JSSE allows customizing the ciphers and other implementation details through the security properties. See Customizing JSSE.
Why does Java lack the ability to configure the SSLSocketFactory?
It could be that it was deemed to be a bad idea to allow an application to alter the enabled cipher suites. You could argue that this is a platform security issue rather than an application responsibility, and that it would be a bad thing for some application to be able to enable (or disable) suites that the system administrator has disabled / enabled.
But I don’t know, and I suspect that none of the small set of people who would really know read StackOverflow regularly.
Its clearly a design decision,
In a sense, yes. But it could just be one of those design decisions that happened by accident or by default. Or it could be that “they” didn’t think this functionality would be used. Or there may be a sound security reason for doing this.
Either way, if you feel strongly about this, you could suggest this as a Java enhancement (e.g. here), or work up a patch that implements your enhancement and submit it to the OpenJDK team.
And if you don’t feel motivated to propose / implement an enhancement, the best way to get an answer to “why did they do it” is to ask “them” yourself. (And please share the answer …)