I’m not all that enthused by the blow-by-blow here. Nonetheless, there are some distortions to correct.
> On 2014-11-12, at 20:23, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > > 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 .) This is true for TLS <= 1.2, but will not be true for TLS 1.3. Certificates are available to a MitM currently, but in future versions, that sort of attack will be detectable. > 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. 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. > 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. 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). _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
