[tpop3d-discuss] Re: OpenSSL and POP3 Integration Question (fwd)

[Ben Schumacher]

And the second:

---------- Forwarded message ----------
Date: Tue, 22 Jan 2002 01:23:16 +1300
From: Geoff Thorpe <geoff@openssl.org>
Reply-To: openssl-users@openssl.org
To: openssl-users@openssl.org
Subject: Re: OpenSSL and POP3 Integration Question

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                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org