Java SSL DH Keypair Generation - Prime Size Error

Question

I'm currently implementing Reddit OAuth2 login into my web app. The handshake and token exchange work fine when testing locally but when running on the server (hosted on 'OpenShift' DIY cartridge) I get the following error:

java.security.InvalidAlgorithmParameterException: Prime size must be 
multiple of 64, and can only range from 512 to 1024 (inclusive)

Which is results in

java.lang.RuntimeException: Could not generate DH keypair 

I've been searching most of the day and have found different solutions ranging from changing Java version to using BouncyCastle. However, I'm using the Scribe library so I don't think I can implement BouncyCastle without forking and changing the base of scribe, which kind of defeats it's purpose.

Installing JCE Unlimited Strength also came up but I can't do that on OpenShift as there's no root access (might be able to get one of their team to do it).

The java versions in use are (taken from java -version):

Local Testing Machine:

java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.4) (7u51-2.4.4-1ubuntu1)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

OpenShift Server:

java version "1.7.0_51"
OpenJDK Runtime Environment (rhel-2.4.4.1.el6_5-i386 u51-b02)
OpenJDK Server VM (build 24.45-b08, mixed mode)

I'm at a loss as to what I can do to solve this. Hopefully I'm being stupid or am misunderstanding something, so any possible solutions would be great!

--

EDIT 1

The request code that returns the error (using Scribe, as I mentioned, so might not be much use). The token endpoint is https://ssl.reddit.com/api/v1/access_token using POST. As I said above, this works on my testing machine.

OAuthRequest request = new OAuthRequest(getAccessTokenVerb(), getAccessTokenEndpoint());

request.addHeader("Authorization", "Basic"
    +Base64.encode((config.getApiKey()+":"+config.getApiSecret()).getBytes()));

request.addBodyParameter("state", "none");
request.addBodyParameter(OAuthConstants.SCOPE, config.getScope());
request.addBodyParameter(OAuthConstants.CLIENT_ID, config.getApiKey());
request.addBodyParameter(OAuthConstants.REDIRECT_URI, config.getCallback());
request.addBodyParameter(OAuthConstants.CODE, verifier.getValue());
request.addBodyParameter("grant_type", "authorization_code");

Response response = request.send();  // Errors here from Request.createConnection in the Scribe code
return getAccessTokenExtractor().extract(response.getBody());

Answer 1

First, "Unlimited Strength" is irrelevant here. That would fix the entirely different problem that you can't use cipher suites using AES-256 (and if the peer insists on them can't handshake at all). Also bitsize of the JVM doesn't matter; this (not really justified) restriction on DH is in the "run-everywhere" bytecode in SunJCE.

You can use BouncyCastle as a crypto provider without changing the code that does SSL connections (in your case Scribe), but from what I've read making BC the preferred provider causes other problems. If you want to try anyway, either put bcprov-version.jar in JRE/lib/exit and edit JRE/lib/security/java.security; or put it anywhere in your classpath and have your init code call java.security.Security.insertProviderAt (new org.bouncycastle.jce.provider.BouncyCastleProvider(), position);

I suggest starting from why your local system DOES work. When I try ssl.reddit.com with openssl, it supports both ECDHE-RSA (with P-256) and DHE-RSA with dh 2048 bits. Suncle Java 7 does support and prefer ECDHE, and I would expect OpenJDK also does but maybe not or maybe sometimes not; I know RedHat until recently nobbled ECC in its rpms of openssl, and it wouldn't astonish me if they did so in openjdk also. If you compile and run the following (with ssl.reddit.com 443) it will tell what suite gets negotiated on your system, using all default SSL settings of your JRE (which I expect/hope Scribe is also using):

//nopackage DThompson 2012.08.13b
import java.net.InetSocketAddress;
import java.net.Socket;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;

public class JustBConnectSSL {

    /* (optionally bind and) just make SSL connection, for testing reach and trust
     * uses default providers, truststore (normally JRE/lib/security/[jsse]cacerts), 
     * and keystore (normally none), override with -Djavax.net.ssl.{trust,key}Store* 
     */
    public static void main (String[] args) throws Exception {
        if( args.length < 2 ){ System.out.println ("Usage: tohost port [fromaddr [fromport]]"); return; }
        Socket sock = SSLSocketFactory.getDefault().createSocket();
        if( args.length > 2 )
            sock.bind (new InetSocketAddress (args[2], args.length>3? Integer.parseInt(args[3]): 0));
        sock.connect (new InetSocketAddress (args[0], Integer.parseInt(args[1])));
        System.out.println (sock.getInetAddress().getHostName() + " = " + sock.getInetAddress().getHostAddress());
        ((SSLSocket)sock).startHandshake();
        System.out.println ("connect okay " + ((SSLSocket)sock).getSession().getCipherSuite());
    }
}

If test gets _DHE_RSA_something, the crypto providers in your JRE must be different from the Suncle ones, either changed by Ubuntu or some customization or patch on your system. If test gets _ECDHE_RSA_something but OpenShift doesn't, they may have disabled ECC/ECDHE somehow. If they can enable that's best (ECDHE-P-256 is at least as secure and probably more efficient than DH-2048). Otherwise until Oracle fixes this (apparently in 8) the only way I think can be relied on is to disable DHE suites (and drop back to plain RSA, which may not be safe against NSA); that is simplest in the code that actually creates the SSLSocket, but if Scribe (like most java web clients) uses URL -> HttpsUrlConnection with its default SSLSocketFactory you can substitute a tweaked factory that changes the EnabledCiphers list along the lines of question #6851461 (although for a host with a good public certificate you don't need the custom-trustmanager parts of that solution).

Answer 2

I know I am very late to answer this but I was struggling with the similar problem and then solved it. My solution is for MAC-OS.

1. Install Bouncy Castle jar from http://www.bouncycastle.org/latest_releases.html, in /Library/Java/JavaVirtualMachines//Contents/Home/jre/lib/ext
2. edit java.security file add the below line security.provider.2=org.bouncycastle.jce.provider.BouncyCastleProvider and then reorder all the other providers you may have.
3. voila

Answer 3

I solved the problem on oracle java 8 by switching to bouncycastle provider for ssl/tls:

1. Added bouncycastle to my project

   <dependency>
       <groupId>org.bouncycastle</groupId>
       <artifactId>bcprov-jdk15on</artifactId>
       <version>1.54</version>
   </dependency>
   

2. Before I do any SSL stuff, I add the BouncyCastle provider as 1st provider to the list:

   Security.insertProviderAt(new BouncyCastleProvider(),1);
   

That's all. Now my connections to sites with 4096 bit DH parameters works as expected (I'm using Apache HTTP Client). This should also work with jdk 7.