TLS Support (was- Re: [tpop3d-discuss] Compilation trouble on Solaris)

[Ben Schumacher]

On Fri, 18 Jan 2002, Chris Lightfoot wrote:
> > > My thinking is that the best solution is to have tpop3d
> > > fork a `helper' process to do the TLS operations. This has
> > > another advantage: if the helper process runs as (say)
> > > root, a malicious local user cannot then use a debugger to
> > > steal valuable cryptographic data from the server process.
> > > This is pretty nasty, but is IMO a cleaner solution than
> > > the other options.
> > 
> > While I understand the security concern, I think the impact would be
> > limited. While it would allow users to view cryptographic information on a
> > tpop3d process that has already done setuid'd to the user in question,
> > would this really be all that bad? At worst it would expose information on
> > the private key used for the initial key exchange, but this problem could
> > probably be mitigated by making sure that memory is free'd or clobbered
> > before we change the effective UID of the forked process.
> 
> Exactly: my concern is for the server certificate and
> private key, not the session keys. Can we safely get rid
> of these? Aren't they needed for renegotiation?

So based on the responses I received from the OpenSSL mailing list, it
appears that the external process might be the best way to go. It appears
that we could *probably* safely remove the private key from memory, but if
a renegotiation happens, it would cause problems on the socket
connection. I guess I might go ahead and investigate what it would take to
spin off another process to do the cryptographic handling. This might,
also, solve the issue of the denial of service problem I found with my
previously contributed SSL patch.

Is there a way I could pull the most recent source code from CVS, or do
you have a recent CVS snapshot I could start working off of?

Cheers,

Ben