You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Martin Hamant <mh...@ow2.org> on 2014/10/03 11:26:56 UTC
SecureRandom instance for session ID generation using [SHA1PRNG]
took [510,962] milliseconds !
Hi there,
Here is my config
Server version: Apache Tomcat/8.0.14
Server built: Sep 24 2014 09:01:51
Server number: 8.0.14.0
OS Name: Linux
OS Version: 3.13.0-36-generic
Architecture: amd64
JVM Version: 1.7.0_65-b32
JVM Vendor: Oracle Corporation
The virtual (qemu) server runs with 4GB RAM
I have two tomcat instances running on the same server with setenv.sh
set to:
-Xmx800m -XX:MaxPermSize=192m
Here is my problem:
I have two configured instances on this server
After some time playing with stopping and starting with those instances
began to take AGES to startup (~10min)
03-Oct-2014 09:11:05.973 INFO [localhost-startStop-1]
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom
Creation of Sec
ureRandom instance for session ID generation using [SHA1PRNG] took
[510,962] milliseconds.
(...)
03-Oct-2014 09:11:41.134 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in 547454 ms
Thread which takes age running SeedGenerator :
"localhost-startStop-1" daemon prio=10 tid=0x00007fe3ac001800 nid=0x580b
runnable [0x00007fe3b55da000]
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)
(...)
Workaround:
I tried to add -Djava.security.egd=file:/dev/./urandom with success (in
setenv.sh).
But why would I *suddendly* have to use this additional param ? Never
got this problem in tomcat before...
Could it be linked to the VM ?
Thanks
Re: SecureRandom instance for session ID generation using
[SHA1PRNG] took [510,962] milliseconds !
Posted by Martin Hamant <mh...@ow2.org>.
Le 03/10/2014 20:41, Rainer Jung a écrit :
> Am 03.10.2014 um 14:01 schrieb Christopher Schultz:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Martin,
>>
>> On 10/3/14 5:48 AM, Martin Hamant wrote:
>>> Le 03/10/2014 11:26, Martin Hamant a écrit :
>>>>
>>>>
>>>> The virtual (qemu) server runs with 4GB RAM
>>>
>>> Sorry, The hypervisor is KVM. The VM is running on top of
>>> OpenStack So... This could lead somewhere as I am reading
>>> http://blog.dustinkirkland.com/2012/10/entropy-or-lack-thereof-in-openstack.html
>>>
>>
>> OpenStack
>>>
>> or not, running on a VM usually means that the underlying OS
>> is providing the source of entropy. If your physical machine is
>> heavily virtualized, you may have multiple entropy sinks constantly
>> draining your source(s() of entropy.
>>
>> If you wait for a while, things will recover. If you find you are
>> constantly blocking waiting for more randomness to be available from
>> your random source, you basically have 3 options:
>>
>> 1. Suffer through it. Just keep waiting.
>>
>> 2. Use a poor source of randomness, like /dev/urandom on Linux.
>> I wouldn't recommend this for any kind of production deployment,
>> since the entropy source is "watered-down". You can't rely on it
>> for important things like encryption (including SSL) and really
>> anything that requires random numbers that are as random as
>> possible (like session ids).
>>
>> 3. Get yourself a hardware entropy source. You can buy USB keys that
>> do this kind of thing. Make sure whatever you get is compatible
>> with your OS and accessible by Java (better yet, get one that will
>> simply dump its randomness into /dev/random).
>
> ... and in case you are heading for the urandom solution and are sing
> JDK before 8, you should use e.g.
Thanks both of you for your help.
>
> -Djava.security.egd=file:/dev//urandom
>
> and *not*
>
> -Djava.security.egd=file:/dev/urandom
And what about using haveged (so no need to alter setenv.sh) in the VM
VS using /dev/urandom ?
I read about it here
http://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines
The small C program returns values between 20-30 in my VM, but as
specified it doesn't guarantee anything...
- Waiting 10min for a tomcat to start is a pain
- getting a USB hardware device for that is like walking on head.
So... I consider using haveged or urandom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SecureRandom instance for session ID generation using [SHA1PRNG]
took [510,962] milliseconds !
Posted by Rainer Jung <ra...@kippdata.de>.
Am 03.10.2014 um 14:01 schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Martin,
>
> On 10/3/14 5:48 AM, Martin Hamant wrote:
>> Le 03/10/2014 11:26, Martin Hamant a écrit :
>>>
>>>
>>> The virtual (qemu) server runs with 4GB RAM
>>
>> Sorry, The hypervisor is KVM. The VM is running on top of
>> OpenStack So... This could lead somewhere as I am reading
>> http://blog.dustinkirkland.com/2012/10/entropy-or-lack-thereof-in-openstack.html
>
> OpenStack
>>
> or not, running on a VM usually means that the underlying OS
> is providing the source of entropy. If your physical machine is
> heavily virtualized, you may have multiple entropy sinks constantly
> draining your source(s() of entropy.
>
> If you wait for a while, things will recover. If you find you are
> constantly blocking waiting for more randomness to be available from
> your random source, you basically have 3 options:
>
> 1. Suffer through it. Just keep waiting.
>
> 2. Use a poor source of randomness, like /dev/urandom on Linux.
> I wouldn't recommend this for any kind of production deployment,
> since the entropy source is "watered-down". You can't rely on it
> for important things like encryption (including SSL) and really
> anything that requires random numbers that are as random as
> possible (like session ids).
>
> 3. Get yourself a hardware entropy source. You can buy USB keys that
> do this kind of thing. Make sure whatever you get is compatible
> with your OS and accessible by Java (better yet, get one that will
> simply dump its randomness into /dev/random).
... and in case you are heading for the urandom solution and are sing
JDK before 8, you should use e.g.
-Djava.security.egd=file:/dev//urandom
and *not*
-Djava.security.egd=file:/dev/urandom
For background info look at
http://marc.info/?l=tomcat-dev&m=130182757504685&w=2
or more officially
http://bugs.java.com/view_bug.do?bug_id=6202721
and
http://openjdk.java.net/jeps/123
This has been fixed in JDK8 though (finally).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SecureRandom instance for session ID generation using [SHA1PRNG]
took [510,962] milliseconds !
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 10/3/14 5:48 AM, Martin Hamant wrote:
> Le 03/10/2014 11:26, Martin Hamant a écrit :
>>
>>
>> The virtual (qemu) server runs with 4GB RAM
>
> Sorry, The hypervisor is KVM. The VM is running on top of
> OpenStack So... This could lead somewhere as I am reading
> http://blog.dustinkirkland.com/2012/10/entropy-or-lack-thereof-in-openstack.html
OpenStack
>
or not, running on a VM usually means that the underlying OS
is providing the source of entropy. If your physical machine is
heavily virtualized, you may have multiple entropy sinks constantly
draining your source(s() of entropy.
If you wait for a while, things will recover. If you find you are
constantly blocking waiting for more randomness to be available from
your random source, you basically have 3 options:
1. Suffer through it. Just keep waiting.
2. Use a poor source of randomness, like /dev/urandom on Linux.
I wouldn't recommend this for any kind of production deployment,
since the entropy source is "watered-down". You can't rely on it
for important things like encryption (including SSL) and really
anything that requires random numbers that are as random as
possible (like session ids).
3. Get yourself a hardware entropy source. You can buy USB keys that
do this kind of thing. Make sure whatever you get is compatible
with your OS and accessible by Java (better yet, get one that will
simply dump its randomness into /dev/random).
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJULpAEAAoJEBzwKT+lPKRYkvsQAKtreSMgcqxhgWxBJRzrEtQi
Uk0J7zGLUDnggvlLSRW6JvY45BsTdKrgaIqeSVd/KGmNOtwI6ZldL/g+b6Dz26xj
W2IOxPRy9UQxiHFjmmyqxRD+ptnHE3alrcH1g0qvnTOfwjWdv/NkOB3HhOvf7Bae
7G1wQBTEOq7VKyizeEO0isEb1t9YEHvuLayM15r6qcEGFqa2GW48iG4EG48HIm+A
yKEIuh5G3+7XoQ3k/aj3g2WT6plM1BI4l39Lfun+2SOSOZlxmI9ri0X8ZhPk6+82
ARc0Y/HF4GY8rSzbQ2k5Xzvv/HbT1089BDGYLq6/E4UfRUzz3i25krE9avFj3YLh
zHEyz+a4+t+4kqIUZFdeTX1XRv39auBXwJriqkH5A4HMx0gvCfSIAktG11cDW2FX
+RlHfeGaTfxF9bii/tJnAGT1/l9i51Si4q23HVjpGMM4JgUP89GWswEcMvp0DjlT
4Hd6y8AyUO2YDuiMxlMoOrhujX3q1tvnZ3dUIzGrDXZoseaMbtKA1tqMsafdPXh6
eyWOX4sS42Es9ePoD0o9uuF5ai136866E3Yk2QFQRZWBOmqhIuf0aM0n6Kdv8GBq
aaICz0L0WtIJ/uljziSARLBl2Aecch0l61/5IwOpbLlzlfr9ZYIwb+F0zB9Dlqqq
o+yT9gLk0P7kps9eM2s+
=Kt5L
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SecureRandom instance for session ID generation using
[SHA1PRNG] took [510,962] milliseconds !
Posted by Martin Hamant <mh...@ow2.org>.
Le 03/10/2014 11:26, Martin Hamant a écrit :
>
>
> The virtual (qemu) server runs with 4GB RAM
Sorry,
The hypervisor is KVM. The VM is running on top of OpenStack
So... This could lead somewhere as I am reading
http://blog.dustinkirkland.com/2012/10/entropy-or-lack-thereof-in-openstack.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org