On Fri, Nov 14, 2014 at 8:00 PM, Patrick McManus <mcma...@ducksong.com> wrote: > > On Thu, Nov 13, 2014 at 11:16 PM, Henri Sivonen <hsivo...@hsivonen.fi> > wrote: >> >> The part that's hard to accept is: Why is the countermeasure >> considered effective for attacks like these, when the level of how >> "active" the MITM needs to be to foil the countermeasure (by >> inhibiting the upgrade by messing with the initial HTTP/1.1 headers) >> is less than the level of active these MITMs already are when they >> inject new HTTP/1.1 headers or inject JS into HTML? > > There are a few pieces here - > 1] I totally expect what you describe about signalling stripping to happen > to some subset of the traffic, but an active cleartext carrier based MITM is > not the only opponent. Many of these systems are tee'd read only dragnets. > Especially the less sophisticated scenarios.
I agree that http+OE is effective in the case of mere read-only fiber splitters when no hop on the way inhibits the upgrade. (The flipside is, of course, that if you have an ISP inhibiting the upgrade as a "small time" attack to inject ads, a fiber split at another hop gets to see the un-upgraded traffic.) > 1a] not all of the signalling happens in band especially wrt mobility. The notion that devices move between networks that change the contents of IP packets and networks that deliver IP packets without changing their contents and upgrade signals seen in the latter kind of network getting remembered for the first kind makes sense, yes. But this isn't really about whether there exist some cases where OE works but about whether OE distracts from https. > 2] When the basic ciphertext technology is proven, I expect to see other > ways to signal its use. > > I casually mentioned a tofu pin yesterday and you were rightly concerned > about pin fragility - but in this case the pin needn't be hard fail (and pin > was a poor word choice) - its an indicator to try OE. That can be downgraded > if you start actively resetting 443, sure - but that's a much bigger step to > take that may result in generally giving users of your network a bad > experience. > > And if you go down this road you find all manner of other interesting ways > to bootstrap OE - especially if what you are bootstrapping is an > opportunistic effort that looks a lot like https on the wire: gossip > distribution of known origins, optimistic attempts on your top-N frecency > sites, DNS (sec?).. even h2 https sessions can be used to carry http schemed > traffic (the h2 protocol finally explicitly carries scheme as part of the > transaction instead of making all transactions on the same connection carry > the same scheme) which might be a very good thing for folks with mixed > content problems. Most of this can be explored asynchronously at the cost of > some plaintext usage in the interim. Its opportunistic afterall. > > There is certainly some cat and mouse here - as Martin says, its really just > a small piece. I don't think of it as more than replacing some plaintext > with some encryption - that's not perfection, but I really do think its > significant. I think the idea that there might be other signals is a bad sign: It's a sign that incrementally patching up OE signaling will end up taking more and more effort while still falling short of https that is already available for adoption and available even in legacy browsers. Also, it's a bad sign in the sense that some of the things you mention as possibilities are problems in themselves: While DNSSEC-based signaling to use encryption in a legacy protocol whose baseline is unencrypted makes some sense for protocols where the connection latency is not an important part of the user experience, such as server-to-server SMTP, it seems pretty clear that with all the focus on initial connection latency, browsers won't start making additional DNS queries--especially ones that might fail thanks to middleboxes--before connecting. (Though, I suppose when the encryption is *opportunistic* anyway, you could query DNSSEC lazily and let the first few HTTP requests go in the clear.) As for prescanning your top-N frecency, that's a privacy leak it itself, since an eavesdropper could tell what the top-N frecency is by looking at the DNS traffic the browser generates (DNSSEC infamously not providing confidentiality...). (Also, at least if you don't have a huge legacy of third-party includes that would become mixed content, https+HSTS is way easier to deploy than DNSSEC in terms of setting it up, in terms of keeping it running without interruption and in terms of not having middleboxes mess with it.) But I think the fundamental problem is still opportunity cost and sapping the current momentum of https. The idea "this is effective against read-only dragnet some of the time, therefore let's do it to improve things even some of the time" might make sense if it was an action to be taken just by the browser without the participation of server admins and had no effect on how server admins perceive https in contrast to the alternative. But it's not. The server admins need to take action to have OE supported on the sites they manage and they could put that effort into https. https may need a bit more effort than OE, but in the absence of OE, when plaintext is clearly no longer reasonable, full https is the alternative, so there's momentum to go all the way to https. If http+OE is perceived as good enough, http+OE will harm the adoption of https, and it's bad to harm the adoption of https. Right now, the message out there is that https is not only good for the privacy of the users of your site but that you get to use SPDY / HTTP/2 for performance and you get better SEO. It would be sad to undermine that by letting people have HTTP/2 performance and "good enough"--but actually MITMable--encryption without https. (Now, one might argue that OE doesn't actually need admin effort, because Web server software will be updated to enable it by default, but I think that's not going to happen, because http+OE needs another port in addition to port 80 and there will be enough HTTP servers behind firewalls that allow port 80 but block other ports [including 443] that the developers of server software won't dare break all those sites by pushing out an update that enables by default something that breaks if there is a port-80-only firewall in the way.) As for cat and mouse, I'd prefer putting our cat-and-mouse energies into patching up https PKI instead of introducing a new cat-and-mouse situation to pay attention to. (Despite being able to walk and chew gum, our end isn't 100% immune to opportunity cost issues, either.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
