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

Chris Lightfoot chris@xxxxxxxxxxxxx
Thu, 17 Jan 2002 17:25:29 +0000


On Thu, Jan 17, 2002 at 10:09:52AM -0700, Ben Schumacher wrote:
> On Thu, 17 Jan 2002, Chris Lightfoot wrote:
> > Sorry, known bug, you need -lrt. Try pasting the above gcc
> > command line and appending -lrt on the end, and see if it
> > works. I'll fix autoconf in the next release (RSN, once I
> > can find a way to make TLS work properly....)
> 
> Quick question Chris. As somebody who has already contributed to the TLS
> effort (BTW- I can't remember if I posted a fixed patch, but the one I
> posted earlier alloacates a *HUGE* amount of memory -- something I missed
> in my initial testing.), where are you stuck with TLS support? I looked at
> the code a little deeper and while what I contributed works for clients
> that supported STARTTLS, it looked like it might require a fair amount of
> work to get tpop3d to work using the alternate port TLS, is this what
> you're working on?
> 
> If so, I'd like to contribute. I haven't had much time over the past
> couple months (my real job is always messing with me), but I should start
> having more free time in the near future. Is there any specific issue
> you're trying to work out that I might be able to assist with? In
> addition, would it be possible to get CVS snapshots periodically, or
> anonymous CVS access? I'd like to contribute more, but I have a feeling
> that the code I'm working off of (1.3.5) is way out of date.
> 
> Just thought I'd toss that out. Let me know if there is anything I can do.

Hmm. First, I should apologise for throwing the above in
to the mix without getting in touch with you first.


I spent a little while looking at the TLS patch you sent a
few weeks ago. Apart from a minor change to make it work
with maildir and BSD mailboxes, it is on the face of it
fine.

However, there is a serious problem with TLS, which makes
it unsuitable for use in a program such as tpop3d which
uses blocking IO: a call to SSL_write may discover that
the client has requested TLS renegotiation. This means
either that the server could then block on SSL_read, or
that all IO must be rewritten to be nonblocking. (The
problem is, obviously, that although this doesn't have a
serious effect when clients and the network are
well-behaved, it's disastrous in the presence of a
malicious client.) Now, it's certainly possible to rewrite
tpop3d's main loop to use nonblocking IO and to include
all of the TLS nastiness, but it's not a very pleasant
problem and I'm reluctant to do this for another reason
which I mention below.

On a related note, while looking into TLS, I wrote a
little bit of code which may be useful to somebody...
    http://www.ex-parrot.com/~chris/tlsproxyd/


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.


I would welcome any comments anyone has (especially from
Ben since he's actually implemented TLS in tpop3d, which
is more than I've managed yet!).


-- 
 ``History teaches us that men and nations behave wisely
   when they have exhausted all other alternatives.'' (Abba Eban)