4 ms·

Exactly, with all cryptographic software you are trusting the distribution and update provider, along with your OS. There is always a level of trust. With an a

Exactly, with all cryptographic software you are trusting the distribution and update provider, along with your OS. There is always a level of trust. With an app from an App Store you are trusting at a minimum: - the vendor - the App Store - the update system for your OS For a web app (via SSL) you are trusting: - the vendor - the browser and it's update system - the OS and its update system There is barely a difference in a world of auto updating software.

SheinhardtWigCo 3y ago
I somewhat share this fatalist view, but it's still worth iterating on all of this until it's possible for the trusted party to be the user's chosen auditor instead of the vendor. Unfortunately, the vendors have little reason to facilitate that.
goodpoint 3y ago
If you use a security-oriented Linux distribution there will be a ton of difference.
kpdemetriou 3y ago
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/ https://backbone.dev/
- littlestymaar 3y ago
  > - 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).
  - afiori 3y ago
    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
    - littlestymaar 3y ago
      > 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 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).
- CJefferson 3y ago
  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.
  - est31 3y ago
    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.
est31 3y ago
The difference is, with the App Store there is policies against malware. Furthermore, it's harder to hide such an attack as you can't press a button to deploy a special version of the client just to Joe Doe whose private pictures you are interested in. You either have to deploy it to a large group, or not at all. With js, you have full control over the HTTP server and can give that specific person a specific version of the client. Yes, the updates are automated on mobile devices, but not under total and full control of the app developer, unlike for websites. And people do monitor what e.g. the Signal app is doing, or WhatsApp. I don't agree though that all web-based cryptography is snake oil though. Targeted attacks from the site operator are not the only thing you want to defend from. Say the site operator is asked by authorities to hand over data they store of a specific user. Then the insecure web based cryptography is enough to protect the data: everything that's stored is encrypted.

SheinhardtWigCo 3y ago

I somewhat share this fatalist view, but it's still worth iterating on all of this until it's possible for the trusted party to be the user's chosen auditor instead of the vendor. Unfortunately, the vendors have little reason to facilitate that.

goodpoint 3y ago

If you use a security-oriented Linux distribution there will be a ton of difference.

kpdemetriou 3y ago

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/ https://backbone.dev/

littlestymaar 3y ago
> - 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).
- afiori 3y ago
  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
  - littlestymaar 3y ago
    > 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 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).
CJefferson 3y ago
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.
- est31 3y ago
  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.

est31 3y ago

The difference is, with the App Store there is policies against malware. Furthermore, it's harder to hide such an attack as you can't press a button to deploy a special version of the client just to Joe Doe whose private pictures you are interested in. You either have to deploy it to a large group, or not at all. With js, you have full control over the HTTP server and can give that specific person a specific version of the client. Yes, the updates are automated on mobile devices, but not under total and full control of the app developer, unlike for websites. And people do monitor what e.g. the Signal app is doing, or WhatsApp. I don't agree though that all web-based cryptography is snake oil though. Targeted attacks from the site operator are not the only thing you want to defend from. Say the site operator is asked by authorities to hand over data they store of a specific user. Then the insecure web based cryptography is enough to protect the data: everything that's stored is encrypted.