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

[Chris Lightfoot]

    [ Thanks for investigating this on the OpenSSL list ]

On Mon, Jan 21, 2002 at 09:20:07AM -0700, Ben Schumacher wrote:
> On Fri, 18 Jan 2002, Chris Lightfoot wrote:
    [TLS and helper processes]
> > 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?

OK-- I'm a bit busy with other things, but I will produce
a snapshot for you later in the week (tomorrow,
hopefully). In fact I should release 1.4.1, TLS or no,
given that there are already some important bug fixes.
Urgh. (It's turning out to be a bad week, just like the
last one. I need a holiday....)

<off-topic type="drifting">
It's my intention to put tpop3d into a more public CVS
repository than it's in at the moment; indeed, I
half-wrote a CVS virtual server layer, but the problem is
that the CVS security model isn't suited to operations in
such an environment, and so it needs me to add ACLs to
CVS. There is an ACL patch for CVS but it comes with a big
`don't use this' warning, making me reluctant to put it
into a security-critical environment. So, writing an ACL
patch for CVS is on my to-do list. Have you ever noticed
how to-do lists always get longer, sometimes in a
catastrophic sense: finishing -- or, worse, starting -- an
item sometimes generates another item of equal or greater
priority, or, sometimes, more than one, leading to a
disastrous to-do list meltdown.

I expect that this is something to do with $n$th-order
metawork, of which you will doubtless have heard.
</off-topic>

It would (IMO) be a good idea to thrash out the model for
helper-process TLS support now, so that we're both happy
that we're talking about the same thing.... So I will now
proceed to try to tell you what to do; feel free to shout
me down.

As far as I can see, the best strategy is to have the
helper process, connected to the main tpop3d by a
socket-pair, forked off as soon as any TLS operation is
required; this sidesteps all of the blocking/non-blocking
issues. This means that the tpop3d main process must
acquire the cryptographic certificate and so forth, and
then as soon as an incoming connection is received on a
pop3s port, or an existing connection issues the STLS
command, we fork the helper process, which calls setuid,
discards resources it doesn't need, and goes into a proxy
loop like the one in tlsproxyd. This process will exit as
soon as it detects EOF or an error on any connected
socket, doing a proper TLS shutdown if it is the local
side which has closed.

This then means that the main process must discard
cryptographic material immediately after forking an
authenticated child, before it calls setuid.
SSL_free/SSL_CTX_free seem to be the things to do here,
since the main tpop3d needs them only so that it can fork
off helper processes. We assume that the OpenSSL people
have got this right, and that these calls zero the memory.

One other remark: the patch which you submitted only
allows one certificate and private key per tpop3d. It
would, IMO, be preferable to have multiple ones. I see
this as working in the following way: extend the
`listener' syntax in the config file to be

    address[:port][(domain)][;tls=(auto|stls),certificate[,private-key]

... I even wrote code to parse this :)  `Auto' means `TLS
negotiation immediately upon connection' -- there may be a
better keyword for this -- and `stls' means STLS operation
in the manner of the patch you've already supplied.

Comments? Does this all look reasonable?

-- 
 Cats are intended to teach us that not
 everything in nature has a function (Garrison Keillor)