Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public Key Pinning Being Removed from Chrome

groups.google.com

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Public Key Pinning Being Removed from Chrome

#21

Post by posixplz »

mschuster91 wrote: post #17
yebyen wrote: post #13

Earlier quoted context omitted.

What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) If someone ransomed you, would you need to pay them for the key, and then use the key on your site from then on? So, you could pay the ransom and they'd be able to decrypt all of your traffic from then on? (I'm sure I just don't know how HPKP works, like there's some…

> What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MI…

Sounds a lot like DANE/TLSA.

Re: Public Key Pinning Being Removed from Chrome

#22

Post by posixplz »

PhantomGremlin wrote: post #20
saas_co_de wrote: post #15

why not provide an advanced feature that alerts you any time a cert changes, similar to what we get with SSH? at least then security conscious users could make decisions for themselves.

why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.st…

I imagine things have only gotten "worse" with Let'sEncrypt issuing 90 certificates.

Re: Public Key Pinning Being Removed from Chrome

#23

Post by mschuster91 »

posixplz wrote: post #21
mschuster91 wrote: post #17

Earlier quoted context omitted.

> What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MI…

Sounds a lot like DANE/TLSA.

Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(

Re: Public Key Pinning Being Removed from Chrome

#24

Post by rocqua »

mschuster91 wrote: post #17
yebyen wrote: post #13

Earlier quoted context omitted.

What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) If someone ransomed you, would you need to pay them for the key, and then use the key on your site from then on? So, you could pay the ransom and they'd be able to decrypt all of your traffic from then on? (I'm sure I just don't know how HPKP works, like there's some…

> What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MI…

As the other commenter said, this sounds a lot like DANE.

As such, it suffers from the same issue: it relies on DNSSEC. If you look at the trust chain for DNSSEC on the .com domain, you are trusting the US government and your registrar. The US government is the bigger issue here, as the NSA is also a part of them.

You might argue that this is 'good enough' but considering the momentum that these kind of systems have, a wrong decision here could really enable NSA spying for a long time. Besides, CT logs seem like a much better solution than key-pinning anyway.

Re: Public Key Pinning Being Removed from Chrome

#25

Post by rocqua »

mschuster91 wrote: post #23
posixplz wrote: post #21

Earlier quoted context omitted.

Sounds a lot like DANE/TLSA.

Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(

The basic reason is that people really don't like DNSSEC. tptaeck (https://news.ycombinator.com/user?id=tptacek) has plenty of comments really supporting that argument.

Re: Public Key Pinning Being Removed from Chrome

#26

Post by wnevets »

PhantomGremlin wrote: post #20
saas_co_de wrote: post #15

why not provide an advanced feature that alerts you any time a cert changes, similar to what we get with SSH? at least then security conscious users could make decisions for themselves.

why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.st…

>Years ago I tried using a Firefox addon called Certificate Patrol.

yeah I too gave up on using that addon for the same reason

Re: Public Key Pinning Being Removed from Chrome

#27

Post by detaro »

mschuster91 wrote: post #23
posixplz wrote: post #21

Earlier quoted context omitted.

Sounds a lot like DANE/TLSA.

Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(

DANE is used a bit for SMTP (where it also forms a clear "only talk to our mail servers over TLS" signal, which as far as I know didn't exist before)

As a replacement for HPKP it doesn't solve the big attack scenario of someone taking over your DNS and obtaining a certificate to impersonate your site: if they can do that, they can also put false certificate details in DNS.

It's also tied to DNSSEC, which isn't universally deployed for domains, would if I understand correctly putting a full DNSSEC-resolver in the browsers to protect against local MITM (which isn't practical in many situations) and often criticized.

Re: Public Key Pinning Being Removed from Chrome

#29

Post by phyzome »

buu700 wrote: post #19

I can't support this at all, and ironically this is partially my fault. My and @eganist's Black Hat / DEF CON talk "Abusing Bleeding Edge Web Standards for AppSec Glory" demoed an exploit concept that we called "RansomPKP", which was essentially a pattern of hostile pinning that could theoretically enable pivoting from a web server compromise to holding a site for ransom. Hostile pinning was by no means a new concept…

I'm curious about that followup message (is that you?) about how Cyph (seems to be some sort of encrypted messaging thing) relies on "HPKP Suicide" for... in-browser code-signing? I didn't find any resources laying out exactly how this works.

Re: Public Key Pinning Being Removed from Chrome

#30

Post by Confiks »

posixplz wrote: post #22
PhantomGremlin wrote: post #20

Earlier quoted context omitted.

why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.st…

I imagine things have only gotten "worse" with Let'sEncrypt issuing 90 certificates.

You pin a public key (of which the private key signs the leaf certificate, the sub-CA or the CA) with HPKP, not the certificate. With the default settings, LetsEncrypt re-uses the keypair for a new certificate.
Post reply on HN