Disabling weak ciphers on a Linux JSS - how do you make sense of it?

[mwright]

I'm curious how other CentOS- or RHEL-hosted JSS admins are handling this.

I recently found that the JAMF article Configuring Supported Ciphers for Tomcat HTTPS Connections is only partially effective in my environment. We run a CentOS cluster that was set up using the manual installation/config guide. As recommended in release notes, we use OpenJDK and Tomcat 7.

The core problem I find with limiting tomcat to the recommended ciphers is that OpenJDK doesn't have them. I see two approaches to working around this, adding BouncyCastle as an OpenJDK provider, or using some other JDK (Oracle?).

I've got the BouncyCastle option working in my environment. but not how I would have expected. Because JAMF bundles a version of the bc provider in the jss web app, installing the latests bc provider in $JAVA_HOME/lib/ext/ causes some strange behavior. Instead, I symlinked to from $JAVA_HOME/lib/ext/bcprov.jar to .../tomcat/webapps/root/WEB-INF/lib/bcprov.jar, then referenced the provider in java.security as normal. This seems to be working well in that the web app initializes normally, and can access the recommended cipher set.

Aside from the obvious maintenance concerns this raises around updates(etc), how bad an idea do you find the BouncyCastle symlink workaround? What alternatives do you prefer?

[andykang]

Hi @mwright

Did you ever find a better solution to this? I'm seeing issues with iOS Self Service not able to connect to our server and I think it's because of this.

[bentoms]

@andykang maybe this will help: https://www.jamf.com/jamf-nation/articles/384/configuring-supported-ciphers-for-tomcat-https-connect...

[andykang]

Hi @bentoms,

I've got those in my server.xml, but only this one is actually supported by OpenJDK 8:

In addition, if you are running Java 1.6 or a JDS instance in your environment, you must also include the following cipher: TLS_RSA_WITH_AES_128_CBC_SHA

When this is removed, Tomcat fails to start because of SSL handshake errors. I found this out when I tried to get the iOS Self Service app working. The webclip works, but the app gets a server communication error.

[bentoms]

@andykang ah, odd.

We're hosted on Ubuntu & do not need that cipher.

[aurica]

I also had this problem. OpenJDK didn't have the necessary support for elliptic curve and was causing a lot of trouble, especially with iOS. Switching to Oracle Java resolved it. Chris Meyer wrote a very useful article exploring the cause: "How to use ECC with OpenJDK"

... The reason for this is hidden in the provider's code. The following lines are taken from sun.security.ec.SunEC:

private static final long serialVersionUID = -2279741672933606418L;

// flag indicating whether the full EC implementation is present
// (when native library is absent then fewer EC algorithms are available)
private static boolean useFullImplementation = true;
static {
    try {
        AccessController.doPrivileged(new PrivilegedAction() {
            public Void run() {
               System.loadLibrary("sunec"); // check for native library
               return null;
            }
        });
    } catch (UnsatisfiedLinkError e) {
        useFullImplementation = false;
    }
}

public SunEC() {
    super("SunEC", 1.7d, "Sun Elliptic Curve provider (EC, ECDSA, ECDH)");

    // if there is no security manager installed, put directly into
    // the provider. Otherwise, create a temporary map and use a
    // doPrivileged() call at the end to transfer the contents
    if (System.getSecurityManager() == null) {
        SunECEntries.putEntries(this, useFullImplementation);
    } else {
        Map<Object, Object> map = new HashMap<Object, Object>();
        SunECEntries.putEntries(map, useFullImplementation);
        AccessController.doPrivileged(new PutAllAction(this, map));
    }
}

Additionally, the following can be found in SunECEntries class, after some entries have been added to the list:

/
  Register the algorithms below only when the full ECC implementation
  is available
 /
if (!useFullImplementation) {
    return;
}

Ok, this explains the behaviour. The algorithms are only present if a native library could be successfully loaded...

[andykang]

Thanks @aurica

We switched to Oracle Java along with the JCE policy and it is now working with all ciphers.