Pgp

EFAIL PGP / S/MIME "flaw" ?

There’s going to be a lot of hype today about something the security researchers who found it are calling “EFAIL”. Interviews, commemorative T-Shirts, press tours, hype.
The technical details are interesting, but the un-hyped end-user advice would probably be “If you’re using a mail client that’s got bugs in it’s MIME handling, and you’ve configured it to load remote content automatically, and you’re using a less secure encryption tool or protocol, and you’ve configured it to decrypt things automatically, and security of your email is so important to you that you’re defending against skilled attackers who have already acquired the encrypted emails you’re concerned about (by compromising your ISP? Sniffing non-TLS traffic?) then you may have a problem.”
I can’t imagine anyone for whom email security is a critical issue would make all those mistakes, so this mostly merits a heads-up to the MUA developers (which has happened) and maybe a “Do people rely on S/MIME? Why?” retrospective. But as someone on twitter described it “The Vulnerability Hype Train has begin, choo choo.”
 

 
There are several different issues all mixed together by the efail folks. All of them require an attacker to already have access to (encrypted) sensitive emails, and to send copies of those to you wrapped up in another message and to have you decrypt that incoming mail.

Read More

September 2014: The Month in Email

September was another busy month for us, but Steve stepped up and wrote a number of really interesting posts on email history, cryptography, and current technical issues in the email landscape.
We started the month with a look at the various RFCs that served as the technical specifications for developing message transfer protocols in the 1970s. It’s really fascinating to look at the evolution of these tools we use every day 40 years later. We followed up with a second post on the origins of network email, which is a great primer (or refresher) on the early days of email.
Steve’s four-part series on cryptography and email started with an in-depth look at how the industry is evolving with respect to encryption and privacy issues. He then introduced us to Alice and Bob (or reintroduced those of us who have been following the adventures of the first couple of cryptography), and described symmetric-key and public-key encryption. His next post described message signing, and how DKIM is used to manage this. He finished up the series with a post on PGP keys.
In industry news: Spamcop is shutting down its email service. There shouldn’t be any major impact on senders, but the post has some specific notes on DMARC implications. We also noted an interesting mail routing suggestion on Twitter, and wrote a post on using Mail.app for this.
In other DMARC news, we wrote about DMARC and report size limits, which might be useful information, depending on your configuration. We also launched a new DMARC tool to help senders understand who is publishing DMARC. Let us know what you think and if you’re finding it useful.
We couldn’t let a month go by without mentioning filters. We looked at a sector we don’t usually discuss, corporate filtering, and went in-depth on a much-misunderstood topic, content filtering.
Finally, Laura offered a webinar on a favorite topic, deliverability, in conjunction with the AMA and Message Systems. If you missed it, you can watch the recorded version here, or just take a peek at some of the reaction via Twitter.

Read More

Alice and Bob and PGP Keys

Last week Alice and Bob showed how to cryptographically sign messages so that the recipient can be sure that the message came from the purported sender and hasn’t been forged by a third party. They can only do that if they can securely retrieve the senders public key – which means they need to retrieve it from the actual sender, rather than an impostor, and be sure it’s not tampered with en route. How does this work in practice?
If I want to send someone an encrypted email, or I want to verify that a signed email I received from them is valid, I need a copy of their public key (almost certainly their PGP key, in practice). Perhaps I retrieve it from their website, or from a copy they’ve sent me in the past, or even from a public keyserver. Depending on how I retrieved the key, and how confident I need to be about the key ownership, I might want to double check that the key belongs to who I think it does. I can check that using the fingerprint of the key.
A key fingerprint looks like this:

Read More

Cryptography and Email

A decade or so ago it was fairly rare for cryptography and email technology to intersect – there was S/MIME (which I’ve seen described as having “more implementations than users”) and PGP, which was mostly known for adding inscrutable blocks of text to mail and for some interesting political fallout, but not much else.
pgp
That’s changing, though. Authentication and privacy have been the focus of much of the development around email for the past few years, and cryptography, specifically public-key cryptography, is the tool of choice.
DKIM uses public-key cryptography to let the author (or their ESP, or anyone else) attach their identity to the message in a way that’s almost impossible to forge. That lets the recipient make informed decisions about whether to deliver the email or not.
DKIM relies on DNS to distribute it’s public keys, so if you can interfere with DNS, you can compromise DKIM. More than that, if you can compromise DNS you can break many security processes – interfering with DNS is an early part of many attacks. DNSSEC (Domain Name System Security Extensions) lets you be more confident that the results you get back from a DNS query are valid. It’s all based on public-key cryptography. It’s taken a long time to deploy, but is gaining steam.
TLS has escaped from the web, and is used in several places in email. For end users it protects their email (and their passwords) as they send mail via their smarthost or fetch it from their IMAP server. More recently, though, it’s begun to be used “opportunistically” to protect mail as it travels between servers – more than half of the mail gmail sees is protected in transit. Again, public-key cryptography. Perhaps you don’t care about the privacy of the mail you’re sending, but the recipient ISP may. Google already give better search ranking for web pages served over TLS – I wouldn’t be surprised if they started to give preferential treatment to email delivered via TLS.
The IETF is beginning to discuss end-to-end encryption of mail, to protect mail against interception and traffic analysis. I’m not sure exactly where it’s going to end up, but I’m sure the end product will be cobbled together using, yes, public-key cryptography. There are existing approaches that work, such as S/MIME and PGP, but they’re fairly user-hostile. Attempts to package them in a more user-friendly manner have mostly failed so far, sometimes spectacularly. (Hushmail sacrificed end-to-end security for user convenience, while Lavabit had similar problems and poor legal advice).
Not directly email-related, but after the flurry of ESP client account breaches a lot of people got very interested in two-factor authentication for their users. TOTP (Time-Based One-Time Passwords) – as implemented by SecureID and Google Authenticator, amongst many others – is the most commonly used method. It’s based on public-key cryptography. (And it’s reasonably easy to integrate into services you offer).
Lots of the other internet infrastructure you’re relying on (BGP, syn cookies, VPNs, IPsec, https, anything where the manual mentions “certificate” or “key” …) rely on cryptography to work reliably. Knowing a little about how cryptography works can help you understand all of this infrastructure and avoid problems with it. If you’re already a cryptography ninja none of this will be a surprise – but if you’re not, I’m going to try and explain some of the concepts tomorrow.

Read More