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
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
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
I had a short look at the source code
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
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
where some disabled algorithms for Java are listed and added all constants
with RC4 in them from /usr/include/security/pkcs11t.h
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
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
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.