[Help-gnutls] Re: gnutls 1.2.6 and Mozilla Firefox compatibility problem

[Simon Josefsson]

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Saturday 10 September 2005 10:34, Nikos Mavrogiannopoulos wrote:
>
>> The problem is that in the 2nd forked session the server tries to resume
>> the previous connection. You can check this by looking the session ID. The
>> one the server selects the second time is the same as the client requested
>> (resume). This is totally strange since there is no communication
>> between the objects (lie in a different process), so the second process
>> shoudn't even know the session ID of the first server process.
>> It seems to work ok if you move the gnutls_session_t session declaration to
>> after the forked process has been created (after if (pid==0)). I'm still
>> looking at it but it really looks odd.
>
> The problem seems to be libgcrypt's random generator. As far as I understand
> when you fork() the random generator is on the same state for every children.
> That's why the server produces the same session ID in the second process.
>
> I am not really sure about it, and I don't know how to overcome this, that's 
> why I crosspost to gcrypt-devel as well.

One solution is that we switch to the random number handling that is
implemented when --enable-nettle is given to a GnuTLS build.  Then
GnuTLS will read (on GNU/Linux) from /dev/urandom for pseudo-random
data and nonces, and from /dev/random for random data.

Alternatively, GnuTLS could use an internal PRNG, and we could add an
API to seed it.

How do people feel about this?

My personal preference is to rely on /dev/*random for randomness.  If
that isn't sufficient for someone, she can always point GnuTLS to
another device (or even file socket) and have full control without
bogging down the gnutls library.

The libgcrypt way should still be available, for people on weird
platforms with an OS that doesn't collect randomness, or for people
who prefer the libgcrypt approach for some reason.

Thanks,
SImon