Oracle Java 8 x64 für Linux und RandomSource

Question

Ich dachte wirklich, dass nach etwa 200 oder mehr Tomcat-Installationen auf verschiedenen Plattformen, bin ich bereit für jede Art von Herausforderung, aber diese ist knifflig.

Ich habe eine Vanille Ubunutu 14_04 Bild erstellt und Java 8 TGZ von Oracle auf diesem System installiert. Außerdem habe ich dem Spiel einen Kater 8 hinzugefügt. Dann habe ich mit der Installation des Vanilla-Servers begonnen.

Bald nachdem ich mit der Bereitstellung der Standard-Apps, die mit Tomcat ausgeliefert wurden, beschäftigt war, fragte ich mich, was dort passiert und machte ein paar Threaddumps. Dies war der miesen Faden, den Kater von Ausgang verhindert:

"localhost-startStop-1" #15 daemon prio=5 os_prio=0 tid=0x00007f37c8004800 nid=0x4d6 runnable [0x00007f37b38b3000] 
    java.lang.Thread.State: RUNNABLE 
    at java.io.FileInputStream.readBytes(Native Method) 
    at java.io.FileInputStream.read(FileInputStream.java:246) 
    at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539) 
    at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144) 
    at sun.security.provider.SecureRandom$SeederHolder.<clinit>(SecureRandom.java:192) 
    at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:210) 
    - locked <0x00000000f06e6ce8> (a sun.security.provider.SecureRandom) 
    at java.security.SecureRandom.nextBytes(SecureRandom.java:457) 
    - locked <0x00000000f06e71c0> (a java.security.SecureRandom) 
    at java.security.SecureRandom.next(SecureRandom.java:480) 
    at java.util.Random.nextInt(Random.java:329) 
    at org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom(SessionIdGeneratorBase.java:234) 

Nach mehr & Freunde google ich entdecken, dass die SeedGenerator mit dem JDK ausgeliefert ist die Quelle meines Problems. Interessanterweise kam der SeedGenerator nach einigen Minuten zurück und manchmal hing er einfach (Entropie ausgegangen? ... überprüft über cat /proc/sys/kernel/random/entropy_avail). Nach weiteren Recherchen fand ich heraus, dass eine Konfigurationsvariable in $JAVA_HOME$/lib/security/java.security namens securerandom.source definiert, was die Quelle für Random ist. In meinem Fall, oder besser im Oracle JDK 8 für Linux installieren, war es /dev/random. Ich bin kein Linux-Experte (ich bin ein Java-Entwickler), aber was ich verstanden habe, ist, dass /dev/random Entropie ausgehen kann (was auch immer das bedeutet), aber vielleicht bedeutet es irgendwann, dass es keine Zufallszahlen mehr erzeugen kann). Ich wechselte zu /dev/urandom und alles war gut mit meinem Kater.

Dann habe ich überprüft, wie andere JDK-Installationen auf meinem anderen verschiedenen Server aussehen, die eine wilde Mischung aus OpenJDK und älteren Oracle JDK-Installationen waren. Zumindest OpenJDK verwendet immer /dev/urandom was könnte die Antwort sein, warum ich das Problem vorher noch nie hatte.

Nun zu meiner Frage: Ist es von Oracle vernünftig, sich auf /dev/random zu verlassen, wenn es Fälle geben kann, in denen das OS keine Zahlen mehr produzieren kann? Ich meine Server wie Tomcat und viele andere verlassen sich auf SeedGenerator aus dem JDK und Debuggen dieser Art von Fehler ist wirklich fortgeschritten. Nahm mich zwei Stunden, um zu dem Punkt zu kommen, wo ich jetzt bin.

Answer 1

Ich denke, die Antwort in diesem Link verlässt sich für WebLogic-Unterstützung: https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html wo sie erwähnen, dass "random" ist sicherer

und auch in der Oracle-Bug Kommentar (bereits von David erwähnt): http://bugs.java.com/view_bug.do?bug_id=4705093

insbesondere im Hinblick auf diesen Teil:

Weil SHA1PRNG ein Messagebasierte PRNG ist, er in der Vergangenheit immer dann verwendet/dev/random für die anfängliche seeding wenn seed-Daten b bereitgestellt wurden nicht y die Anwendung. Da alle zukünftigen Werte vom vorhandenen Status des MessageDigest abhängen, ist es wichtig, mit einem starken Anfangswert zu beginnen.

Das Ändern dieses Verhaltens war für den ursprünglichen Entwickler problematisch. Also hat er ein neues SecureRandom-Impl namens NativePRNG erstellt, das den java.security.egd-Wert berücksichtigt.

Wenn Sie rufen:

• neue Secure() auf Linux und die Standardwerte verwendet werden, ist es von/dev/urandom gelesen wird und blockieren nicht. (Standardmäßig wird unter Solaris das PKCS11 SecureRandom verwendet und auch in/dev/urandom aufgerufen.)

• SecureRandom.getInstance ("SHA1PRNG") und haben keinen Samen, OR neue Secure() angeben, aber eine alternative java.security.egd neben "file:/dev/urandom" angegeben ist, wird es Verwende den SHA1PRNG, der/dev/random aufruft und möglicherweise blockieren kann.

• SecureRandom.getInstance ("NativePRNG"), hängt davon ab, worauf java.security.egd zeigt.

Answer 2

, was ich verstanden, dass/dev/random aus Entropie laufen kann (was auch immer das bedeutet), aber vielleicht bedeutet es irgendwann es nicht mehr Zufallszahlen erzeugen kann nicht).

Es kann vorübergehend Lauf aus Entropie und blockieren, bis es genug sammelt mehr verzichtet werden. Die JVM benötigt nur ein wenig, um eine SecureRandom Instanz zu erstellen.

Wie lange es dauert hängt davon ab, wie laut Ihr System ist und wie der Kernel Entropie sammelt.

Ist es von Oracle vernünftig, sich auf/dev/random zu verlassen, wenn es Fälle gibt, in denen das Betriebssystem keine weiteren Zahlen mehr produzieren kann?

Der Mangel an Entropie kann auf Embedded-Systemen oder in VMs beim ersten Start problematisch sein, die mit einem sehr deterministischen Bild kommen, haben nur wenige Quellen der Entropie, die auf reale PCs und keine RDRAND Anweisung oder ähnlich verglichen wird geernteten der Kernel, der für die Initialisierung des Entropiepools geerntet werden soll.

Eine unzureichende Zufälligkeit kann für die Schlüsselgenerierung und andere kryptografische Algorithmen katastrophal sein, z. DSA is quite sensitive to the quality of your entropy source.

Also ja, es ist ziemlich vernünftig, eher zu warten, als ein kompromittiertes System zu haben.

Um zu zitieren von Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices von N.Heninger et al.

Um zu verstehen, warum diese Probleme auftreten, werden, wir manuell Hunderte der anfälligen Wirten untersucht, die als jede der privaten Schlüssel als auch Vertreter der am häufigsten wiederholten Schlüssel waren wir erhalten (§ 3.2) . Nahezu alle Informationen dienten als Headless- oder Embedded-Systeme, einschließlich Routern, Server-Management-Karten, Firewalls und anderen Netzwerkgeräten. Solche Geräte erzeugen normalerweise automatisch Schlüssel beim ersten Booten und können Entropiequellen im Vergleich zu herkömmlichen PCs haben. Wenn wir Cluster von Hosts untersuchten, die einen Schlüssel oder einen Faktor gemeinsam hatten, schienen diese in fast allen Fällen durch einen Hersteller oder ein Gerätemodell verbunden zu sein. Diese Beobachtungen führen uns zu dem Schluss, dass die Probleme durch spezifische defekte Implementierungen verursacht werden, die Schlüssel generieren, ohne genügend Entropie gesammelt zu haben.

Wenn Sie eine externe Quelle der Entropie und Root-Rechte besitzen, können Sie push additional entropy into the pool and increment its counter (ich glaube rngd kann dies für Sie tun). Wenn Sie nur /dev/random schreiben, wird Ihre Entropie dem Pool hinzugefügt, der Zähler jedoch nicht erhöht.

Für VMs gibt es auch virtualization drivers Entropie vom Host zu erhalten.

Das Zeigen der jvm zu einer Hardware RNG dev (/ dev/hwrng,/dev/misc/hw_random oder etwas Ähnliches) kann auch eine Wahl sein, wenn sie verfügbar sind.