back to article RIP HPKP: Google abandons public key pinning

Google is abandoning a next-generation web crypto technology it initially championed. HTTP Public Key Pinning (HPKP) is a standard that allows a host to instruct browsers to only accept certain public keys when communicating with it for a given period of time. While HPKP can offer a lot of protection, the technology was open …

  1. gerdesj

    Expect-CT

    Wondering what Expect-CT is? This bloke knows what he is on about:

    https://scotthelme.co.uk/a-new-security-header-expect-ct/

  2. streaky Silver badge

    Problem with PKP

    Basically if you had a problem with your cert and needed to drop it you were up shit creek with a conventional cert deployment, PKP makes sense only if it's long-lived so you had to maintain two (or more) separate certs for every domain and ensure those digests are both being sent to clients, it's not a cost issue it's a complexity/maintenance issue. Without a backup cert if you year-long your PKP header and your cert is compromised or similar in the first few months any client that connected in that first months won't be able to connect to your server. Your backup cert can't be near production servers either because if your main cert is compromised your backup one probably would be too so how do you digest it to clients? It's a nightmare to maintain that sort of set up.

    Behaviour of browsers with regards to what happens on revoke with PKP isn't well defined and behaviour of CA's themselves with regards to cert revocation itself isn't well defined - and that's ignoring misconfiguration giving people completely unusable domains for year-plus periods - and all this has obviously led to poor uptake of the technology.

    That being said the principle of the domain owner/admin being able to specify precisely which certificates are allowed to serve the domain is a very powerful tool when clients respect it. It's just not clear if there's another way to offer the same level of protection (cert transparency doesn't, although it potentially has a wider appeal and may or may not be "enough" protection). This is one of the reasons we need to do a better job of securing zones - which DNSSEC equally isn't up to the task of. Once we have a secure DNS system we can tag keys to domains in a more reliable and secure way and tools like PKP and cert transparency will be completely unnecessary.

  3. Gene Cash Silver badge

    Shock and astonishment

    "a half-baked standard got deployed to production"

    From GOOGLE? No way! That NEVER happens!

  4. Anonymous Coward
    Anonymous Coward

    Still waiting for DANE

    Ah yes - yet another failed pinning solution. Just indicate the expected SHA in DNS. Not perfect, but a real step up in security. Google just wants to own everything...

    1. Orv Silver badge

      Re: Still waiting for DANE

      I could see that working, but you'd need secure DNS first. Anyone who can intercept HTTPS traffic is probably in a position to spoof DNS.

      1. streaky Silver badge

        Re: Still waiting for DANE

        It's worse than that, one of the strongest perceived threats to crypto security is state actors (well, it's not perceived, it's a fact) - and state actors in most cases will have far more ability to screw with DNS than anything else.

        There's a moral hazard here though - securing PKI this way calls PKI's existence into question. If a domain owner can specify keys for sites it operates and DNS is cryptographically secured in terms of data content (records signed by domain controller, as opposed to the DNS provider) then PKI providers will probably face questions about the necessity of them continuing to exist. Security of DNS record would be the prime concern of domain registrars and DNS providers but when DNS is secured properly and you can specify any key and it's equally secure as PKI infrastructure would otherwise be (and arguably more so) then they're going to have an issue. That's why expect never to actually see a secure DNS system; because it's not in the cert authorities best interest to secure it.

  5. John Smith 19 Gold badge
    Gimp

    Odd thing for Google to supply. It doesn't help them slurp more of your data faster.

    What's it for?

    As for certificate management (both live and offline backup in case of compromise)

    Is there not (by now) an app for that?

    Or at least a plug in for some management framework to do this?

    If not, why not?

  6. DougS Silver badge

    Now Google is not only killing products they developed

    They'll killing protocols they developed. Why should anyone be an early adopter of anything Google with their track record?

  7. aberglas

    How will secruity software proxy TLS?

    Many corporate tools work by issuing all their clients with an internal trusted root cert. This then enables them to proxy TLS and do deep inspection of the packets by simply providing their own site based certificates.

    Will CT prevent this trick from working? Is that the point? Or does it just mean that the Loggers also need to be proxied?

    (The real solution is not to rely on PKI at all, but to use Secure Remote Password. Also kills phishing dead. Passwords should never be sent to servers, just a proof of possession.)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019