4 ms·

Not again. We had this same bad argument just last week[1]. Custom-engineering backdoored client software, and rolling it out to a subset of users in a targete

by p-e-w 3y ago

Not again. We had this same bad argument just last week[1]. Custom-engineering backdoored client software, and rolling it out to a subset of users in a targeted attack, is not comparable to storing everything in plaintext on the server and looking through it whenever the fancy strikes. Practicality matters a great deal in information security. Yes, it is perfectly possible to do the former – just like it is possible to enter any home and simply bug all hardware inside. That doesn't mean this scenario should be part of a normal person's threat model. The article is correct in the sense that technically, web-based cryptography requires a degree of trust in the server provider. But the article is utterly wrong in concluding that this makes it snake oil, because attacks are substantially more difficult and costly. [1] https://news.ycombinator.com/item?id=36386884 https://news.ycombinator.com/item?id=36386884

phh 3y ago
I agree it isn't snake oil, but from my PoV it's barely moving the scale back from the "use an E2E IM to protect against tour state", while either recommending closed source apps or close source origins (downloading an open source app from Google Play Store or App Store who owns the encryption keys is pretty much the same security as close source app)
samwillis 3y ago
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
- 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.
fragmede 3y ago
A jilted jealous former lover dropping a hardware bug in someone's home doesn't really seem that far fetched, but maybe I've been watching too many TV shows. Something off Amazon for < $100 can record audio for hundreds of hours to a microSD card, and it's only active when there's noise.
anonym29 3y ago
This line of thinking is analogous to handing competent threat actors a skeleton key to your system with only one condition - the attack must not be trivial - and then you'll grant them full access. These kinds of attacks can be made trivial with the engineering capability, capacity, and systems employed by large tech firms like Google, Apple, Facebook, et al. even in the context of these firms as third party platform providers, to say nothing of their own first-party software. These systems can already classify your political views with a high degree of accuracy, and platforms like the iTunes / Apple App Store and Google Play are already designed with the capability to serve different versions of applications to different requestors (think beta programs), in addition to being the signing entity, for package formats that are entirely within their capability to supplement with additional code. To be clear - it's entirely plausible that one day, the rogue, evil, mean government voted into power by the evil bad party of your choice could compel Apple, or Google, to backdoor all applications going to clients with the same known political views as yours. You believe this to be too complex or unrealistic to be plausible (Occam's Razor, right?) but in doing so (and lowering your guard to such threat), YOU are the one that makes this go from impossible to possible. Also, using normative adjectives like "'normal people' shouldn't worry about this in this in their threat model" implies that those who do have competent threat actors after them aren't "normal", but we know that to be untrue - competent threat actors are, to some degree or another, after everyone. There is no need to "otherize" people for simply being aware of this. Instead of proscribing behavior, consider that maybe individuals are better equipped to understand their own threat models than you are, and explain the pros and cons of various courses of actions, rather than implying everyone who isn't a sheep isn't normal, and everyone who is a sheep doesn't have real threat actors interested in them.
_8j50 3y ago
I have to disagree with you, the ability for threat actors and LE to selectively backdoor code on server is important in any TM. Practicality is dynamic, TAs use the easiest method within the parameters of their objectives. It is reasonable to assume this attack would be the easiest given lack of other options. By your logic,56 bit DES is fine because most people won't see attackers that spend >$20k to crack their keys. Just like they won't see robbers who spend that much to break into their homes. Infosec is different than IRL because TAs can attack arbitrary targets easily with little personal risk. Also, hard attacks today can become common attacks a year from now and security for even the 99th percentile of users who get targeted attacks is important.

by p-e-w 3y ago

phh 3y ago

I agree it isn't snake oil, but from my PoV it's barely moving the scale back from the "use an E2E IM to protect against tour state", while either recommending closed source apps or close source origins (downloading an open source app from Google Play Store or App Store who owns the encryption keys is pretty much the same security as close source app)

samwillis 3y ago

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
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.

fragmede 3y ago

A jilted jealous former lover dropping a hardware bug in someone's home doesn't really seem that far fetched, but maybe I've been watching too many TV shows. Something off Amazon for < $100 can record audio for hundreds of hours to a microSD card, and it's only active when there's noise.

anonym29 3y ago

This line of thinking is analogous to handing competent threat actors a skeleton key to your system with only one condition - the attack must not be trivial - and then you'll grant them full access. These kinds of attacks can be made trivial with the engineering capability, capacity, and systems employed by large tech firms like Google, Apple, Facebook, et al. even in the context of these firms as third party platform providers, to say nothing of their own first-party software. These systems can already classify your political views with a high degree of accuracy, and platforms like the iTunes / Apple App Store and Google Play are already designed with the capability to serve different versions of applications to different requestors (think beta programs), in addition to being the signing entity, for package formats that are entirely within their capability to supplement with additional code. To be clear - it's entirely plausible that one day, the rogue, evil, mean government voted into power by the evil bad party of your choice could compel Apple, or Google, to backdoor all applications going to clients with the same known political views as yours. You believe this to be too complex or unrealistic to be plausible (Occam's Razor, right?) but in doing so (and lowering your guard to such threat), YOU are the one that makes this go from impossible to possible. Also, using normative adjectives like "'normal people' shouldn't worry about this in this in their threat model" implies that those who do have competent threat actors after them aren't "normal", but we know that to be untrue - competent threat actors are, to some degree or another, after everyone. There is no need to "otherize" people for simply being aware of this. Instead of proscribing behavior, consider that maybe individuals are better equipped to understand their own threat models than you are, and explain the pros and cons of various courses of actions, rather than implying everyone who isn't a sheep isn't normal, and everyone who is a sheep doesn't have real threat actors interested in them.

_8j50 3y ago

I have to disagree with you, the ability for threat actors and LE to selectively backdoor code on server is important in any TM. Practicality is dynamic, TAs use the easiest method within the parameters of their objectives. It is reasonable to assume this attack would be the easiest given lack of other options. By your logic,56 bit DES is fine because most people won't see attackers that spend >$20k to crack their keys. Just like they won't see robbers who spend that much to break into their homes. Infosec is different than IRL because TAs can attack arbitrary targets easily with little personal risk. Also, hard attacks today can become common attacks a year from now and security for even the 99th percentile of users who get targeted attacks is important.