Hi Amitai,
Nice to have you here! What took you so long? ;)
So, the reason why I never followed the ucspi-tls thing is that I
simply
don't like opportunistic TLS. A core tenet of my philosophy is that
dynamic stuff is inherently more dangerous than static stuff, and it is
harmful to have dynamic stuff just because we can; every addition of
dynamism should be properly justified. And that includes STARTTLS: why
would you start a connection in plain text *then* upgrade to a secure
one, when you can start a TLS connection right away?
That's why I designed s6-tlsclient and s6-tlsserver to always perform
immediate encryption, not delayed encryption. It works well with IMAP:
it's generally accepted that IMAP servers can (and should) require the
use of imaps as a policy, and that IMAP clients should just perform
imaps connections, starting right away with a TLS exchange, instead of
relying on STARTTLS. Why is it not the case with SMTP?
(Actually, I have a pretty good idea why it's not the case with SMTP:
the SMTP landscape is a wasteland on top of a landfill, and I'm out of
'land' words but the landfill is contained in a giant garbage truck
that is on fire, and the firemen are all Pennywise the Clown, and the
fire hoses are actually spewing out gasoline.)
So, the programs in s6-networking that perform the TLS layer, i.e.
s6-tlsc and s6-tlsd, are entirely self-contained, will perform the
TLS handshake, and will just provide a tunnel for the applications to
write into. Same idea as ucspi-ssl, except I wanted to be free of the
horrendous openssl interface, and I wanted to play with bearssl, which
is hands down the best thing that has happened to transport security
since the first release of SSLeay.
If I needed to write an SMTP server that supports STARTTLS, the way
I would do it would be the following:
- Use an unpatched SMTP server that does not support it, typically
qmail-smtpd
- Have a s6-tlsserver process on port 587 (it is really a s6-tcpserver
process that performs the correct s6-tlsd invocation when it gets a
client connection) spawning a qmail-smtpd for native TLS connections
- Have a regular s6-tcpserver process on port 25 listening to plain
text connections, but invoking something like:
starttls-wrapper localhost 587 qmail-smtpd
- Write the starttls-wrapper program.
starttls-wrapper would:
* spawn qmail-smtpd and forward the communication between the client
and the qmail-smtpd instance, but record it, and snoop on it looking
for a STARTTLS command
* depending on a command-line option, if no STARTTLS has been
received by some point, either drop the connection (secure option) or
just stop the recording and continue the plaintext forwarding
(default option)
* on STARTTLS, drop the plaintext connection to qmail-smtpd, open a
secure connection to localhost:587 with the real tls-enabled server,
replay the start of the dialogue with it, then disappear into the
aether, leaving the client to speak with the real server.
The benefit of that approach is that it doesn't involve patching at
all, and can be made as secure as you want. The drawback is that it
may interpose yet another forwarding process in the data flow, causing
context switches and thus slowness, but I don't think it's critical.
The starttls-wrapper program is protocol-specific, but STARTTLS is
already protocol-specific so there's no real difference in the amount
of effort needed to support it.
I realize it's probably not the answer you were looking for, but it's
the best I can give you. :)
What do you think?
--
Laurent
Received on Mon Nov 16 2020 - 14:05:27 UTC