On Mon, Sep 22, 2014 at 9:36 PM, Chris Palmer <pal...@google.com> wrote: > On Mon, Sep 22, 2014 at 5:56 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > >>> -- HTTP Strict Transport Security >> >> Yes, but I think this requirement shouldn't apply to subresources for >> the page to qualify, since top-level HSTS together with the "No mixed >> content" requirement mean that there's no sslstrip risk for embedded >> resources even if they are served from a non-HSTS CDN. > > These days we're blocking loads of active mixed content, but passive > mixed content is still a concern to me. E.g. an attacker can mangle a > web app's UI pretty badly, including to perform attacks, if the app > gets its icons and buttons via SSLstrip-able sources.
My point was that if the HTML is served from HSTS-enabled https://hsts.example.com/ and in has <img src='https://cdn.example.org/foo.png'>, the image is not SSLstrip-able even if cdn.example.org doesn't support HSTS. I think it would be a mistake to make the bar for the new indicator needlessly high--especially in a way that would require pleading with an external CDN to resolve. > HPKP is indeed dangerous. > > I don't anticipate any additional UI for it, let alone additional UI > that would motivate a not-ready-yet ops team to turn it on. OK. >> It seems to me that it's at least currently impractical for small >> sites to get CAs to commit to issue future certs from a particular >> root or intermediate, so it seems to me that especially pinning an >> intermediate is hazardous unless you are big enough a customer of a CA >> to get commitments regarding future issuance practices. > > Intermediates move slowly, and roots even more slowly. It's fairly > safe to assume that, for the lifetime if your end-entity cert, the CA > will still be operating, and if that they can and will cross-sign in > cases where they re-key heavily-used issuing certs. The thing is that "fairly safe to assume" isn't really good enough if your site becomes unreachable for a year if the assumption is wrong. Current best practice with intermediates is to always re-download intermediates when renewing the end-entity cert, because the intermediate *might* have changed. As for roots, major CAs have numerous roots and at least if you are paying at the cheapest tiers, there doesn't seem to be any ahead-of-time commitment from CAs to use a particular root. Looking at Twitter's pre-pins in Chrome, it seems that even Twitter isn't counting on an ahead-of-time commitment for future issuance to happen from a particular root. (Moreover, I don't see Twitter actually serving hashes for the all the CA roots that are pre-pinned for them as HTTP headers. In fact, I don't see them serving any pinning headers at all. Especially in the CDN case, it might be a tough sell that you 1) have to research a large number of roots, just in case, and 2) stick the hashes of a large number of roots (amounting to a large number of bytes) in every response.) Maybe HKPK will lead to CAs making dependable statements about future issuance relative to intermediates and roots, but it's too early to rely on that sort of thing before it actually happens. > But, yeah, have a backup pin, and pin at various places in the > certificate chain. My point is that 1) I want the new indicator to improve the long tail, too, not just big sites, so I want the new indicator to be practically available to sites that are low-end customers from the CA perspective and 2) if you are a low-end customer for a CA, AFAICT, there's no *sure* way to have a backup pin. > I'd advise people to look at > net/http/transport_security_state_static.json and consider what > Dropbox, Google, Twitter, and Tor have done, and why. I've taken a look and, whoa, that's *complicated*! Again (I saw we already agreed; mainly talking to others who might be reading), requiring sites to deal with that sort of complication before they get the new badge would mean few sites would go for the new badge and the badge wouldn't have much impact. OTOH, if the story was that you copy and paste lines like ssl_ciphers ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA; ssl_prefer_server_ciphers on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_dhparam /etc/nginx/ssl/dh-2048.pem; ssl_stapling on; resolver a.b.c.d; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; in your server config and you get a new badge, chances are that the new badge would have a lot more impact. Getting admins to even copy and paste the above would be quite an improvement over the status quo. >> It's unclear to me if HPKP makes it safe and practical to use without >> actually forming a business relationship with two CAs in advance >> (which would be impractical for many small sites). It seems to me that >> HPKP makes it possible to generate a backup end-entity key pair in >> advance of having it certified. However, the spec itself discourages >> end-entity pinning altogether and it's pretty scary to pin a key >> before you know for sure you can get it certified by a CA later. > > I wouldn't say we discourage EE pinning; but I would discourage > pinning EEs *exclusively*. I read "Security Considerations" as discouraging end-entity pinning, but OK. >> (In some way, it seems like HPKP is the simplest thing that makes >> sense for Google, which has its own intermediate, but for the rest of >> us, being able to maintain a TACK-style signing key *to the side of* >> the CA-rooted chain would be better. What's the outlook of us >> supporting TACK or some other mechanism that allows pinning a >> site-specific signing key that's not part of the CA-rooted chain?) > > I consider a backup pin to be enough like an "on the side" pin. But, > however, you may not. If I'm a small-time customer from the CA perspective and CAs won't make commitments about future issuance practices to me, I can't rely on just pinning two intermediates. Pinning all the roots of a bunch of CA would bloat the responses by quite a bit. Buying two certs from different CAs right away would double my cert costs up front and it's hard enough to make people pay for certs at all. If I mint two keys, pin both of them but have only one certified up front, there's the risk that for some reason by the time there's a need to get the other one certified, things won't work out for some reason. (The key generation and pinning was simply botched and never tested [most likely], a catastrophic RNG bug was discovered in the mean time [unlikely but has happened; CAs check for Debian weak keys] or some requirement like minimum key size changed [very unlikely to happen with less than a year of notice]. The first one, i.e. just botching something at the site's end and never testing is by far the most likely problem.) On Mon, Sep 22, 2014 at 11:41 PM, Ryan Sleevi <ryan-mozdevsecpol...@sleevi.com> wrote: > That is, the TSK is almost invariably going to get lost, or someone will > forget the password, or the person who creates the TSK will forget to back > it up and format their machine, or any number of things we _routinely_ see > with SSL certs (and precisely why implicit pinning to EE certs is hard). > The only people who will be able to safely deploy TACK are a subset of > those who can safely deploy HPKP. All these problems (and more) apply to pinning end-entity keys with HPKP and, as indicated above, at the low end, you can't really rely on the CAs keeping the intermediates stable for pinning for you. (Especially not the other CA you aren't even a customer of yet.) :-( (Note that I think HPKP is a valuable addition to the platform above the low end. I'm just arguing that we shouldn't make HPKP as-is a requirement for the new badge in order to make the long tail chase the new badge, too.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
