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)
ISC StormCast for Friday, June 15th 2012 http://isc.sans.edu/podcastdetail.html?id=2605

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives