On Fri, Nov 14, 2014 at 10:51 AM, Martin Thomson <m...@mozilla.com> wrote: >> How so given that >> http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 >> exists and explicitly seeks to defeat the defense that TLS traffic >> arising from https and TLS traffic arising from already-upgraded OE >> http look pretty much alike to an operator? > > That is a direct attempt to water down the protections of the opportunistic > security model to make MitM feasible by signaling its use. That received a > strongly negative reaction and E/// and operators have since distanced > themselves from that line of solution.
Seems to be an indication of what some operators want nonetheless. >> What about >> http://arstechnica.com/security/2014/10/verizon-wireless-injects-identifiers-link-its-users-to-web-requests/ >> ? What about >> http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/ >> ? > > Opportunistic security is a small part of our response to that. I don’t > understand why this is difficult to comprehend. A simple server upgrade with > no administrator intervention is very easy, and the protection that affords > is, for small time attacks like these, what I consider to be an effective > countermeasure. 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? >>> I’ve been talking regularly to operators and they are concerned about >>> opportunistic security. It’s less urgent for them given that we are the >>> only ones who have announced an intent to deploy it (and its current >>> status). >> >> Concerned in what way? (Having concerns suggests they aren't seeking >> to merely carry IP packets unaltered.) > > Concerned in the same way that they are about all forms of increasing use of > encryption. They want in. To enhance content. To add services. To collect > information. To decorate traffic to include markers for their partners. To > do all the things they are used to doing with cleartext traffic. You suggest > that they can just strip this stuff off if we add it. It’s not that easy. Why isn't stripping the HTTP/1.1 headers that signal the upgrade that easy? Rendering the upgrade signaling headers unrecognizable without stretching or contracting the bytes seems easier than adding HTTP headers or adding JS. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
