sslio as a STARTTLS wrapper (was Re: sslio error description incomplete/wrong)

On Sat, 1 Jan 2005, Charlie Brady wrote:

> I've been dabbling with using sslio to add STARTTLS functionality to Bruce
> Guenter's imapfront-auth ... [and smtpfront-qmail, etc]

Some work of Scott Gifford
(http://www.suspectclass.com/~sgifford/stunnel-tlsproxy/stunnel-tlsproxy.html)
with stunnel helped me along. And I'm now inviting him here to join a
discussion of what the next step might be.

To bring him up to speed, Gerrit has built a nice small ssl wrapper
(sslio) in his ipsvd package. And I've made patches to various parts of 
Bruce Guenter's mailfront package to add STARTTLS support. I've added 
STARTTLS command parsing to imapfront-auth, pop3front-auth and 
smtpfront-qmail, with the SSL/TLS implemented by execing a command named 
via the TLSCOMMAND environment variable. This works, nicely with stunnel, 
and almost using sslio (because sslio provides only SSLv3, not TLSv1).

This approach gives me a simpler setup than Scott's with a significantly
smaller footprint, and the advantage of avoiding a plaintext proxy when
STARTTLS is not used. Moreover it avoids any need to add SMTP/IMAP/POP
protocol parsing to the SSL wrapper. But in the case of SMTP wrapping, it
loses the privilege separation that Scott's modified stunnel and sslio can
provide.

I think I have an approach which will solve these problems. I'd like to 
get some feedback before I try to implement it.

Here's an invocation of an SSL wrapped smtpfront-qmail, running on the 
ssmtp port:

exec /usr/bin/tcpsvd \
	-i ./peers \
	-l 0 \
	0 \
	ssmtp \
          sslio -vv -/ ssl -u stunnel -U qmaild /usr/bin/smtpfront-qmail

This executes a chrooted sslio (running as stunnel) talking to the network
and an instance of smtpfront-qmail (running as qmaild) talking via pipes 
to sslio.

I'd like to do something very similar on the smtp port, with 
smtpfront-qmail talking plain text smtp, until it sees a STARTTLS request.
This should be possible with just a little co-operation between sslio and 
smtpfront-qmail. If sslio leaves smtpfront-qmail with stdin and stdout 
connected to the network socket, and doesn't itself read from or write to 
the network, smtpfront-qmail should be able to talk plain text SMTP to the 
network, right?

Now, if smtpfront-qmail sees a STARTTLS request, it can respond to the
connecting client that it is ready for TLS, and can switch its I/O to the
pipe connections it has with sslio (closing the file descriptors it no 
longer needs). It'll send some sort of message to its
sslio peer, which will then commence SSL negotation, and start proxying
the SSL traffic as it normally does.

If smtpfront-qmail sees any command other than STARTTLS, it'll know it 
doesn't need an SSL proxy, and can let sslio know that it can quit.

The main detail to flesh out is what form of IPC to use. Any suggestions? 
Any serious flaws in my thinking?

---
Charlie