On Wed, Nov 12, 2014 at 11:12 PM, Richard Barnes <rbar...@mozilla.com> wrote: > >> On Nov 12, 2014, at 4:35 AM, Anne van Kesteren <ann...@annevk.nl> wrote: >> >> On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach <a...@mozilla.com> wrote: >>> The whole line of argumentation that web browsers and servers should be >>> taking advantage of opportunistic encryption is explicitly informed by >>> what's actually "happening elsewhere." Because what's *actually* happening >>> is an overly-broad dragnet of personal information by a wide variety of both >>> private and governmental agencies -- activities that would be prohibitively >>> expensive in the face of opportunistic encryption. >> >> ISPs are doing it already it turns out. Governments getting to ISPs >> has already happened. I think continuing to support opportunistic >> encryption in Firefox and the IETF is harmful to our mission. > > You're missing Adam's point. From the attacker's perspective, opportunistic > sessions are indistinguishable from
I assume you meant to say indistinguishable from https sessions, so the MITM risks breaking some https sessions in a noticeable way if the MITM tries to inject itself into an opportunistic session. That's true if the server presents a publicly trusted cert for the wrong hostname (as is common if you try to see what happens if you change the scheme for a random software download URL to https and get a cert for Akamai--I'm mentioning Akamai because of the [unmentioned on the draft] affiliation of the other author). However, if the site presents a self-signed cert, the MITM could check the chain and treat self-signed certs differently from publicly trusted certs. (While checking the cert chain takes more compute, it's not outlandish considering that an operator bothers to distinguish OpenVPN from IMAP-over-TLS on the same port per https://grepular.com/Punching_through_The_Great_Firewall_of_TMobile .) But even so, focusing on what the upgraded sessions look like is rather beside the point when it's trivial for the MITM to inhibit the upgrade in the first place. In an earlier message to this thread, I talked about overwriting the relevant header in the initial HTTP/1.1 traffic with spaces. I was thinking too complexly. All it takes is changing one letter in the header name to make it unrecognized. In that case, the MITM doesn't even need to maintain the context of two adjacent TCP packets but can, with little risk of false positives, look for the full header string in the middle of the packet or a tail of at least half the string at the start of a packet or at least half the string at the end of a packet and change one byte to make the upgrade never happen--all on the level of looking at individual IP packets without bothering to have any cross-packet state. This is not a theoretical concern. See https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks for an analogous attack being carried out for email by ISPs. If we kept http URLs strictly HTTP 1.1, it would be clear that if you want the fast new stuff, you have to do confidentiality, integrity and authenticity properly. Sites want the fast new stuff, so this would be an excellent carrot. By offering an upgrade to unauthenticated TLS, people both at our end and at the server end expend effort to support MITMable encryption, which is bad in two ways: 1) that effort would be better spent on proper https [i.e. provisioning certs properly as far as the sites are concerned; you already need a TLS setup for the opportunistic stuff] and 2) it makes the line between the MITMable and the real thing less clear, so people are likely to mistake the MITMable for the real thing and feel less urgency to do the real thing. I haven't been to the relevant IETF sessions myself, but assume that https://twitter.com/sleevi_/status/509954820300472320 is true. If even only some operators show a preference to opportunistic encryption over real https, that alone should be a huge red flag that they intend to keep MITMing what's MITMable. Therefore, we should allocate our finite resources to pushing https to be better instead of diverting effort to MITMable things. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
