4 ms·

The problem with in-the-browser encryption is that it is fundamentally insecure until websites can be made immutable. You're executing remote, mutable code to h

by the8472 10y ago

The problem with in-the-browser encryption is that it is fundamentally insecure until websites can be made immutable. You're executing remote, mutable code to handle your secret data. Which means at any point the website operator could replace it with something that exfiltrates the data the moment you access it. Even if the operator is not malicious they could receive a court order or the connection loading the code could be MITMed even if you think you're secure[0]. [0] https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know-it-90935f7f6d98#.jktc9i7r6 https://medium.com/@karthikb351/airtel-is-sniffing-and-censo...

josephg 10y ago
Its a bit harder to exploit, but this is also a problem with mobile apps. The developer could be compelled to release an update which leaks data to a 3rd party for specific users. Even for opensource projects there's no guarantee that the published version of the app matches anything in the commit history. And I doubt anybody looks inside the binaries that get published to the app stores when there's source code available. So right now on web or mobile you simply have to trust the app developers. Apple & Google could easily fix this by copying the docker registry. Just run a build process themselves directly from a specified git SHA. Publish that & name the repo & git SHA they used for the build. That way security researchers could go read the sourcecode and know that its the actual code running on everyone's phones. Mind you, doing this would make it easier for the US government to compel apple or google to modify a binary for just one user. But apple and google can already do that if they want to. Another approach would be to make the whole toolchain build reproducible binaries, so a researcher can run the build process themselves and verify the binary hashes match. But lets not pretend that somehow apps are more secure because you download a sandboxed app from an app store instead of sandboxed JS + HTML. The tech stacks used to deploy code are more similar than they are different.
- pwg 10y ago
  > Even for opensource projects there's no guarantee that the published version of the app matches anything in the commit history. But at least for opensource, if you are willing you can build your own binary, using your own tools, from the source in the commit history, and get an app that matches the commit history [1]. [1] Exclusive of the issues detailed in "Reflections on Trusting Trust" by Ken Thompson regarding the actual build tools themselves (https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...)
- floatboth 10y ago
  F-Droid does builds themselves!
dredmorbius 10y ago
What happens if, say, you Torify the code element? Such that it's not possible to identify a specific user by name? Or have some, say, third-party hash proof of the download? (Essentially signed downloads.) Or if the system is blind to the identity of the user requesting information? Reads need not be authenticated, only writes, which would have to match some signature, say. (I'm aware of numerous browser problems, I'm looking at ways around them.)
kybernetikos 10y ago
Subresource integrity [1] helps make sure that the javascript referred to by the page is really what gets served. The common usecase talked about is to ensure that a compromised CDN can't attack big chunks of the internet. The page itself can still be modified, but there are mitigations that can be performed if you're paranoid enough. 1. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- the8472 10y ago
  The threat model I stated included the future compromise of the second party (the hoster). SRI only helps against untrustworthy 3rd parties (CDNs). So it does not really address the issue.
  - kybernetikos 10y ago
    Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it and run it from there. It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution. It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.
    - yeukhon 10y ago
      If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.
      - kybernetikos 10y ago
bubblethink 10y ago
The Airtel story is interesting. I've experience this in India, but it's usually just DNS level blocks. Didn't expect it to manifest as an HTTPS MITM. That's a massive fail on Cloudflare's part.
- RadioactiveMan 10y ago
  That was entirely The Pirate Bay's fault, not CloudFlare's.
  - bubblethink 10y ago
    I mean it's deceptive to the general public to even call it flexible SSL and offer it as a product. False sense of security is worse than no security.
homakov 10y ago
It's not about being immutable, but about verified and signed builds (see codehash.db)
- megous 10y ago
  Even if that is done, there has to be verification for absence of security vulnerabilities in the app itself, because if data can trigger code execution, you're done. It's much easier to manipulate its own data for the web service itself than for other parties trying to exploit XSS vulnerability. In other words, you must ensure that the frontend treats the entire backend as a hostile actor, not just the code it serves, but also the data. Not all web frontends are written like that; many serve HTML snippets that get pasted into the DOM unchecked, instead of passing JSON data and rendering on the client side. You can sign the static frontend code all you want, and you're still owned by the service itself in this case.
bugmen0t 10y ago
websites can be made immutable: https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to...
- the8472 10y ago
  No, that just is a hint for caching. Caches naturally evict entries and eventually reload the content. For security you don't need an immutability-hint, you need it enforced.
  - rnhmjoj 10y ago
    IPFS is the way to go.
px43 10y ago
Immutability isn't a great option for obvious reasons. Trackability would be nice though. Imagine if web data served off a domain could be dug through like a git repo. If you could see every commit and diff, and if proof of malice would be indisputable. Then, even if bad people did take over the domain, it would be detected immediately, and its reputation rating would drop so low that browsers would refuse to connect to it.
- Groxx 10y ago
  Well, take cryptpad. The link could define the version of the code, and the browser could enforce that it never changes. everything else is communication with the server - something you can audit, given never-changing code. Bugfixes are of course prevented, but that just means you need to bake in a "check for updates" link - there's no reason that URL needs to change, just the contents at it, which you don't need to trust like the cryptpad's pad source. How to achieve this, no idea. Or, several ideas, but nothing general enough ¯\_(ツ)_/¯

by the8472 10y ago

josephg 10y ago

Its a bit harder to exploit, but this is also a problem with mobile apps. The developer could be compelled to release an update which leaks data to a 3rd party for specific users. Even for opensource projects there's no guarantee that the published version of the app matches anything in the commit history. And I doubt anybody looks inside the binaries that get published to the app stores when there's source code available. So right now on web or mobile you simply have to trust the app developers. Apple & Google could easily fix this by copying the docker registry. Just run a build process themselves directly from a specified git SHA. Publish that & name the repo & git SHA they used for the build. That way security researchers could go read the sourcecode and know that its the actual code running on everyone's phones. Mind you, doing this would make it easier for the US government to compel apple or google to modify a binary for just one user. But apple and google can already do that if they want to. Another approach would be to make the whole toolchain build reproducible binaries, so a researcher can run the build process themselves and verify the binary hashes match. But lets not pretend that somehow apps are more secure because you download a sandboxed app from an app store instead of sandboxed JS + HTML. The tech stacks used to deploy code are more similar than they are different.

pwg 10y ago
> Even for opensource projects there's no guarantee that the published version of the app matches anything in the commit history. But at least for opensource, if you are willing you can build your own binary, using your own tools, from the source in the commit history, and get an app that matches the commit history [1]. [1] Exclusive of the issues detailed in "Reflections on Trusting Trust" by Ken Thompson regarding the actual build tools themselves (https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...)
floatboth 10y ago
F-Droid does builds themselves!

dredmorbius 10y ago

What happens if, say, you Torify the code element? Such that it's not possible to identify a specific user by name? Or have some, say, third-party hash proof of the download? (Essentially signed downloads.) Or if the system is blind to the identity of the user requesting information? Reads need not be authenticated, only writes, which would have to match some signature, say. (I'm aware of numerous browser problems, I'm looking at ways around them.)

kybernetikos 10y ago

Subresource integrity [1] helps make sure that the javascript referred to by the page is really what gets served. The common usecase talked about is to ensure that a compromised CDN can't attack big chunks of the internet. The page itself can still be modified, but there are mitigations that can be performed if you're paranoid enough. 1. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

the8472 10y ago
The threat model I stated included the future compromise of the second party (the hoster). SRI only helps against untrustworthy 3rd parties (CDNs). So it does not really address the issue.
- kybernetikos 10y ago
  Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it and run it from there. It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution. It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.
  - yeukhon 10y ago
    If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.
    - kybernetikos 10y ago

bubblethink 10y ago

The Airtel story is interesting. I've experience this in India, but it's usually just DNS level blocks. Didn't expect it to manifest as an HTTPS MITM. That's a massive fail on Cloudflare's part.

RadioactiveMan 10y ago
That was entirely The Pirate Bay's fault, not CloudFlare's.
- bubblethink 10y ago
  I mean it's deceptive to the general public to even call it flexible SSL and offer it as a product. False sense of security is worse than no security.

homakov 10y ago

It's not about being immutable, but about verified and signed builds (see codehash.db)

megous 10y ago
Even if that is done, there has to be verification for absence of security vulnerabilities in the app itself, because if data can trigger code execution, you're done. It's much easier to manipulate its own data for the web service itself than for other parties trying to exploit XSS vulnerability. In other words, you must ensure that the frontend treats the entire backend as a hostile actor, not just the code it serves, but also the data. Not all web frontends are written like that; many serve HTML snippets that get pasted into the DOM unchecked, instead of passing JSON data and rendering on the client side. You can sign the static frontend code all you want, and you're still owned by the service itself in this case.

bugmen0t 10y ago

websites can be made immutable: https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to...

the8472 10y ago
No, that just is a hint for caching. Caches naturally evict entries and eventually reload the content. For security you don't need an immutability-hint, you need it enforced.
- rnhmjoj 10y ago
  IPFS is the way to go.

px43 10y ago

Immutability isn't a great option for obvious reasons. Trackability would be nice though. Imagine if web data served off a domain could be dug through like a git repo. If you could see every commit and diff, and if proof of malice would be indisputable. Then, even if bad people did take over the domain, it would be detected immediately, and its reputation rating would drop so low that browsers would refuse to connect to it.

Groxx 10y ago
Well, take cryptpad. The link could define the version of the code, and the browser could enforce that it never changes. everything else is communication with the server - something you can audit, given never-changing code. Bugfixes are of course prevented, but that just means you need to bake in a "check for updates" link - there's no reason that URL needs to change, just the contents at it, which you don't need to trust like the cryptpad's pad source. How to achieve this, no idea. Or, several ideas, but nothing general enough ¯\_(ツ)_/¯