Authenticating E-Mail

Published: 2012-06-15
Last Updated: 2012-06-15 14:48:00 UTC
by Johannes Ullrich (Version: 1)
12 comment(s)

We got a lot of responses to yesterday's "fake Verizon" e-mail. This brings (again) up the topic of authenticating e-mail messages. If you are reading this post, you probably already realize that the "From" header, like anything else transmitted in a default email, doesn't do a thing to authenticate an e-mail message. There are a number of technologies that can be deployed to help this.

1 - SMTP over SSL

There are a number of methods to run SMTP and other mail related protocols over SSL (pop, imap...) . SMTP in particular frequently uses the "STARTTLS" protocol which can start an SSL connection "on the fly" if both servers support it. SSL however only protects the connection. The receiving mail server can verify the identity of the sending mail server, and the connection can be encrypted. In most implementations I have seen, the certificate is not verified, and the SSL connection is optional, which significantly reduces the value of this technique, in particular between mail servers. For mail clients sending e-mail to trusted mail servers, SMTPS can be a meaningful control if for example a VPN isn't available. But the main issue is that e-mail is forwarded from server to server, and the sender or recipient have no control if the path the email took was secure.

2 - DKIM

DomainKeys Identified Mail (DKIM) [1] is mostly an anti-spam feature. It will authenticate if a mail server is authorized to send e-mail on a particular domain's behalf. At this point, some major e-mail providers like Yahoo will implement DKIM. However, aside from its limited scope, DKIM suffers from a number of implementation issues. First of all, it is typically not a default component of mail servers, but has to be added on via a patch or additional software packages. Secondly, once implemented, e-mail for a particular domain has to be sent via authorized mail servers. A users working from home may no longer use his or her ISP's mail server, but has to send e-mail via the corporate mail server. In most cases, this is a good thing, but it can be difficult to implement. The neat part about DKIM is that keys are distributed via DNS, and that validation is done on the server without user involvement. Of course, the use of DNS also requires a secure DNS infrastructure.

3 - PGP

PGP is probably the oldest form of e-mail encryption and authentication. It does provide end-to-end verification of a message or part of a message. It is very flexible in that it can be used to verify the entire message, or just parts of it. Headers are usually not included in the signature, but since the signature is linked to an e-mail address, it can still be used to authenticate the sender. In my opinion, PGP (and GPG for that matter) suffers from two big problems: First of all, support is available for most e-mail clients, but usually not included by default, requiring users to install and configure additional software. Software for iOS for example is available, but poorly integrated with the default iOS mail client. Secondly, PGP key management is not intuitive to the average user. It lacks the use of a central "certificate authority" and leaves it up to the user to trust or not to trust a key. combined with the limited use of PGP in day-to-day e-mail use, this is a big challenge. Usually it is best to establish the validity of a PGP key by continuously using it for all e-mail, making it easier to spot unusual or different keys.

4 - S/MIME

S/MIME probably has the best chance at this point of gaining some acceptance. It does use certificate authorities, so unlikely PGP the decision to trust a certificate is removed form the user to some extend. But as other uses of certificate authorities have shown, this isn't all that safe either. However, I think for the average user (one that hasn't attended a key signing party yet), this is preferred over the decentralized method used by PGP. The main issue with S/Mime is that it does sign the entire message including headers, and there is no option to only sign part of the message. This leads to broken signatures if a message is forwarded to a mailing list or passes other remailers that change headers. But S/Mime has been widely implemented by default in many e-mail clients, including mobile clients.

I really wish more people would take advantage of any of these technologies to verify e-mail. Any e-mail, including e-mail sent by automated processes, should be signed. I think user awareness will follow once users see more signed e-mail. Most of the automated e-mail we sent for ISC/DShield uses PGP signatures and we are working on implementing it for more of our e-mail. DKIM hasn't been an option for us so far as our organization is too decentralized, and for our audience PGP has shown to work pretty well and easier to implement then S/Mime for our scripts. My personal e-mail is usually S/MIME signed. 

[1] http://www.dkim.org/

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: email pgp smime
12 comment(s)

Comments

DMARC looks like a good up-and-comer. It combines SPF and Domain Keys AND gives the legitimate domain owner the ability to see who is sending using their domain but getting failed. Finally, a way to be proactively notified about phishing using your domain name.

www.dmarc.org - Their About page shows a lot of heavy hitters are alreeady signed on:

Receivers: AOL, Comcast, GMail, Hotmail, Yahoo! Mail

Senders: American Greetings, Bank of America, Facebook, Fidelity, LinkedIn, Paypal

Intermediaries & Vendors: Agari, Cloudmark, eCert, ReturnPath, Trusted Domain Project
DKIM is _not_ "mostly an anti-spam feature". All DKIM does is cryptographically link a domain to an email. So if an email is DKIM-signed by example.com then you know for sure that... it was DKIM-signed by example.com.

That may not sound very powerful at first, but anything (but the sender's IP address) in an email can be forged. So this gives for instance a spam filter the option to correctly deliver an email.

Only with the introduction of DMARC earlier this year has a reliably way arisen for DKIM to be used as some kind of requirement for email sent from a certain domain, that is: before DMARC it was generally a bad idea to consider email from example.com without a DKIM-signature from example.com to be forged.
The #1 thing for PGP/GPG is the fact that it can be deployed guerilla-style if need be.
Anybody know of a cheap or Free S/MIME cert. Thawte use to have some but a year or two back dropped them. Use PGP but its always good to have an option that works with any novice on the other end.
No mention of SPF? DMARC is worthy of mention, but it's hard to get excited about given how little traction SPF got. plus, I'm not sure how much any of these will really help with phishing. Unless you can somehow bind the content of the body of the message itself to the sender, then social engineering is going to happen. Most people simply don't know enough to validate the other identifiers and it's not fair to expect them to given how frequently legitimate mail misuses them.
@mrgushi: Mozilla has a list of free S/MIME certificates here: http://kb.mozillazine.org/Getting_an_SMIME_certificate
Also no mention of TLS on TCP 25. SMTPS runs on TCP 465 for inbound and we rarely see connection attempts. Almost everyone seems to runs TLS nowadays.

None of this matters much when a mass-email marketing company validated by SPF and DomainKeys sends out a malicious email to their customer's customers. We received some today. It will be interesting to see how the rest of this story turns out.

SPF was slow to get going but lots of sites use it today. Check out this May 2012 story in American Banker. I'll bet a lot more banks will be sporting shiny new SPF records soon. :-)

http://www.americanbanker.com/issues/177_99/phishing-spear-phishing-hacks-1049511-1.html?zkPrintable=true
Thanks to everyone who mentioned DMARC; it was definitely worth looking at. I went ahead and tried it on a few domains and it's already shown me some cases where DKIM c=strict/strict was a problem. I can imagine the reports being really helpful for those who had stuck with SPF "~all" for now, because they weren't sure yet if all their mail is using the right outgoing servers.
@JJ: I assume that when you say "mass-email marketing company" you mean illegal spammers? No legitimate marketing company would ever send out a malicious email as, even if it was accidental, it would damage the reputation of both the company and its customer so badly that it would be suicide to do so. The marketing company would also be open to prosecution, of course.
@jwhitlow Thanks for the info

Diary Archives