cat /dev/DiBona/brain: What About E-mail Security?

Let's start with TLS while we wait for SPF.

Ever used driftnet? I go to a lot of conferences, and one thing I find myself doing while speaking is checking how engaged the audience is by sniffing the 802.11b traffic in the room. Whether this is a measure of how absorbing I am or, to put it delicately, how self-absorbed the conference attendee is, is an open question. That said, it always is surprising to me how little encrypted traffic is flowing on the very open Internet.

Does anyone use Telnet anymore? I hope not. We have better tools now; SSH and SCP are the way most sane people hop around systems on which they might have accounts. In addition, the days of unreliable and patent-encumbered SSH are gone, and we now have the luxury of using OpenSSH for shelling around.

For Web browsing, no one in his or her right mind would transmit important information over an insecure link. Secure sites for bank, shopping and other applications are the norm, with poorly secured sites being exceptions.

One mode of communicating over the Internet, however, is done shockingly, overwhelmingly in the clear. I'm talking about e-mail. It doesn't have to be this way, though. With all the excitement about SPF and other mail authentication methods, it struck me that people haven't done even the base work to secure their communications--myself included. If one can eavesdrop on communications, one can spoof those communications. In my mind, authentication schemes are going to be of dubious value without an attendant amount of effort spent securing the line as well.

Hence this article. TLS is a great way to do the basics of securing your e-mail against this very basic kind of snooping. You can use the same certificates you use to secure your Web site. Many people find using unsigned certificates works okay too, although it offers no guarantees for security or reliability regarding the exchange of mail.

TLS is an acronym for Transport Layer Security, and it simply encrypts your mail server to mail server traffic with other TLS-enabled sites. I recently implemented this for a client site and thought it really was in my interest to implement it for my personal e-mail, as well. So I decided to implement it on DiBona.com.

I made a quick trip to FreeSSL.com to pick up a certificate. Thirty-nice dollars and an automated phone call later, I had it. I highly recommend FreeSSL. Clear instructions on how to create the certificate on any competently setup Linux box, straightforward processes and a smart phone system make for a great way to get a solid certificate without any worries. FreeSSL has terrific phone support as well, in the event you make a mistake or need a little bit more hand holding, as I did for a chained certificate some months ago.

I ran this article by Uriah Welcome and Marc Merlin. Marc reminded me that you don't have to get a signed certificate, as most mail systems are configured to not care so much about the chain of trust. If you think about it, when your chain of trust ends at network solutions, it's not so trustworthy, but let's not go there. Uriah wanted me to make sure that people don't forget to protect the certificate files properly, don't chmod 666 then and so on.

Setting up TLS with your mail server can be difficult, depending on your setup. An exim installation is too simple for words. Once you have generated the key, you simply need to add the following three lines to the top of you exim.conf file:

tls_certificate = /pathtocert/dibona.crt
tls_privatekey = /pathtokey /dibona.key
tls_advertise_hosts = *

Please note that I used the exim-exiscan rpm.

For Sendmail users, here is an oldish Linux Journal article on the topic; I haven't installed it yet for Sendmail, so I can't vouch. Same with this postfix install. I expect users reading this install have better links than these, so check the comments for more on those servers.

A cool tool to use to test if you have set up TLS correctly has been provided by the Kernel.org people. To see what a good configuration looks like, see here.

Note the 250 Starttls line. That means I'm ostensibly ready to trade encrypted e-mail with other hosts. Life isn't perfect yet--I need to implement SPF--but I feel much more secure in my e-mail.

Chris DiBona is the Co-Founder of Damage Studios, a San Francisco-based game company working on the next generation massively multiplayer on-line game, Rekonstruction. He was formerly an editor for Slashdot.org and was the co-editor of Open Sources: Voices From the Open Source Software Revolution.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

The ONLY WAY to ensure completely secure email is to use either Gnupg or PGP. The message retains its encryption and security from sender to receiver... Just how many mail servers the message transits thru is irrelevant.

Further more, key generation and distribution are under the complete control of the individuals concerned.....

Peterson...

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

Or, use an S/MIME certificate. S/MIME has a greater chance of being widely accepted because the most popular (not necessarily the best) mail clients support it. S/MIME is probably easier to use for the average user. That said, I even got Mutt to sign/verify and encrypt/decrypt using the certificate/key (PKCS12 file) I exported from Mozilla, took apart with openssl, and whose components (cert, key, intermediate CA, and root CA) I put in the files Mutt expected them to be in. Admittedly, I find myself hitting (S)/MIME-(f)orget_it before sending in most cases because most people use S/MIME certs as much as they use PGP/GPG -- which is hardly ever.

Disclaimer: I work for a CA and use my S/MIME cert as much as possible -- even for client authentication to our company website. Later versions of curl can even use S/MIME certs to authenticate itself to a website that requires client authentication.

the crypto specified in the

Anonymous's picture

the crypto specified in the S/MIME standard is too weak to provide reliable security, it's only protection against casual snoopage

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

Or tell everybody to get a free personal certificate from Thawte or use PGP. Then you don't have to change anything on the server.

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

Thawte certs are the best :)

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

The biggest problem with implementing TLS mail is all the poorly configured TLS mail servers presently online that break mail sending when trying to negotiate TLS with each other. This is the biggest barrier to widespread TLS use

Stephen
meridian@tha.net

Secure telnet since 1993 at the latest

amarsh04's picture

Secure forms of telnet have been in existence since 1993 or earlier, and there are implementations that support authentication and encryption.
http://www.columbia.edu/kermit/telnet80.html is a good place to start learning more about security options in telnet.

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

What advantage does this offer over generating your own cert with openssl?

I don't see FreeSSL.com in any of the lists of trusted CAs I quickly checked, so I'm not too sure how they can beat 'mydomain.com.au' the new self-signed CA.

Their https server uses a cert signed by usertrust.com, which is in turn self-signed. If the same is true of their certs for sale, I may as well just generate my own instead.

We already use our own root CA to generate client certificates (which we require to grant access over the 'net) for users who want remote HTTPs, SMTP and IMAP access. We also make server certs for TLS-protected LDAP, HTTPs for use on the intranet. I'm very surprised this option wasn't mentioned in the article. Perhaps I've missed something.

--
Craig Ringer

Re: cat /dev/DiBona/brain: What About E-mail Security?

Anonymous's picture

Also, you can get free (as in beer) certificates from cacert.

Re: POP and IMAP

Anonymous's picture

Except that S/POP and IMAP/S are pretty well-known and many clients have GUI interfaces that allow the user to simply "Click here to autoconfigure" and they figure out if your server supports secure versions of POP and/or IMAP and then uses them, if available.

Of course, none of this protects your mail while it sits in the spool area of the various mailservers that it transits through. Which is why PGP/GPG encryption is truly the only way to secure email, since it's fully endpoint-to-endpoint encryption. It doesn't sit plaintext in some mailserver's spool directory...

Re: POP and IMAP

Anonymous's picture

Which is why PGP/GPG encryption is truly the only way to secure email

Mmmm... I don't agree. What about S/MIME?

S/MIME doesn't offer the

Anonymous's picture

S/MIME doesn't offer the choices nor the security of properly configured PGP or GnuPG. S/MIME is a distant second choice that needs to be updated to offer strong crypto and appropriate pubkey lengths or it's only protection against casual snoopage. The guy who said PGP/GPG is the "one true way" is correct.

pop/imap

Anonymous's picture

no mention of encrypting pop/imap huh? You've only taken care of outgoing mail and completely ignored incoming mail in which your password is typically sent in the clear.

Re: pop/imap

Gamara's picture

I wanted to keep the article focused and to the point, as the other commented noted, many people have and use pop-s and imap-ssl, but in my experience tls enabled servers aren't as common as I'd like them to be....hence the articles focus.

That said, please, everyone, use pop-s or imap-s :-)

Chris DiBona

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix