Secure Internet Email

Using x509 certificates and PKI to secure message transmission

by Mark Foster
October 15th, 2003

We all know the virtues of a secure webserver - the "lock" icon in our browser gives us the confidence to send our most personal information (namely credit card numbers) over an insecure medium (the Internet) knowing that are information is secure. But what does this really mean, and how can this same mechanism be reused to secure our most personal information sharing mechanism - email?

What the lock symbol in your browser really means is that the owner of the website (https://www.example.com/) has installed with is commonly called an SSL certificate or x509 certificate. This certificate, in turn, is used to secure the data transmission between your browser and the web server such that the data is encrypted (cannot be read by casual observers) and authenticated (well at least in one direction, we'll get to that later).

Now it's worth noting at this point that there's really nothing "web-specific" about this SSL certificate technology. All of it falls under the umbrella term PKI (Public Key Infrastructure) which has been in development for quite some time (30 years?). Now there's not much about PKI that I'm going to regurgitate for anyone, since there are plenty of references about the technology. The important things which make this technology ripe for exploitation on the email front are:

  • robust technology
  • support by all the major vendors
  • provides one or two-way authentication and encryption
  • provides credentials for one or both parties in a transaction
  • allows for penalization (CRL - certificate revocation lists)
  • Is distributed - you can have multiple finite CA (Certificate Authorities)
Also, implementing this solution will not prevent other SPAM-fighting mechanisms, such as SPF/RMX, from working as designed. It does not stand in the way of S/MIME or PGP/GPG, in that those techologies work with the body of an email message, not the entire message, headers and all (commonly called the envelope). Finally, this solution provides a more robust and secure solution than DNSBLs[3].

How would it work?

Consider the vilified spammer who takes it upon themself to obtain one of these SSL certificates in order to play mailbomb on the newly-secured email network. Said spammer's email message is all that would be needed as evidence to revoke their certificate, and blam! They are out of business.

Now that's saying alot, and there are alot of assumptions that need to be addressed before we really can put that (and most) spammers out of business...let's step through these assumptions one-by-one so that we haven't missed anything.

  1. Certificate Authorities (CA) - these entities will be expected to respond to bonafide spam-complaints. Most likely a simple email address where spam-ridden email could be forwarded will do the trick. Think abuse@someca.com. Think Spamcop. The question is, can our existing CAs (such as Verisign, Thawte, GeoTrust, Tucows to name a few) be convinced to operate in this manner? Safe to say the current role of CAs does not quite encompass what is involved here, so if resistance is met - that's OK. A new set of alternate CAs can emerge to fill the void, possibly offsetting the cost of deploying the solution worldwide, by offering low-cost or no-cost certificates to non-profits, individuals and the like.
  2. Certificate Revocation Lists - this is how we ensure that the system is not abused. Spammer certificates are put on the CRL for all to see. Next time spammer connects - boot 'em.
  3. Revocation Thresholds - how many offenses to trigger a certificate revocation? I say 3, but this would ultimately be decided by the CAs, some of whom may end up being tossed from mail server admin's CA list if they don't meet some reasonable expectation of responsibility and integrity.
  4. Mail Transfer Agents (MTA) - these are the mail servers on the Internet that talk SMTP or ESMTP. I recent survey I did shows the top 5 email servers being Sendmail, MS-IIS, qmail, IMail and exim[2]. These and other widely-deployed MTAs need to support STARTTLS and/or other SSL enabled transports. This may be easier than we think.

Conclusion

In conclusion, the table is set for deploying a widely-recognized, stable and scalable solution for securing one of our most important communication mechanisms. Email is here to stay, and almost everyone is using it. Now is the time to fix it.

Next time, I'll look at some of the popular MTAs being used on the Internet to gauge their readiness for this solution. Stunnel comes to mind as another piece of software that could play a huge role. Also I will setup a prototype CA to show how easy that aspect of the process can be. Until next time! -mdf

Notes

[2]eMail Server Survey
[3] DNSBL - DNS black list - a mechanism utilitizing DNS that has been seen recently. By performing a DNS lookup on the address of a connecting client, a mail server determines whether to accept the connection based in the response of the DNSBL. There are no DNS white lists that I am aware of.

Resources

http://amtp.bw.org/docs/draft-weinman-amtp-02.txt
Anti-Spam Research Group
RFC 2487 - SMTP Service Extension for Secure SMTP over TLS
Certificate Authority Services
Certificates and PKI

Update 2004/01/31

I've taken my follow-up research on this matter over to Credentia - including instructions on enabling certificate verif ication and using STARTTLS on various MTAs.

© 2003 Mark Foster

$Id: secure-email.html,v 1.8 2005/11/12 16:36:00 mdf Exp $