[gnutls-dev] Generating/regenerating params
Nikos Mavroyanopoulos
nmav at gnutls.org
Sun Mar 7 19:59:35 CET 2004
On Sat, Mar 06, 2004 at 02:19:31AM -0500, Stephen Frost wrote:
> Greetings,
> I've run into a very difficult problem when trying to safely
> regenerate dh/rsa parameters. The setup is like this:
> There's a global context which has creds
> (gnutls_certificate_credentials) and all of the CA certs and whatnot
> are loaded into it.
> We then have a local (per thread) context which copies the cred from
> the global context, but just the pointer (there isn't a function to
> copy the whole thing...).
There is no need to copy the whole thing, since the credentials
are only read by the sessions. They are never modified.
> We then set params in creds in each thread, cacheing the params in a
> file and regenerating the params whenever the file disappears, which
> we plan to make happen periodically as is recommended in various
> comments in the example GNU TLS server.
> There's a couple problems here though: The params are shared across
> all threads because of the single global context with creds. I worry
> about regenerating them because I don't want to break existing
> connections or ones which are in the process of setting up. I don't
> see any way (beyond re-reading all the certs which I expect would kill
> performance) to make the creds be local though.
> What's the right way to do this? Have multiple threads going and
> still periodically regenerate the rsa/dh params without breaking
> anything or leaking memory or anything? Is it safe to just init the
> rsa/dh params and then just change them with generate2 or import_raw?
> Will that break existing connections or other threads which are
> setting up their connections? Do I still need to call set_XX_params?
Currently there is no easy way to renew that parameters in multithreaded
applications. I was thinking into adding functions or callbacks to set those
parameters per session. Would this solve your problem?
> Thanks,
> Stephen
--
Nikos Mavroyanopoulos
More information about the Gnutls-dev
mailing list