Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6720693

RFE: Allow the disabling of specific cipher across all providers

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 5.0u14
    • Fix Version/s: 7
    • Component/s: security-libs
    • Labels:
      None

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                xuelei Xue-Lei Fan
                Reporter:
                mbowyer Mark Bowyer (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: