Postfix/TLS - Initial Motivation
This introduction shall point out the motivation, why I spend my time
writing this TLS extension for postfix.
Roaming users problem
It quite often happens that my users want to access their mailboxes
and to send emails from hosts outside our network. The main reasons
are the access from home via Internet service providers (ISP) or from
abroad during business trips (in our case typically to other universities
around the world). Sending and accessing leads to two loosely coupled
problems.
UCE control
One problem is sending emails, because from abroad it is seldom possible
to predict the sending hostname we will have and when using an ISP the
assigned hostname is typically random. As we of course must have UCE
control in effect, I either must open up relaying complete ISP domains
on my users request (Arrgghh!) or must introduce an authentication
beside the hostname or IP address.
Passwords and insecure networks
This directly leads to the second problem. Recent versions of Netscape
do offer password based authentication. This solves the UCE problem
but introduces another one, which I consider far more severe: The
users have to send a password in plain text over the network. Of course
I could solve this problem by issuing special passwords just for this
reasons, but some of my users don't have a clue of what is going on between
the keyboard and the screen, so they would happily try their real password.
The same problem of course also applies to the POP and IMAP services. I
tackled them first, because they are typically attacked by port scanners,
so I closed them down by tcpwrappers (Hi Wietse!) to only allow my local
hosts to access them.
Encryption via SSL
The solution to the plain text password problem was easily found with
the use of SSL. You just tunnel the POP or IMAP connection through
SSL, using either SSLwrap
[SSLWRAP]
or stunnel
[STUNNEL].
Netscape supports IMAP with SSL tunneling since version 4, I have one user
with Outlook Express, who uses POP3 with SSL tunneling, so this solves
the plain text password problem by encryption.
Netscape 4.5
Starting with Netscape 4.5, also sending with SSL encryption is supported.
As Netscape also supports client certificates, this seemed to be an easy
solution for the UCE control problem. So I happily added an "smtps" service
with SSL wrapper and client certificate verification. Unfortunately it
didn't work and the connection just hung! After some digging around I found
out, that Netscape 4.5 seems to realize the protocol described in
RFC 2487
[IMC].
RFC 2487 - SMTP Service Extension for Secure SMTP over TLS
RFC 2487 describes how to include TLS (the successor of SSL) into
the normal Extended SMTP protocol. During the normal EHLO start negotiation
the server offers the STARTTLS option to the client, which then issues
the STARTTLS command. After the server accepts the command (220), the
normal SSL handshake will start.
Unfortunately it is impossible to handle this situation with a normal
tunneling software, as they are not prepared to do clear text negotiation
before running SSL and don't have the slightest idea on the SMTP protocol.
Therefore the way to go was to extend a given mail server software. The
first candidate was sendmail-8.9.3, as I was a long term sendmail user.
After digging around some I came to the conclusion, that even though
possible, the source code was quite difficult to understand and adding
the necessary configuration options didn't look inviting.
Postfix
At this point (February 1999) I checked other mail servers and was
immedideately fascinated by postfix source. It was very good to
read and understand, so I decided that if I would take the time, then
postfix would be the way to go.
I then started to first change our site to postfix. It took some hours
to do this, because our mail system is running on a common network I
administrate for several chairs, each of them with its own mail server
and domain, but a common user base, so a lot of rewriting takes place,
we need virtual services for symbolic names like "webmaster"
etc.
Postfix/TLS
Some time after having done this I finally found the time to write
my TLS extensions for postfix. I took the source of the s_server
of the OpenSSL package and added a simplified version of it to
postfix, so that by now we can run the SMTP protocol encrypted on the
server side. This would also allow us to use plain text password
authentication, but as it is available without cost, I rather decided
to go with client certificates. If you can offer a client certificate
to our server, that is included in a list on our server, you can relay
your emails through our server!
Summary
Postfix/TLS is an addition to the smtpd server, which (at least trys to)
implement the RFC 2487 TLS Service Extension and allows UCE control
based on client certificates. I think it won't be too difficult to also
realize the client side of RFC 2487, but this will be a later step.