RC4 and ECDHE_RSA

[Ian Young]

On 21 Aug 2013, at 10:39, Martin Haase <Martin.Haase at DAASI.de> wrote:

> This is IdP 2.4.0, Tomcat6.0.24, java-1.6.0-openjdk, RHEL6.4.
> Trying to get metadata via a https URL, that server uses RC4_128
> encryption and ECDHE_RSA for key exchange.
> 
> Starting up the IdP, it cannot fetch metadata:
> 
> javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
> generate DH keypair
> ...
> Caused by: java.security.InvalidAlgorithmParameterException: Prime size
> must be multiple of 64, and can only range from 512 to 1024 (inclusive)

I found a couple of articles around the web referring to this.  Best one was:

http://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-give-could-not-generate-dh-keypair-exception

or

http://bit.ly/14BvVqc

If I'm reading this correctly, it's a known limitation and not fixed until Java 8.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6521495

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044060

> I tried several combinations of:
> 
> * adding
> security.provider.9=org.bouncycastle.jce.provider.BouncyCastleProvider to
> $JAVA_HOME/lib/security/java.security
> 
> * adding disregardSslCertificate="true" to the MetadataProvider
> 
> * adding
> sslImplementationName="org.bouncycastle.jce.provider.BouncyCastleProvider" 
> to /etc/tomcat6/server.xml, in the relevant <Connector>

I wouldn't expect the disregardSslCertificate option to have any effect, but those articles quoted above do seem to imply that the Bouncy Castle provider does this right.  Of course, they don't actually include helpful hints about how to get Tomcat to do what you want here.

> None worked. Any ideas (besides, well, asking the provider to switch to
> plain http for the metadata location)?

I guess putting the Bouncy Castle provider higher up in the list of providers might result in it being preferred; you could try that.

Switching to http:// would obviously do it (and there's really no reason to use TLS for metadata unless the metadata is itself unsigned).  The other alternative would be to get them to use a more compatible set of cipher suites on their side.

Do you have any idea what their implementation is based on?  When things like this come up I always worry that they are advance warnings of some platform distribution's default policies, which might affect lots of people in the long run.  It's more often just a random person's individual choice, though.

	-- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20130821/424e701d/attachment.bin