Hacker News Reader

Comment by the8472 | Hacker News Reader

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

View on HN

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.

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

F-Droid does builds themselves!

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.

That was entirely The Pirate Bay's fault, not CloudFlare's.

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.

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

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.

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.

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.

Depends on the app. If you are making a storage app then you can do client side encryption so that it doesn't matter if s3 is compromised, they don't have access to your data.

SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use.

It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective.

But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.

I've been thinking about this problem for Airborn OS. In my opinion, the best place to put signatures of the "main resource" would be the website's certificate. [1]

I created a Firefox extension that can check signatures both in the certificate and (in the meantime) hardcoded in the extension. [2]

[1]: http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of...

[2]: http://blog.airbornos.com/post/2016/02/23/The-first-web-appl...

Well if you trust the website at least once, it can load a service worker which will verify signatures of any app/script updates from any party before allowing them to update the locally cached version of the script.

Service workers can get wiped on hard refreshes or due to space constraints. And they are not easily transferred to new devices, unlike packaged applications. They're not a security mechanism.

And it does not necessarily address the compromise of the hoster either, since the attacker who has control over that may also have access to the signing keys. Especially in the case of a court order.

That effectively is a silent, user-targetable auto-update of software to which you entrust your secret data.

Auto-updates for crypto software should be verifiable through other channels, require user confirmation and use a distribution method that is difficult to scope to a single user to make targeted attacks harder.

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.

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 ¯\_(ツ)_/¯

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

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

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.

websites can be made immutable:

https://hacks.mozilla.org/2017/01/using-immutable-caching-to...

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.

IPFS is the way to go.

Reply on news.ycombinator.com