services elastic aws java security amazon-web-services tomcat spring-boot

java - elastic - spring boot controller service repository



Tomcat tarda demasiado en iniciarse-Java SecureRandom (2)

Por favor, no lo marque como duplicado. Es una pregunta de seguimiento para ambas preguntas.

Entiendo que, reemplazando

securerandom.source=file:/dev/urandom

con

securerandom.source=file:/dev/./urandom

en $JAVA_PATH/jre/lib/security/java.security resolveremos este problema.

Mi pregunta es, ¿está bien hacerlo en producción? ¿Tendrá esto algún impacto en la seguridad (como que la ID de sesión sea predecible)? Si esto es menos seguro, ¿hay alguna otra manera de dar suficiente entropía más rápido?

Actualizar

Uso openstack para la implementación (o digamos, utiliza AWS o GCP o cualquier otro proveedor de la nube). Por lo tanto, agregar un dispositivo de hardware como una tarjeta de sonido no es una opción para mí.

Después de algunas búsquedas extensas en Google con los términos de búsqueda correctos, me encontré con este bonito artículo en DigitalOcean . Simplemente estoy citando la parte relevante aquí.

Hay dos dispositivos aleatorios generales en Linux: / dev / random y / dev / urandom. La mejor aleatoriedad proviene de / dev / random, ya que es un dispositivo de bloqueo, y esperará hasta que haya suficiente entropía disponible para continuar proporcionando salida. Suponiendo que su entropía es suficiente, debería ver la misma calidad de aleatoriedad de / dev / urandom; sin embargo, como es un dispositivo no bloqueante, continuará produciendo datos "aleatorios", incluso cuando se agote el grupo de entropía. Esto puede dar como resultado datos aleatorios de menor calidad, ya que es mucho más probable que se repitan datos anteriores. Muchas cosas malas pueden suceder cuando la entropía disponible se queda baja en un servidor de producción, especialmente cuando este servidor realiza funciones criptográficas.

Por lo tanto, es un riesgo potencial de seguridad.

Solución para poblar grupos de entropía

Linux ya obtiene datos aleatorios de muy buena calidad de las diferentes fuentes de hardware, pero como una máquina sin cabeza generalmente no tiene teclado ni mouse, se genera mucho menos entropía. Las E / S de disco y red representan la mayoría de las fuentes de generación de entropía para estas máquinas, y producen cantidades muy escasas de entropía. Dado que muy pocas máquinas sin cabeza como servidores o servidores en la nube / máquinas virtuales tienen algún tipo de solución de RNG de hardware disponible, existen varias soluciones de usuario para generar una entropía adicional mediante interrupciones de hardware desde dispositivos que son "más ruidosos" que los discos duros, como tarjetas de video, tarjetas de sonido, etc. Esto, una vez más, demuestra ser un problema para los servidores, desafortunadamente, ya que no suelen contener ninguno

Solución: hasged

Basado en el principio HAVEGE, y anteriormente basado en su biblioteca asociada, hasged permite generar aleatoriedad basada en variaciones en el tiempo de ejecución del código en un procesador. Dado que es casi imposible que una pieza de código tarde en ejecutarse exactamente el mismo tiempo, incluso en el mismo entorno en el mismo hardware, el tiempo de ejecución de uno o varios programas debería ser adecuado para generar una fuente aleatoria. La implementación hasged siembra la fuente aleatoria de su sistema (generalmente / dev / random) usando diferencias en el contador de marca de tiempo (TSC) de su procesador después de ejecutar un ciclo repetidamente

Cómo instalar hasged

Siga los pasos en este artículo. DigitalOcean

Si alguien esta teniendo este problema

Acabo de resolver el mío simplemente eliminando todos los BREAKPOINTS del depurador.