Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

On Opportunistic Encryption

Opportunistic encryption has become quite a hot topic recently, and blew up in a big way thanks to an Internet Draft that was published on February 14th for what amounts to sanctioned man-in-the-middle. Privacy advocates were quickly up in arms – but it’s not that simple (see here). As pointed out by Brad Hill, this isn’t about HTTPS traffic, but HTTP traffic using unauthenticated TLS; thanks to poor wording in the document, it’s easy to miss that fact if you just skim it.

It’s routine practice for ISPs to MITM unencrypted traffic today; it’s well-known that Comcast does it. This practice won’t change once we move to HTTP2, regardless of unauthenticated TLS – the only question is will users know about it.

But this isn’t about that single internet draft, it’s about what this tells us about opportunistic encryption.

We’ve seen many smart people get very upset (myself included) over a misunderstanding about how opportunistic encryption fits into the new HTTP2 paradigm. What does that tell us about how it’ll be perceived in the future?

What does opportunistic encryption buy us? #

We can break attackers down into two classes:

  • Active – Will intercept and re-route traffic, at small or large scale.
  • Passive – Will watch what goes over the wire, but is unable or unwilling to interfere with it.

Opportunistic encryption prevents passive attackers from being able to collect data, they will either fail or be forced into an active role (if they are positioned and financed to do so). While many talk about increasing the cost of surveillance for groups like the NSA, I doubt that will create a substantial impact – we know that they are both active and passive today. So they are positioned for active attacks when they so desire, though there may be some reduction of monitoring lower value targets due to increased complexity / resource demands.

What opportunistic encryption doesn’t do #

Unauthenticated TLS skips the most vital step in the process – it doesn’t verify that the server is actually the one you intend to talk to, meaning anyone that can control network traffic between you and the end server, can pretend to be the end server, monitoring all traffic. Which is, exactly what we have today with HTTP traffic.

So, you know your traffic is encrypted, what you don’t know is who has the keys, or how many people have seen the traffic. You’re safe from passive threats, but it provides no protection against active threats – but it’s also not intended to.

Should we pursue it? #

If people weren’t involved – it eliminates a class of attacks without substantial costs, and forces passive attackers to become active. Overall, that sounds like a win, but there’s a problem: people.

Opportunistic encryption isn’t real security, it doesn’t stand up to active attackers – it provides protection against only a specific type of attack. Real TLS provides protection against both active and passive threats. If people understood this, opportunistic encryption would be fine – but people don’t understand that, that’s clear.

If people see it as a “just works” alternative to real TLS, then the harm it does greatly outweighs the value it provides. It will give a false sense of security, when in reality there is none.

Adam Caudill

Related Posts

  • Security By Buzzword – Why I don’t support Ensafer

    Update: I had a call with Ensafer’s CTO, Trygve Hardersen to discuss the issues I brought up, and what they can do about it. First, they updated the site so that downloads are now over HTTPS. He stated that the infrastructure that powers their service is separate from the website, and everything is over HTTPS. They are working on making documentation available, and hope to have the first documents available soon.

  • Worried about the NSA? Try AES-512!

    …or, The Cost of Wild Speculation. “We need to boost our security – I think the NSA has broken everything we use. AES-256 is too weak, I don’t trust it. Find a way to implement AES-512.” Double-AES-256! It’d be easy, and double encrypting has never bitten us before. So, let’s write some code! def encrypt(msg, iv, key) return e(e(msg, iv, key.slice(0..31)), iv, key.slice(32..63)) end def decrypt(cipher, iv, key) return d(d(cipher, iv, key.

  • SMIMP at the DEFCON Crypto Village

    Last week I gave a lighting talk at the DEFCON CryptoVillage on SMIMP. The talk went over the basics of why the project is needed, and how the specification works. Here are the slides: Here is a rough transcript of the talk: Slide 1: I’m Adam Caudill, I’m a developer and security researcher; I work on a number of different things, but my recent work has been around privacy and secure messaging.

  • The Sinking Ship of E-Mail Security

    E-Mail, the venerable old standard for internet text messages, dating back to the early 1980s – and back to the early 1970s in other forms, has long been the “killer app” of the internet. While so many companies try to make the next great thing that’ll capture users around the world – none of these compare to the success of e-mail. It is likely the single most entrenched application-layer protocol used today.

  • On Apple, Privacy, and Device Control

    If you’ve bothered to look at Twitter or any technology news source, you’ve seen that Apple made a major announcement: Expanded Protections for Children. This has been written about by countless outlets, so I’ll assume you’re familiar with the basics. The announcement covered a few new features being added to the next version of Apple’s operating systems, namely: Scanning of inbound and outbound messages for sexually explicit images. Scanning images being uploaded to iCloud for CSAM.