exit code trigger for STARTTLS (Re: sslio as a STARTTLS wrapper)

On Fri, 7 Jan 2005, Scott Gifford wrote:

> Charlie Brady <[email protected]> writes:
> 
[...]
> 
> >> Another idea is to have the server exit with a particular exit code
> >> when SSL was requested; the wrapper would detect this, enable SSL,
> >> then re-exec the server with the connection, and any SSL settings in
> >> environment variables.  This is also very simple to implement, and
> >> enforces the requirement for SMTP that all state is reset after
> >> STARTTLS.
> >
> > That's incompatible with the privilege separation. 
> 
> I don't think it is.  Something like this:
> 
>   sslserver:
>     fork()
>       child:
>         drop_privs();
>         exec(program,args);
>       parent:
>         exit_code = wait();
>         if (exit_code == START_SSL)
>           setup_ssl_fds();
>           fork()
>             parent:
>               drop_privs();
>               start_ssl();
>             child:
>               drop_privs();
>               set_ssl_envvars();
>               exec(program,args);

Yep, I can see it's so.

> > It's certainly no better than what I already have, which is that
> > smtpfront-qmail parses STARTTLS, then execs an SSL wrapped 
> > smtpfront-qmail.
> 
> The advantage is that you don't have to have a frontend program
> proxying data, you can use a very small patch to many different
> programs to implement it, it works well for layering wrappers, and it
> allows environment variables parsed only at startup to take effect.
> For example, if you only want to offer SMTP AUTH if TLS has been
> negotiated, the SMTP AUTH wrapper can just check environment variables
> to see whether to activate itself or not.  Or if you want to use a
> different QMAILQUEUE depending on whether TLS is negotiated,
> you can do that fairly easily.

They seem interesting capabilities.
 
> I think a single-character on a pipe is probably better, though.  :)

So you don't believe your own advocacy? :-)

> I don't really have any objections to OpenSSL ...

Its record tells us that it hasn't been designed from ground up to be 
string/buffer safe.

> or patching qmail-smtpd,

Can't be included in binary distributions. But smtpfront-qmail is a 
superset anyway.

> I'm interested to see if there's a more general solution that could be
> used to layer various types of protocol extensions on top of any
> inetd-style SMTP server, like STARTTLS, SMTP AUTH, and ETRN.

Yep.

> [...]
> 
> > But that's not my point. My proposal is to fork an SSL wrapper which sits 
> > in standby mode until asked to participate. There's no point in keeping it 
> > around if it's not to be used, so the mail daemon can send it one of two 
> > messages as soon as it's able - take over I/O and start SSL wrapping, or 
> > die - 'y' or 'n'. 
> 
> STARTTLS can be sent at any time, although in practice it's generally
> sent right after EHLO.  I don't see any harm in just letting the ssl
> server block on a read in case STARTTLS is later requested; that would
> take a negligible amount of resources (a process slot and probably a
> page of memory).

OK.

---
Charlie