On Thu, Nov 13, 2014 at 8:29 PM, Martin Thomson <m...@mozilla.com> wrote: > 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.
Great. I was unaware of this. (This is particularly nice to hear after the move from NPN to ALPN going the other way.) > 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? The draft has only this: "Once a server has indicated that it will support authenticated TLS, a client MAY use key pinning [I-D.ietf-websec-key-pinning] or any other mechanism that would otherwise be restricted to use with HTTPS URIs, provided that the mechanism can be restricted to a single HTTP origin." ...which seems too vague to lead to interoperable implementations. Also, it seems that the set of sites that have the operational maturity to deploy key pinning but for whom provisioning publicly trusted certs is too hard/expensive is going to be a very small set--likely a handful of CDNs who haven't yet responded to the competitive pressure from Cloudflare to buy publicly trusted certs in wholesale but will eventually have to anyway. >> 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? 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/ ? > 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.) On Thu, Nov 13, 2014 at 10:08 PM, Patrick McManus <mcma...@ducksong.com> wrote: > 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. This is obvious to everyone reading this mailing list. My concern is that if the distinction between http and https gets fuzzier, people who want "encryption" but who want to avoid ever having to pay a penny to a CA will think that http+OE is close enough to https that they deploy http+OE when if http+OE didn't exist, they'd hold their nose, pay a few dollars to a CA and deploy https with a publicly trusted cert (now that there's more awareness of the need for encryption). > 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. OE is a strict improvement over cleartext if the existence of OE doesn't cause sites that in the absence of OE would have migrated to https in the next couple of years to migrate only to OE. That is, things that are technically improvements can still be distractions that harm the deployment of the further improvements that are really important (in this case, real https). OTOH, point 8 at http://open.blogs.nytimes.com/2014/11/13/embracing-https/ suggests that holding better performance hostage works as a way to drive https adoption. > Particularly at scale using forward-secret suites mixed in with https:// > traffic it creates an obstacle to dragnet interception. If the upgrade takes place, yes. > tofu pinning is > another possibility that helps especially wrt mobility. TOFU pinning seems rather hand-wavy at this point, so I think it's not well enough defined to base assessments about the merit of http+OE on. Also, if TOFU pinning for http+OE existed, it would mean that server admins who deploy http+OE have to care about key management in order to avoid TOFU failures arising from random rekeying. This would bring the deployability concerns of http+OE even closer to those of real https, which would make it even sillier not to just do the real thing. Specifically, https+HSTS requires you to: * Configure the server to do TLS. * Bear the performance burden of the server doing TLS. * Add a header to all responses from port 443. * Configure port 80 to redirect to https. * Be careful about minting new keys. * Obtain and provision a publicly-trusted cert for each key. * Test this stuff. http+OE requires you to: * Configure the server to do TLS. * Bear the performance burden of the server doing TLS. * Add a header to all responses from port 80. * Test this stuff. http+OE+TOFU would require you to: * Configure the server to do TLS. * Bear the performance burden of the server doing TLS. * Add a header to all responses from port 80. * Be careful about minting new keys. * Test this stuff. The pessimistic way of looking at this is that http+OE and http+OE+TOFU especially involve most of the substantial trouble that you'd have to go through to deploy proper https+HSTS, so giving people the opportunity to stop short of going all the way is harmful. The optimistic way of looking at this is that http+OE is a great gateway drug for https+HSTS, because you have to do so many of the same things that in the end it's just silly not to take the last step of getting a proper cert. However, I don't see the proponents of http+OE themselves even argue the gateway drug angle. > 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. That indeed is a good sign. > 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. If one subscribes to the logic that "something is better than nothing, therefore http+OE is better than old http", it makes no sense to turn around and forgo the protections that PKI has to offer because PKI has issues. That is, if one believes "something is better than nothing, therefore http+OE is better than old http", it doesn't make sense not to believe "something is better than nothing, therefore PKI is better than no PKI"--especially when defeating PKI is quite a bit harder than defeating OE. The demise of XP and rising feasibility of SNI will take care of the hosting charge issue for most workloads. Hopefully, Cloudflare's pricing will take care of the remaining workloads. HSTS provides a safety net for legacy markup. The OCSP risk point is *really* sad. Right now, OCSP is worse than nothing: OCSP doesn't have the upside of catching MITMs, since the MITM can block OCSP traffic, but OCSP has the downside of causing downtime when a stale OCSP response has gotten stuck in a cache somewhere and the downside of leaking browsing behavior to a third party when stapling isn't in use. If https://bugzilla.mozilla.org/show_bug.cgi?id=1010068 makes sense on mobile, why not do it on desktop, too, to get rid of the downside of OCSP? (OCSP doesn't really make sense without "must staple" and then stapling.) > 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. The opportunity cost issue of less of a concern at our end, but it seems very real at the site's end. If a site is satisfied doing http+OE, the site isn't doing https+HSTS, because for practical purposes, the two are really mutually exclusive. Any time a site does http+OE to save a bit on money and trouble on certs but would have done https+HSTS if http+OE didn't exist, it's a loss. > 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. What's the plan for measuring OE's relationship to https transition rates? If the availability of OE becomes the reality, how would you know how https transition would have gone in its absence? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
