![](\"https:\/\/i.giphy.com\/media\/wjreQXpQaD6tW\/giphy.webp\")
Keeping with our Halloween theme, today we have Pinhead.\u00a0 Because it’s horror stuff but also because the article is about key pinning (because “pin”, get it?)\u00a0 I kill me.<\/p>\nKeeping with our Halloween theme, today we have Pinhead.\u00a0 Because it’s horror stuff but also because the article is about key pinning (because “pin”, get it?)\u00a0 I kill me.<\/p>\n
Anyway, today we have an interesting turn of events. Google is planning to pull key pinning (HPKP) from Chrome<\/a>.\u00a0 There’s a whole thread about the motivation, timeline, and plan here<\/a>.<\/p>\n If you’re not familiar with key pinning, it’s basically a mechanism to allow a server, via HTTP response headers, to send a message to a “user agent” (i.e. your browser) about what public key to expect that server to use.\u00a0 In other words, to say something akin to “hey… when you talk to me, you should get this certificate or one of these public keys.”<\/p>\n Why do this?\u00a0 It’s a (kludgy I’d argue) workaround for CA compromise.\u00a0 Say, for example, bad guys trick some CA into issuing a certificate for *.google.com.\u00a0 Those bad guys what to use that certificate to do all kinds of shenanigans – set up a proxy for MITM for example.\u00a0 Sounds nefarious, right?\u00a0 But if the server has already told the client “hey, if you talk to me later and you don’t get this particular cert – or a cert that contains a public key matching XYZ – then you’re probably being scammed.”\u00a0 This lets the browser warn people about it if they get something they don’t expect.<\/p>\n If you really want to understand how it works at a high level of depth,\u00a0the\u00a0RFC (RFC 7469)<\/a>\u00a0 is the best way to get there, but another useful resource is the page up at OWASP about it<\/a>.\u00a0 It’s really not complicated though: response headers that specific certificate or key information to be used by the browser to “pin” what they should expect to receive from that site.<\/p>\n The primary reason why Google pulling back on it is super interesting though is because it was Google that started all this pinning stuff in the first place.\u00a0 For example, check out that RFC that I linked to before – do you notice who wrote it?\u00a0 \u00a0Yeah.\u00a0 Google.\u00a0 And recently too.\u00a0 So that’s interesting.\u00a0 They cite three factors for this decision; paraphrased, they are: it’s hard to do (exacerbated by the fact that not many people are supporting it), it’s risky, and someone could attack it.\u00a0 Is it a good idea?\u00a0 Yes… yes it is.\u00a0 Are they right to deprecate it?\u00a0 Yes, I think they are.<\/p>\n If those two statements sound incompatible to you, I come back to the statement that I made earlier about it being a kludge.\u00a0 I say it’s a kludge (for you youngsters, “kludge”=inelegant workaround) because it’s outside where this should (in my opinion) really happen, which is the TLS protocol itself… better yet, in\u00a0TLS implementations<\/strong> based on instructions built into public PKI certs.<\/p>\n Here’s why I say that.\u00a0 HPKP is out of band to TLS — in the response headers, right?\u00a0 But wouldn’t it be nice if other, non-HTTP connections could have this same safety feature?\u00a0 Sure.\u00a0 Can they?\u00a0 No… not with this mechanism anyway.\u00a0 \u00a0From a conceptual point of view, the problem we’re trying to solve isn’t really a problem with HTTP… HTTP is fine the way it is.\u00a0 It’s also not really a TLS issue.\u00a0 The mechanics of security issues in the certificates it uses are, I’d argue, outside of the scope of the TLS standard.\u00a0 Instead, it’s a PKI problem.\u00a0 So addressing it at the PKI level seems to make the most sense.<\/p>\n If it were up to me to design a fix, I\u00a0would use either extended key usage (in the certificate) or the certificate policy extension to implement HPKP.\u00a0 Why?\u00a0 Because that’s what these fields are for – i.e. information about certificate policy (many times this is just a link, but it doesn’t have to be) or about how they key should be used.\u00a0 \u00a0That’s step one.\u00a0 Step two would be to get relying parties (such as TLS implementations) to “want” to pin the cert if they get one that has this field set to something informative.\u00a0 In other words, they do it because the cert specifies they should and gives them instructions on how.\u00a0 The implementation can be agnostic about why, for what purpose, whether used in HTTPS or something else, etc.\u00a0 In fact, you could do everything you’re doing now in HPKP… just more cleanly and in a way that lets you use it for other use cases too.<\/p>\n