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

Charlie Brady <[email protected]> writes:

> On Fri, 7 Jan 2005, Scott Gifford wrote:
>
>> Charlie Brady <[email protected]> writes:
>> 
>> > On Thu, 6 Jan 2005, Scott Gifford wrote:
>> >
>> >> Charlie Brady <[email protected]> writes:
>> 
>> [...]
>
>> > was negotiated. In the fork/exec model which sslio has, this is 
>> > necessary/deliberate, since the fork/exec occurs before any data is read 
>> > from the network, so, e.g., an environment variable can't be set up for 
>> > the the mail daemon describing the SSL negotiation outcome. This prevents, 
>> > for instance, the mail daemon from adding a descriptive Received header. 
>> 
>> With your pipe/socket idea, it would be straightforward to send this
>> information back down the pipe, although it would require a more
>> complex protocol.
>
> True, but could be as simple as send 'y', then read string until \n.

If you're sending information from the certificate, it's a bit more
complicated, since that can (probably) contain embedded newlines.
That's some of the more useful information, since you could
potentially use pattern matching rules to accept and reject particular
client certificates.

Still, it's nowhere near impossible.

>> SSL may allow renegotiation of parameters, which would be more
>> challenging.
>
> In theory yes, but I don't think any of the smtpd+starttls deal with that 
> issue already. Nor do I think it's a real issue in practice. OTOH, I don't 
> know how much more valuable a received header is than good logging by the 
> SSL wrapper.

I agree with both points.  We could probably also find a way to
disable renegotiation, to make the whole thing irrelevant.

>> 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);

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

I think a single-character on a pipe is probably better, though.  :)

[...]

> people use SMTP+SSL on port 25. And I'm keen to demonstrate that big
> patches to qmail-smtpd aren't the way to provide it. Using something
> other than OpenSSL isn't a bad thing either.

I don't really have any objections to OpenSSL or patching qmail-smtpd,
but I agree that minimal changes are better, and I think privilege
separation is vital, along with easy setup (which my current solution
lacks).

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.

Charlie Brady <[email protected]> writes:

> On Fri, 7 Jan 2005, Scott Gifford wrote:
>
>> Charlie Brady <[email protected]> writes:
>> 
>> > On Fri, 7 Jan 2005, Scott Gifford wrote:
>> >
>> >> Charlie Brady <[email protected]> writes:
>> >> 

[...]

> 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).

-----ScottG.