idp.jks not created

[Nigel Sheridan-Smith]

These messages from earlier this month weren't approved by the list
moderator (posted through Nabble.com).

Original thread here:

http://shibboleth.1660669.n2.nabble.com/idp-jks-not-created-td7613402.html

This might catch out other people who install Oracle Java 8 with Shibboleth.

Cheers,
Nigel

---

I've spent quite a few weeks attempting to get the IdP v2.4.4 and v3.1.1
working - with limited success. On one host it would fail consistently, but
on a clean AWS Ubuntu server it would at least get further along.

It turns out that using Java 8 changes the default SecureRandom behaviour,
resulting in both Tomcat and Jetty hanging on startup if the server's
entropy has run out. On Jetty, you won't even get the TCP ports to open
(8080 / 8443, or 80 / 443, depending on your configuration).

Earlier versions of Java used /dev/urandom by default, which would not hang
if entropy ran out.

http://security.stackexchange.com/questions/40633/java-securerandom-doesnt-block-how

To confirm this problem, send a kill -3 to your tomcat process and the
catalina.out log file will show a deadlock here:


"localhost-startStop-1" daemon prio=10 tid=0x00007f4b48002000 nid=0x36aa
runnable [0x00007f4b43ffa000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:272)
        at
sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:551)
        at
sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:139)
        at
sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:197)
        at
sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:214)
        - locked <0x00000000edaff5b0> (a
sun.security.provider.SecureRandom)
        at java.security.SecureRandom.nextBytes(SecureRandom.java:455)
        - locked <0x00000000edaff8c8> (a java.security.SecureRandom)
        at
org.opensaml.common.impl.SecureRandomIdentifierGenerator.generateIdentifier(SecureRandomIdentifierGenerator.java:62)
        at
edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.attributeDefinition.TransientIdAttributeDefinition.<init>(TransientIdAttributeDefinition.java:78)


Cheers,
Nigel


---

Actually I've looked at this further, and its actually the choice of the
'blocking' random-number generator on Java 8 on Linux. If you switch this
to NativePRNGNonBlocking, then the deadlock doesn't occur.

In jre/lib/security/java.security:

securerandom.strongAlgorithms=NativePRNGBlocking:SUN

... can become:

securerandom.strongAlgorithms=NativePRNGNonBlocking:SUN

Presumably this is a 'secure by default' setting, but a bizarre choice
since it basically will bite anyone that installs any Java 8 software on
Linux that requires secure random number generation, with no exception or
error message presented to the unlucky devops person.

Further information here:

https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html
http://openjdk.java.net/jeps/123
http://stackoverflow.com/questions/23713640/working-only-with-dev-random-in-java

Cheers,
Nigel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150719/0c7d0299/attachment-0001.html>