Hi there, > * The OpenSSL API does not offer a call to remove the private key > information from memory as long as any TLS functionality is still > set up. > (-> reminder: check, whether the memory overwritten when performing > SSL_free()/SSL_CTX_free()..) > To be compliant with RFC2246 we do not the private key, as a > renegotiation may take place.
I assume you mean "we do need" rather than "we do not"? If so - it could be skipped if was known that the request in question wouldn't involve any renegotiations. Renegotiations are quite unlikely if the connection carries a single transaction and the fork()d process exit()s after that is dealt with. In that case, you don't even need to bother with SSL_free() or any such SSL API thing - just "BN_clear_free(rsa->[d|p|q|dmp1|...]); rsa->[d|p|...] = NULL;" will do. Ie. just zero out the key entries as they won't be called upon anyway - you're just protecting against scanning attacks on the memory (or core dump as the case may be). If you really want to be ruthless - edit every RSA_new() and RSA_free() function to (de)register each RSA pointer in a global list of some kind, then after the fork() and SSL handshake has taken place, just iterate through every living RSA structure and wipe out any private key components you find in them (not all with have them, eg. not those keys in the certificate objects!). If you need persistence of the key because child processes handle multiple requests or renegotiations may take place in one request, then you'll need some other mechanism for doing the key operation outside the child process so the child-process doesn't need the key components, eg. dedicated hardware/smart-card, distinct crypto process, etc. > * On the other hand, if your process started with root permissions > and later dropped privileges using setuid(), your kernel should protect > you from the user being able to attach to it. > (At least on HP-UX: I just tried to attach to an imapd process > and the kernel did not allow it.) This is also true for Linux and Solaris IIRC. I suspect it's probably required by correct implementation of various aspects of POSIX etc, but whether various platforms implement them that accurately is another question of course. Anyway, I doubt assuming protection against attaching to processes necessarily implies protection against key-scans ... core files, memory paging, etc can all be ways to get read access to the process memory (or record/copy of it). Better to ensure that the key data is simply not accessible in any sense at all before the process is running as that user *or* at least get rid of that data as early as possible (ie. lowering the window of time the process is running as that user with the key-data in memory). There's also the risk of "third-party" code binding in that could launch key-scans, eg. mail-filters, auto-responders, whatever. Some could be written deliberately by users to compromise the server keys of course (the threat model includes your users, I assume?). If you scrub the key data before any of those are loaded - that at least cuts out another avenue of attack even if you can't have the keys removed before the process is running as a non-root user in the first place. Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]