[tpop3d-discuss] Re: TLS Support

[Ben Schumacher]

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

No rush man. I just figured it might be easier to pull anon from CVS than
have you package up a snapshot. I'll start playing with the 1.3.5 code,
I'm sure it won't be too difficult to merge back. And trust me, I fully
understand busy. The reason I haven't played with this more recently is
because I was quite busy with my real job up until the end of last year
and had no time to work on anything open source. Things have slowed down a
bit though, so I thought I might as well contribute some time to another
project.

> 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.

All perfectly reasonable. Pretty much the same design I came up with in my
head. 
 
> 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.

Maybe always, instead of auto? Or enab and nego? As in "enabled" or
"negotiated"? Either way works for me. Actually, auto/stls works, too. And
I completely agree with you, different keys for different addresses make
sense. Admittedly, my patch was hacked together based solely on the fact
that I wanted TLS for myself and I figured if I had it, somebody else
might want it as well. :)

> Comments? Does this all look reasonable?

Yup. It really is basically what I came up with in my head, just hadn't
taken the time to write down/articulate my ideas. Having somebody else
write it down helps me hash it out in my mind a little more.

Cheers,

Ben

P.S. Despite the fact I clipped the off-topic drifting, I tend to agree
with your assertations. And just so you know, I don't think CVS access is
necessary, just figured it might be easier for me to pull out the code
myself than for you to have to pack it up somehow.