Authenticating E-Mail
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
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
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
JJ
Jun 15th 2012
1 decade ago
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.
Martijn
Jun 15th 2012
1 decade ago
Joshua
Jun 15th 2012
1 decade ago
mrgushi
Jun 15th 2012
1 decade ago
Matt
Jun 15th 2012
1 decade ago
jwhitlow
Jun 15th 2012
1 decade ago
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
JJ
Jun 15th 2012
1 decade ago
Steven Chamberlain
Jun 17th 2012
1 decade ago
patermann
Jun 18th 2012
1 decade ago
mrgushi
Jun 19th 2012
1 decade ago