Less plain-text is better. Right?

Every connection and every user on the Internet is being monitored and snooped at to at least some extent every now and then. Everything from the casual firesheep user in your coffee shop, an admin in your ISP, your parents/kids on your wifi network, your employer on the company network, your country’s intelligence service in a national network hub or just a random rogue person somewhere in the middle of all this.

My involvement in HTTP make me mostly view and participate in this discussion with this protocol primarily in mind, but the discussion goes well beyond HTTP and the concepts can (and will?) be applied to most Internet protocols in the future. You can follow some of these discussions in the httpbis group, the UTA group, the tcpcrypt list on twitter and elsewhere.

IETF just published RFC 7258 which states:

Pervasive Monitoring Is a Widespread Attack on Privacy

Passive monitoring

Most networking surveillance can be done entirely passively by just running the correct software and listening in on the correct cable. Because most internet traffic is still plain-text and readable by anyone who wants to read it when the bytes come flying by. Like your postman can read your postcards.


Recently there’s been a fierce discussion going on both inside and outside of IETF and other protocol and standards groups about doing “opportunistic encryption” (OE) and its merits and drawbacks. The term, which in itself is being debated and often is said to be better called “opportunistic keying” (OK) instead, is about having protocols transparently (invisible to the user) upgrade plain-text versions to TLS unauthenticated encrypted versions of the protocols. I’m emphasizing the unauthenticated word there because that’s a key to the debate. Recently I’ve been told that the term “opportunistic security” is the term to use instead…

In the way of real security?

Basically the argument against opportunistic approaches tends to be like this: by opportunistically upgrading plain-text to unauthenticated encrypted communication, sysadmins and users in the world will consider that good enough and they will then not switch to using proper, strong and secure authentication encryption technologies. The less good alternative will hamper the adoption of the secure alternative. Server admins should just as well buy a cert for 10 USD and use proper HTTPS. Also, listeners can still listen in on or man-in-the-middle unauthenticated connections if they capture everything from the start of the connection, including the initial key exchange. Or the passive listener will just change to become an active party and this unauthenticated way doesn’t detect that. OE doesn’t prevent snooping.

Isn’t it better than plain text?

The argument for opportunism here is that there will be nothing to the user that shows that it is “upgrading” to something less bad than plain text. Browsers will not show the padlock, clients will not treat the connection as “secure”. It will just silently and transparently make passive monitoring of networks much harder and it will force actors who truly want to snoop on specific traffic to up their game and probably switch to active monitoring for more cases. Something that’s much more expensive for the listener. It isn’t about the cost of a cert. It is about setting up and keeping the cert up-to-date, about SNI not being widely enough adopted and that we can see only 30% of all sites on the Internet today use HTTPS – for these reasons and others.

HTTP:// over TLS

In the httpbis work group in IETF the outcome of this debate is that there is a way being defined on how to do HTTP as specified with a HTTP:// URL – that we’ve learned is plain-text – over TLS, as part of the http2 work. Alt-Svc is the way. (The header can also be used to just load balance HTTP etc but I’ll ignore that for now)

Mozilla and Firefox is basically the only team that initially stands behind the idea of implementing this in a browser. HTTP:// done over TLS will not be seen nor considered any more secure than ordinary HTTP is and users will not be aware if that happens or not. Only true HTTPS connections will get the padlock, secure cookies and the other goodies true HTTPS sites are known and expected to get and show.

HTTP:// over TLS will just silently send everything through TLS (assuming that it can actually negotiate such a connection), thus making passive monitoring of the network less easy.

Ideally, future http2 capable servers will only require a config entry to be set TRUE to make it possible for clients to do OE on them.

HTTPS is the secure protocol

HTTP:// over TLS is not secure. If you want security and privacy, you should use HTTPS. This said, MITMing HTTPS transfers is still a widespread practice in certain network setups…


I find this initiative rather interesting. If implemented, it removes the need for all these application level protocols to do anything about opportunistic approaches and it could instead be handled transparently on TCP level! It still has a long way to go though before we will see anything like this fly in real life.

The future will tell

Is this just a fad that will get no adoption and go away or is it the beginning of something that will change how we do protocols in the future? Time will tell. Many harsh words are being exchanged over this topic in many a debate right now…

(I’m trying to stick to “HTTP:// over TLS” here when referring to doing HTTP OE/OK over TLS. This is partly because RFC2818 that describes how to do HTTPS uses the phrase “HTTP over TLS”…)

8 thoughts on “Less plain-text is better. Right?”

  1. Why would Mozilla support “HTTP:// over TLS” when it rejects “Silent acceptance of Self-signed-certificates”? (Quick searching found bug 433422 and 431386, where merely toning down the alerts are rejected)

  2. great idea! not…..

    adds zero security but makes any attempt at debugging network traffic much harder. In addition adds to bandwidth cost and CPU cost for the sites and user for protecting something that is 99.9% not considered worthy of hiding.

    Instead of this BS firefox should simply work on improving support for self signed certificates and that will actually help solving privacy and security issues for people that care about it.

    In addition having no visual indication is double stupid, how is a user supposed to know if his privacy protected or not?

  3. Anders: because HTTPS is meant to be secure and protect privacy. HTTP is not.

    Mark: because it is unauthenticated and thus you cannot know you’re not being actively monitored, the padlock etc are for authenticated connections that are “secure”.

    And about “zero security”, I tried to explain the different camps in my text and then I guess we know in which of those camps you end up in.

    Work on HTTPS (and self-signed certs and what not) I consider somewhat independent and I’m sure there’s lots of areas to improve there. We can work on many different things, improvements and experiments at the same time!

  4. With “silent acceptance” I meant that no security indicators should be shown: no padlock, no green, and no “s” (or at least grayed/striked out).

  5. I can see how that could be a way to ask for more explicit “opportunism” but it also sounds like a downgrade “attack” waiting to happen since it is an explicit HTTPS URL which I consider is a major difference. I haven’t followed those bugs or that suggestion so I can’t tell what anyone’s motivation has been other than what is publicly available already.

  6. One detail I have not seen mentioned enough is that active monitoring is not only more expensive, but also can be caught – even after the fact (for example if you’re capturing the network traffic at the server and at the client and then compare them at a later date – a MITM attack would be evident).

    So large scale eavesdropping would be caught rather soon, and attackers would have to think twice because of the risk (they’d have no way to detect they’re being caught).

    > Mozilla and Firefox is basically the only team that initially stands behind the idea of implementing this in a browser.

    I thought Google was behind this too.

  7. “Server admins should just as well buy a cert for 10 USD and use proper HTTPS.”

    I have quite a few native applications that provide a server and a web-based interface (Plex media server, uTorrent, Oracle db, phpmyadmin, my web cam software — to name but a few). What’s more, almost all the local applications I create now use a HTTP server/browser client architecture because it’s so much more powerful and flexible.

    In a HTTPS-only world, do you expect the “cert for 10 USD” to work for local applications? Or is this the kind of thing Alt-Svc is aimed (imperfectly) at? If not, what do you recommend for creating applications that way?

  8. J.B: I really should not attempt to say what Google or the Chrome team are behind and let them speak for themselves, but I have not seen any of the leading figures speak out in favor for opportunistic unauthenticated TLS.

    voracity: in a HTTPS-only world, I would expect the certs to get even cheaper and yeah, I think I expect even small installations to use proper certs. But I also think there’s more to enhance to make self-signed work better etc and there will be a few use-cases that never will use HTTPS. This posting is not about HTTPS though, it is about the world that is not TLS-enabled to start with!

Comments are closed.