On 03/27/2014 09:27 AM, Emilia Kasper wrote: > HPKP can never work this way. Pin validation is always done on top of > normal TLS validation and can only invalidate an otherwise valid connection > and never the other way around. Otherwise I could trivially hijack > connections by pinning sites to a fake FooCA.
i didn't mean to imply that a new client that had never seen the server before would see these pins and accept them. My suggestion was about a client who had previously had a good connection to the server (using its trusted root store), and had collected these pins, but didn't have a copy of BarCA's certificate in its root store. Regardless of whether the client is willing to rely on BarCA for other sites, there is a plausible argument to be made that for future connections to the pinned site, regardless of how its root store is updated, a client might want to accept connections that are anchored in BarCA. If the UA doesn't know BarCA's certificate, the UA at least knows how to recognize it by public key when the UA sees it in the future (thanks to the hash from the pinning header). >> For HPKP, that might be possible, because >> https://tools.ietf.org/html/draft-<https://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.6> > >> ietf-websec-key-pinning-11#section-2.6<https://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.6> >> suggests that any TLS errors will cause a connection termination anyway, >> before pins are checked. But, it's conceivable that an HPKP >> implementation could modify a TLS stack to allow a novel root cert base >> on its SPKI matching a known pin for a given site. I don't see that >> implementation choice explicitly forbidden in the spec. >> > > In that section, > > "When a UA connects to a Pinned Host, if the TLS connection has errors, the > UA MUST terminate the connection without allowing the user to proceed > anyway." > > "If the connection has no errors, then the UA will determine whether to > apply a new, additional correctness check: Pin Validation." (note the word > *additional*) > > as well as > > "The UA MUST note the Pins if and only if it received the Public-Key-Pins > response header field over an error-free TLS connection." right, but none of these include an explicit disavowal of the approach i mentioned. If we want to declare that approach off-limits, then we'd expect to see a statement something like: If a UA sees a pin for a root CA it does not already rely on in the course of processing a valid pin, the UA MUST NOT use that pin in any other way (including to validate as-yet-unseen certificates). This isn't worded quite right, partly because i'm not sure i believe such a restriction is a good idea (let alone enforceable), but this sentiment doesn't seem to be clearly stated in the HPKP draft. At the moment, most UAs are clumsy and coarse in how they deal with their root stores. a root CA is either valid for everywhere or not valid at all. For individual peers who don't validate in the normal chain, there's either a static "security exception" for a particular certificate (which acts as an extra "allow" option, but doesn't rule out other certificates if they also validate). But we're starting to see more sophistication: there is wider support for nameConstraints in the CAs than ever before ("this CA should only be relied on to certify names in this specific subtree of the DNS"). And a pin for a given site can be seen as a sort of inverted name-constraint on all unpinned CAs. Seeing a (valid, correctly gathered) pin as a marker for an additional tightly-name-constrained CA isn't far removed from this. > As I said, I have low faith in admin intervention.. According to SSL pulse, > 6% of Alexa top 200K sites serve an incomplete chain. You'd think they'd > notice. I share your skepticism, but to be fair, most of the tools folks are faced with right now don't give them *any* pointers about what needs to be done, or even whether they've done the right thing or not. For most sysadmins (who have lots of different tasks to take care of that don't relate to the arcana of X.509 validation) the prospect of sorting this out is "spend a couple hours on search engines reading random blog posts that disagree with each other to figure out what you might need to do, and when you're done you won't even be sure that you're done." Given this disappointing and frustrating scenario, i am not surprised that many people don't even bother trying. You're talking about improving the toolchains they have so that they get more concrete feedback about what they're doing and explicit suggestions about what needs to be done to fix the problems. i think that's great. --dkg
signature.asc
Description: OpenPGP digital signature
