Oracle Java 8 x64 для Linux и RandomSource

Я действительно думал, что после того, как 200 или более tomcat установит на разных платформах, я готов к любым вызовам, но это сложно.

Я создал изображение Vanilla Ubunutu 14_04 и установил Java 8 TGZ из oracle в этой системе. Кроме того, я добавил кота 8 в игру. Затем я начал установку сервера ванили.

Вскоре после развертывания приложений по умолчанию, поставляемых с tomcat, я задавался вопросом, что происходит там и какие-то потоки. Это была паршивая нить, которая не позволила кошке начать:

"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)

После того, как Google и друзья узнали, что SeedGenerator, поставляемый с JDK, является источником моей проблемы. Интересно, что иногда SeedGenerator возвращался через несколько минут, а иногда просто зависал (заканчивался энтропия?... проверен через cat /proc/sys/kernel/random/entropy_avail). После нескольких исследований выяснилось, что переменная конфигурации в $JAVA_HOME$/lib/security/java.security, называемая securerandom.source, определяет, что такое источник для Random. В моем случае, или лучше, в oracle JDK 8 для linux, это было /dev/random. Я не эксперт по Linux (я разработчик Java), но я понял, что /dev/random может закончиться энтропией (что бы это ни значило), но, возможно, это означает, что в какой-то момент он не может генерировать более случайные числа). Я переключился на /dev/urandom, и все было в порядке с моим tomcat.

Затем я проверил, как другие установки JDK выглядят как на моем другом сервере, который был диким сочетанием OpenJDK и устаревшей установки Oracle JDK. По крайней мере OpenJDK всегда использовал /dev/urandom, что может быть ответом, почему у меня никогда не было проблемы раньше.

Теперь на мой вопрос: разумно ли из Oracle полагаться на /dev/random, когда могут быть угловые случаи, когда OS can not производит больше чисел? Я имею в виду серверы, такие как Tomcat, и многие другие полагаются на SeedGenerator из JDK, и отладка такого рода ошибок действительно продвинута. Принял меня 2 часа, чтобы добраться до того, где я сейчас.

Ответ 1

Я думаю, что ответ полагается на эту ссылку для поддержки WebLogic: https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html где они упоминают, что "случайный" более безопасен

а также в комментарии к ошибке Oracle (уже упоминается Дэвидом): http://bugs.java.com/view_bug.do?bug_id=4705093

с особым учетом этой части:

Поскольку SHA1PRNG является PRNG на основе MessageDigest, он исторически всегда использовал /dev/random для начального посева, если исходные данные не были предоставлены приложением. Поскольку все будущие значения зависят от существующего состояния MessageDigest, важно начать с сильного начального семени.

Изменение этого поведения беспокоило первоначального разработчика. Таким образом, он создал новый SecureRandom impl, называемый NativePRNG, который уважает значение java.security.egd.

Если вы вызываете:

new SecureRandom() в Linux и значения по умолчанию используются, он будет читать /dev/urandom, а не блокировать. (По умолчанию в Solaris используется PKCS11 SecureRandom, а также вызывает /dev/urandom.)

SecureRandom.getInstance( "SHA1PRNG" ) и не указывайте семя, или новый SecureRandom(), но указали альтернативный файл java.security.egd, кроме "file:/dev/urandom", он будет использовать SHA1PRNG, который вызывает /dev/random и может потенциально блокироваться.

SecureRandom.getInstance( "NativePRNG" ), это будет зависеть от того, на что указывает java.security.egd.

Ответ 2

я понял, что /dev/random может закончиться энтропией (что бы это ни значило), но, возможно, это означает, что в какой-то момент он не может генерировать более случайные числа).

Он может временно закончиться энтропией и заблокировать до тех пор, пока он не соберет достаточно, чтобы распределить больше. JVM нужно немного, чтобы засеять экземпляр SecureRandom.

Сколько времени это займет, зависит от того, насколько шумна ваша система и как ядро собирает энтропию.

Является ли разумным из Oracle полагаться на /dev/random, когда могут быть угловые случаи, когда OS can not производит больше чисел?

Отсутствие энтропии может быть проблематичным для встроенных систем или виртуальных машин при первой загрузке, которые имеют очень детерминированный образ, имеют мало источников энтропии, которые можно собирать по сравнению с реальными ПК, а также никакой инструкции RDRAND или аналогичной для ядра урожай для инициализации пула энтропии.

Недостаточная случайность может быть катастрофической для генерации ключей и других криптографических алгоритмов, например. DSA довольно чувствительна к качеству вашего источника энтропии.

Так что да, вполне разумно скорее ждать, чем иметь скомпрометированную систему.

Для цитаты из Mining Your Ps и Qs: обнаружение широко распространенных слабых клавиш в сетевых устройствах от H.Heninger и др.

Чтобы понять, почему эта проблема возникает, мы вручную исследовали сотни уязвимых хостов, которые были представитель наиболее часто повторяющихся ключей, а также каждый частных ключей, которые мы получили (раздел 3.2). Почти вся обслуживаемая информация идентифицирует их как безголовые или встроенные системы, включая маршрутизаторы, серверные карты управления, брандмауэры и другие сетевые устройства. Такие устройства обычно генерировать ключи автоматически при первой загрузке и могут быть ограничены энтропийных источников по сравнению с традиционными ПК.

Кроме того, когда мы рассмотрены кластеры хостов, которые разделяют ключ или фактор, почти во всех случаи, которые, по-видимому, связаны между собой производителем или моделью устройства. Эти наблюдения позволяют сделать вывод о том, что проблемы вызваны специфические дефектные реализации, которые генерируют ключи без собрал достаточную энтропию.

Если у вас есть внешний источник энтропии и привилегии root, вы можете вставить дополнительную энтропию в пул и увеличить счетчик (думаю, rngd может сделать это для вы). Просто запись в /dev/random добавит вашу энтропию в пул, но не увеличит счетчик.

Для виртуальных машин также есть драйверы виртуализации, чтобы получить энтропию от хоста.

Указание jvm на аппаратное RNG dev (/dev/hwrng,/dev/misc/hw_random или что-то в этом роде) также может быть вариантом, если они доступны.