Hacker News Reader

Comment by lexman0 | Hacker News Reader

I completely disagree with this. Public key pinning has some well known problems that make it very dangerous to implement at scale [1].

There are some very large problems that this introduces and does not solve:

- How do kiosk machines now work? How can I trust any website when every use is first use?

- What about https domains for images and scripts? Is the user supposed to trust each domain separately?

- Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse?

- Is the author suggesting that we retain all users of browsers everywhere? I believe that to be a herculean task.

Certificates have their problems, but this is not a solution. I will not propose one here, because it is an extremely complicated problem that needs many separate parties working together to solve.

[1] https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...

View on HN

> How do kiosk machines now work? How can I trust any website when every use is first use?

Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.

> What about https domains for images and scripts? Is the user supposed to trust each domain separately?

Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better.

> Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse?

AFAIK, revocation isn't very good even with the current CA infrastructure[1][2].

[1] https://news.netcraft.com/archives/2014/04/24/certificate-re...

[2] https://www.maikel.pro/blog/current-state-certificate-revoca...

> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.

I should have the choice. This doesn't even give me that.

> Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better.

This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated?

> AFAIK, revocation isn't very good even with the current CA infrastructure[1][2].

I completely agree with you, so lets not make it any worse.

> I should have the choice. This doesn't even give me that.

I don't understand why you say this. Can you explain more?

> This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated?

Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.

>> I should have the choice. This doesn't even give me that.

>I don't understand why you say this. Can you explain more?

Not who you replied to, but with this system, I need to trust everything between the kiosk and the website server to not be MitMed. With the certificate system, I only need to trust the kiosk itself. Specifically, I need to trust the browser does TLS right, and I need to trust the installed root certificates are correct.

This is my thinking.

>> Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.

Then that means each external domain has to tell all its linkers that its key will change whenever it does. Assuming it even has such a list. What if a party doesn't respond? I understand it would be said parties problem, but it sure does make re-keying difficult.

> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.

This has already been answered, but I'll offer a different perspective. For a lot of people kiosk machines are the only way they get to use the internet. Not everyone has the privilege of owning their own computer or internet-enabled phone.

> I completely disagree with this. Public key pinning has some well known problems that make it very dangerous to implement at scale

I don't know what you are commenting on, because the author of the linked article suggests we use Trust On First Use, not HPKP.

which is aweful from a user perspective, not everybody is an engineer. many many people would be more confused by that.

Reply on news.ycombinator.com