On Wed, 26 Mar 2003, Andreas Aardal Hanssen wrote: > >But in any case, I don't think it matters, since perhaps the division of > >labour between child and parent should be such that there is no need to > >pass control in the way that Andres seeks. > >Scott Gifford has modified stunnel so that it can execute as an IMAP > >proxy. It either negotiates TLS, or operates as a cleartext proxy. > >Moreover, it does so running non-root in a chroot jail. > >Un his configuration stunnel runs non-root (as the user "stunnel"), > >imapfront-auth as root, then imapd as the authenticated user. I'm curious > >as to how you would partition the tasks differently, and why you wish to > >pass the TLS task from one process to another. You'll note that this > >configuration handles the connection with two concurrent processes - there > >is no way to use fewer processes without sacrificing privilege separation. > > Agreed that this is a great way to handle port 993 SSL, but how would you > use this to solve STARTTLS?
What I've showed you is exactly how to solve the STARTTLS problem (port 993 is so easy I didn't mention it). The modified stunnel is an IMAP proxy, except that it interprets STARTTLS itself. If an IMAP command other than STARTTLS or CAPABILITY is issued, it becomes a cleartext proxy (and TLS is no longer possible). If STARTTLS is issued, then stunnel negotiates TLS with the client, and then acts as a TLS proxy. In this configuration the IMAP daemon no longer needs any SSL code, and the SSL code doesn't need to run as root. I suggest that you read Scott Gifford's page for more detail. -- Charlie
