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

On Mon, 3 Jan 2005, Charlie Brady wrote:

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

When started in this mode, sslio could create a pipe to share with its
mail daemon peer. It could then block on a one byte read from the pipe.  

The mail daemon peer could deal with the STARTTLS command in cleartext,
then send 'y' into its end of the pipe, and thereafter allow sslio to wrap
the I/O. The mail daemon will need to know it is co-operating with sslio, 
and will need to know which file descriptors to use when communicating 
with sslio.

If the mail daemon saw another command which implied cleartext 
communication, it could send a 'n' into the pipe, and then wait for the 
sslio peer to terminate, before continuing in cleartext.

sslio will know to exit or to start wrapping the network traffic depending 
on the byte it reads.

Sound OK?

---
Charlie