> On 2014-11-13, at 21:25, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> Your argument relies on there being no prior session that was not >> intermediated by the attacker. I’ll concede that this is a likely situation >> for a large number of clients, and not all servers will opt for protection >> against that school of attack. > > What protection are you referring to?
HTTP-TLS (which seems to be confused with Alt-Svc in some of the discussion I’ve seen). If you ever get a clean session, you can commit to being authenticated and thereby avoid any MitM until that timer lapses. I appreciate that you think that this is worthless, and it may well be of marginal or even no use. That’s why it’s labelled as an experiment. > >>> I haven't been to the relevant IETF sessions myself, but assume that >>> https://twitter.com/sleevi_/status/509954820300472320 is true. >> >> That’s pure FUD as far as I can tell. > > 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. > 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. >> 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
