Hacker News Reader

Comment by kpdemetriou | Hacker News Reader

The web app case is unfortunately more hazardous:

- You're also trusting a large population of Certificate Authorities (CAs), subject to the post-compromise implications of Certificate Transparency. Only one needs to be compromised.

- An app "update" occurs on every page load, giving attackers flexibility and more frequent opportunity to intercept app payloads - perhaps as users cross into networks the attackers control.

- There are currently no sufficient mechanisms to validate the integrity of web app packages end-to-end. Not even under a trust-on-first-use (TOFU) model.

These are all practical constraints we're grappling with while working on Backbone[1], and why deploying native apps is a top priority for us. Nevertheless, we need to reach users where they are, and that means we can't completely deprecate our web app.

[1] https://backbone.dev/

View on HN

Once a CA gives out one bad certificate, they are done. If your risk profile includes someone being willing to throw away an entire CA to get to you, then you should worry about it. For 99.999% of people and companies, I don’t imagine that is a reasonable concern.

CAs give out bad certificates all the time. Whether they are done depends on the reason. Often people give fradulent information to CAs, which leads to them issuing a certificate. This is usually discovered soon after the fradulent issuance, but for some victims it might still be too late. If the CA proves that it followed due diligence, and this happens rarely enough, they won't be distrusted by browsers.

> - You're also trusting a large population of Certificate Authorities (CAs), subject to the post-compromise implications of Certificate Transparency. Only one needs to be compromised.

I fail to see the difference between Web and Native in that regards, in both case the attacker need to both:

- a compromised certificate

- a way to redirect the user to their own server (be it DNS or IP spoofing, or something more fancy like bitsquatting).

With only one of those, both the Web and Native app are safe, and with the two of them, you're screwed in both cases.

> - There are currently no sufficient mechanisms to validate the integrity of web app packages end-to-end. Not even under a trust-on-first-use (TOFU) model.

Would you mind expanding your requirements here? (Especially, what's the threat model you have in mind for which subresource integrity isn't enough but your ideal solution would be).

I suspect they want a browser feature to show fingerprints of the HTML and of subresources possibly to pin a certificate for a given domain.

A browser setting to only load subresources with integrity checks would also help

> I suspect they want a browser feature to show fingerprints of the HTML and of subresources possibly to pin a certificate for a given domain.

You can do pretty much all you want in a ServiceWorker today[1], but I'll advise against pinning certificates, because you'd just be re-marking HPKP again, with the same gigantic footgun.

> A browser setting to only load subresources with integrity checks would also help

A “browser setting”? What's the point if the user need to set it up themselves to be secure? Some kind of linting tool on CI in order to be sure you never include a resource without SRI would be nice though, but it's not really the responsibility of the browser here.

[1]: you can see an example of that here: https://arxiv.org/pdf/2105.05551.pdf (Note that I've just DuckduckGo-ed a quick example, I haven't read this particular paper and can't say if their scheme is particularly good, but that'd give you an idea).

Reply on news.ycombinator.com