JDK-6720693 : RFE: Allow the disabling of specific cipher across all providers
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 5.0u14
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2008-06-30
  • Updated: 2012-05-09
  • Resolved: 2010-11-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
JDK-6916074 - Add support for TLS 1.2
Description
The customer reported:

A security audit showed several open ports with SSL servers running. This is
OK but some of them allowed connections from clients with weak ciphers (like
DES). First we identified the component and found cacao, the Common Agent
Container. It is installed during JumpStart and later updated by SunCluster.

I found with 
        cacaoadm list-modules
that several Sun Cluster components are registered in this thing. So it is
unlikely, that we can disable it. First question: is this right? Do we have
to live with the service
        svc:/application/management/common-agent-container-1:default
which results in the process
        root      3550  0.1  0.8209792131488 ?        S 15:13:53  0:29 /usr/jdk/jdk1.5.0_15/bin/java -Xms4M -Xmx128M -Dcom.sun.management.jmxremote -Dfile.encoding=utf-8 -classpath /usr/share/lib/jdmk/jdmkrt.jar:/usr/share/lib/jdmk/jmxremote_optional.jar:/usr/lib/cacao/lib/cacao_cacao.jar -Djavax.management.builder.initial=com.sun.jdmk.JdmkMBeanServerBuilder -Dcacao.print.status=true -Dcacao.config.dir=/etc/cacao/instances/default -Dcom.sun.cacao.ssl.keystore.password.file=/etc/cacao/instances/default/security/password -Dcacao.monitoring.mode=smf com.sun.cacao.container.impl.ContainerPrivate

When we can disable it, we would obviously prefer this. How does this work?
A developer told me, he disabled it with
        svcadm disable svc:/application/management/common-agent-container-1:default
but after a reboot it was running again.

The next best solution (I think the one we have to go for) is to disable the
weak ciphers inside cacao. Unfortunately, I did not find anything in the
configuration files like
        /etc/cacao/instances/default/private/cacao.properties
I had a short look at the source code
        https://common-agent-container.dev.java.net/source/browse/common-agent-container/trunk/src
but without a working search function it was simply too much to click through.

To check, that weak ciphers are used I did
        cacaoadm get-param commandstream-adaptor-port
to get the open port, which can also be seen with pfiles in the above mentioned
process.
Then I connected to this port with
        /usr/sfw/bin/openssl s_client -connect localhost:11163 -cipher LOW
and was connected with the cipher EDH-RSA-DES-CBC-SHA. This means in
essence DES, which uses 56 bits, which is very weak.

Second question: What do I have to configure, to get an error in this case?
I still want to be able to connect with things like "-cipher AES" but DES (and
everything with too few key bits) should be disabled.

I played around with
/usr/jdk/instances/jdk1.5.0/jre/lib/security/sunpkcs11-solaris.cfg
where some disabled algorithms for Java are listed and added all constants
with RC4 in them from /usr/include/security/pkcs11t.h

  CKM_RC4
  CKM_RC4_KEY_GEN
  CKM_PBE_SHA1_RC4_128
  CKM_PBE_SHA1_RC4_40

I took RC4 simply because fewer CKM_ constants existed with RC4 than with DES.
On the other hand this configuration file is for all Java processes and I did
not intend to disturb any other processes. I simply hoped, nobody would use
RC4 anyway.

Then I restarted cacao with
        svcadm restart svc:/application/management/common-agent-container-1:default
but could still connect with
        /usr/sfw/bin/openssl s_client -connect localhost:11163 -cipher RC4
I got the cipher RC4-SHA.

This means, it was definitely the wrong configuration file. Where can I 
configure this?

------

After some investigation, we came down to this not being such a problem, as they only got a weak cypher if they requested it - the system negotiated the strongest cipher available to both client and server.  And this still didn't allow breaking of authorisation, it just covered how the communication was encrypted.  The customer also misread what they were getting as DES, when it was actually 3DES, which they're satisfied with.

But it still leaves open the question about how they can configure all the providers across the system to effectively ban the use of weak ciphers if they want to?  This RFE is to request that functionality.
We addressed the request in the fix of CR 6916074 with a more general solution.
Comments
EVALUATION Understood that the RFE is asking for an administrative configuration interface, perhaps something like the PKCS11 interface.
07-07-2008
EVALUATION I've discussed this with the customer, and this isn't a solution. SSLSocket.setEnabledCipherSuites() clearly only works per connection, and so can't be used from the customer side. It might be of use to the Cacao developers to limit what they'll accept, but it doesn't provide a means for a sysadmin to control what the system uses as a whole. Maybe the problem has been misunderstood? The customer is not looking to control single connections themselves, they're looking to tell Java as a whole what it can and can't use. It certainly can't be closed on this.
02-07-2008
EVALUATION This is really more of a JSSE issue, I think, rather than JCE. Moving to that category. What they seem to be most concerned with is "how can I disable certain ciphersuites." See below. > that several Sun Cluster components are registered in this thing. So it is > unlikely, that we can disable it. First question: is this right? Do we have > to live with the service ...and... > When we can disable it, we would obviously prefer this. How does this work? > A developer told me, he disabled it with > svcadm disable svc:/application/management/common-agent-container-1:default > but after a reboot it was running again. I do not know, we don't have the expertise in this area, you should contact the Common Agent Container team(s). > Second question: What do I have to configure, to get an error in this case? > I still want to be able to connect with things like "-cipher AES" but DES (and > everything with too few key bits) should be disabled. By using the SSLSocket.setEnabledCipherSuites(), you can disable all of the ciphersuites you feel are not secure enough for your purposes. If you're using the HttpsURLConnection, you can also use the https.cipherSuites system property to select which suites are available in the default case. > I played around with > /usr/jdk/instances/jdk1.5.0/jre/lib/security/sunpkcs11-solaris.cfg Yes, that will disable all access to *ALL* of the RC4 algs implementations supplied by the PKCS11 provider. But that probably doesn't do what you want...again, see below... > This means, it was definitely the wrong configuration file. Where can I > configure this? If you do a "which java", you'll probably be pointed at the proper version, which should be part of the <java-home> environment. > After some investigation, we came down to this not being such a problem, Unlike the algorithms named DES and 3DES, some JCE algorithm names do not have specific key lengths attached to them. e.g. AES can be 128 or 256 bit, and still uses the same algorithm name. In SSL/TLS, algorithms like this have predetermined sizes. RSA_EXPORT is used in places, which is a 40bit RSA. Same with 40 bit RC4. So you would probably want to disable the ciphersuites with that name. That is, the following cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 > But it still leaves open the question about how they can configure all the > providers across the system to effectively ban the use of weak cyphers if they want > to? This RFE is to request that functionality. See above, the SSLSocket.setEnabledCipherSuites can be used to disable these suites.
01-07-2008