Christoph Biedl ngircd.anoy@manchmal.in-ulm.de wrote:
Florian Westphal wrote...
I had code which did load the new certificates/keys in the OpenSSL backend, but if memory serves me right I didn't find a simple way to do the same with gnutls... so i removed the reload-feature completely.
I see.
"Why would anyone have to re-generate certificates/keys on-the-fly anyway?" 8-(
Are you asking the gnutls guys or me? If the latter: Certificates tend to expire every now and then
Right, i did not consider this.
And restarting an ircd is always a harsh operation, but how about implementing the /upgrade feature as seen in irssi? ;->
Heh. I'd rather not ;-)
But you're right, it should be possible to re-load both keys and certificates.
I'll go through my archive and will re-add the reload feature to the OpenSSL backend and look at the gnutls stuff again.
I remember why i changed this. Previously, the ngircd ssl init hook was performed in the main loop, after chroot. A user complained that this was bad behaviour, because they used the same key/certificate for all of their services and they didn't want to copy their certificate data into the chroot.
Now, from a security POV, there is no difference between having ssl keys inside the chroot or storing them outside, because if there is an exploitable hole in ngircd you can read the key data from memory anyway.
I'll modify the code to allow both behaviours, i.e. it will be called before chroot() and from inside the Rehash function to allow keys to be re-loaded (provided they reside inside the chroot...).
Supporting this in gnutls will take some time, though. If i remember correctly, you can't simply call gnutls_certificate_free_credentials() on the old x509 context, since it may still be in use (by active ssl-connections). I'll have to investigate what the best way to solve this is.
Florian