I haven't really waded into this iteration of the discussion because there isn't really new information to talk about. But I know everyone is acting in good faith so I'll offer my pov again. We're all trying to serve our users and the Internet - same team :)
OE means ciphertext is the new plaintext. This is a transport detail. Of course https:// is more secure than http:// of any form. This isn't controversial - OE proponents believe this too :) Its a matter of opinion exactly how common, comprehensive, and easy downgrade to cleartext will be in practice - but its trivially easy to show an existence proof. Therefore, given the choice, you should be running https://. full stop. However, in my opinion https deployment is not trivially easy to do all the time and in all environments and as a result tls based ciphertext is an improvement on the defacto cleartext alternative. Particularly at scale using forward-secret suites mixed in with https:// traffic it creates an obstacle to dragnet interception. tofu pinning is another possibility that helps especially wrt mobility. Its a matter of opinion how big of an obstacle that is. I get feedback from people that I know are collecting cleartext right now that don't want us to do it. That's encouraging. https:// has seen very welcome growth - but ilya's post is a bit generous in its implications on that front and even the most optimistic reading leaves tons of plaintext http://. If you measure by HTTP transaction you get an amount of https in the mid 50%'s (this is closer to Ilya's approach) and our metrics match the post about chrome.. However, if you measure by page load or by origin you get numbers much much lower with slower growth. (we have metrics on the former - origin numbers are based on web crawlers).. if you measure by byte count you start getting ridiculously low amounts of https. I want to see those numbers higher, we all do, but I also think that bringing some transport confidentiality to the fraction you can't bring over to the https:// camp is a useful thing for the confidentiality of our users and it doesn't ignore the reality of the situation. There are lots of reasons people don't run https://. The most unfortunate one, that OE doesn't help with in any sense, is that this choice is wholly in the hands of the content operator when the cost of confidentiality loss is borne at least partially (and perhaps completely) by the user. But that's not the only reason - mixed content, cert management, application integration, sni problems, pki distrust, ocsp risk, and legacy markup are just various parts of the story why some content owners don't deploy https://. OE can help with those - those sites aren't run by folks with google.com like resources to overcome them all. There are other barriers OE can't help with such as hosting premium charges. Its a false dichotomy to suggest we can't work on mitigations to those problems to encourage https and also provide OE for scenarios that can't be satisfied that way. This isn't hypothetical - we absolutely are both walking and chewing gum at the same time already on this front. I don't really believe many in the position to choose between OE and https would choose OE - I expect it to be used by the folks that can't quite get there. OE doesn't change the semantics of web security, so if I'm wrong about OE's relationship to https transition rates we can disable it - it has no semantic meaning to worry about compatibility with: ciphertext is the new plaintext but the web (security and other) model is completely unchanged as this is a transport detail. Reversion is effectively a safety valve that I would have no problem using if it were necessary. Thanks. -Patrick On Wed, Nov 12, 2014 at 8:23 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > 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 > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
