Applications /

How can TLS increase e-mail security?

By Joel Snyder
Network World on Groupware and Messaging, 03/29/99

Now that you know what TLS is, this is the next obvious question.

Most Internet-based e-mail systems use a combination of three main protocols: SMTP (for message delivery) and POP and IMAP (for message retrieval). Of course, for proprietary systems (such as Exchange or Notes), there are other, different, protocols that take the place of these standardized ones. Nevertheless, when it comes to pulling and pushing e-mail across the Internet, these three are the dominant ones.

Since TLS is a "transparent" protocol, you can run any other protocol on top of it. In the Internet world movement is generally geared towards every client/server protocol having two entries into a system (TCP or UDP ports, really). One is the "standard" one -- unencrypted, and the other is the encrypted version. Although there are thousands of protocol port numbers defined in the Internet, really only a few major ones dominate Internet traffic --- and, as mentioned above, three of them (four if you count http) do most of the e-mail.

Thus, for IMAP, which is normally run over port 143, there is now an encrypted port: 993.

The table below gives some of the mappings for protocols that are defined to run over TLS:

 Protocol	Normal Port		Encrypted Port
 http		80				443
 NNTP		119				563
 LDAP		389				636
 FTP-data	20				989
 FTP-control	21				990
 Telnet		23				992
 IMAP		143				993
 IRC			194				994
 POP3		110				995
 SMTP		25				465 (revoked)

Notice in the chart that SMTP port 465 is marked as "revoked." This is because there has been a lot of debate within the Internet community about whether or not each protocol now needs two ports. The obvious problem with this is that there are a lot of protocols and defining a second port for each one is going to be a long and ugly process.

An alternative to this is to have an "upgrade" built-in to each protocol. With an upgrade, two sides start to communicate on the normal port. Then one of them decides to "upgrade" the connection to a higher level of security. The two sides negotiate this and, if the upgrade is successful, begin to communicate using a more secure channel.

The problem with the upgrade idea is that it is very susceptible to "man in the middle" attacks --- a kind of security attack where someone is able to insert a receiver and transmitter into a connection, receive and then retransmit the data out to the other side. If the man in the middle is properly situated he may be able to convince both sides that they are running a secure channel, when in fact he is able to read everything sent over the connection.

In any case, many protocols --- including SMTP --- are being retrofitted with an "upgrade" feature that allows cooperating client and server systems to jump from unencrypted to encrypted on the same channel.

Right now, the most popular way to run SMTP is to use port 25 and then use the SMTP extension "STARTTLS" to upgrade the protocol from unencrypted to encrypted. This is the problem that Exchange and the PIX have: Exchange offers to upgrade and PIX gets in the way.

Support for these encrypted protocols is growing. I use the Netscape 4.5 client at home, with encrypted IMAP and SMTP. Servers such as Exchange and PMDF support it, so depending on how your system is configured, you may be getting encrypted e-mail without knowing it (at least from MTA to MTA). Of course, just installing Exchange isn't sufficient to get TLS --- you must follow Microsoft's lengthy instructions and get a certificate to enable the security features.

This is one of the first areas, though, where firewalls may be decreasing (instead of increasing) security. If your firewall will let through unencrypted IMAP traffic on port 143, but won't let through encrypted IMAP traffic on port 993, then your firewall may be forcing users who want to read mail across the Internet to expose their usernames and passwords to the world. Similarly, for SMTP, if your firewall relays your mail or if it proxies SMTP but blocks TLS, then you could be losing security, rather than gaining it!

Your action items: find out if your POP and IMAP clients support encryption over TLS, and if they don't either upgrade or pressure your vendor for support. Next, find out if your servers support encryption, and do the same -- upgrade or get the vendor to fix it.