Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

End-to-end encryption in the browser

blog.excalidraw.com

Post reply on HN
Print view View original

51–60 of 112 posts

Re: End-to-end encryption in the browser

#51

Post by thanksforfish »

_bxg1 wrote: post #36
m1el wrote: post #17

I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.

How does that differ from a native app? In any E2E context you have to trust the client code. Sure, there are a couple extra steps needed here: - The website author needs to avoid casually throwing in dependencies (unlike perhaps the average JS project) - HTTPS for loading code resources is crucial; maybe even CDNs need to be avoided - The user needs to avoid having browser extensions enabled But the fundamental prob…

I agree, not intractable but there are meaningful differences:

* A native app can be installed once. A browser app is effectively downloaded fresh each time you use it. That give more exposure to attack. * A native app is downloaded, then run. A browser app does both in one step. Separation gives the user a chance to verify using hashes, signatures, etc, ideally cross checked from multiple different domains incase only the download server/primary domain is hacked. If there are sensitive user cookies, malicious javascript can steal them immediately on page load.

Native apps that update themselves can be a mess, but OS or package manager updates are generally carefully managed (I.E. apt).

For the CDN concern, sub resource integrity should work well (of course you need to verify that the version you hash is actually safe, which people sometimes skip). I think browser support is good these days.

But I agree, not intractable.

Re: End-to-end encryption in the browser

#52

Post by dogma1138 »

marcus_holmes wrote: post #31
denisu wrote: post #11

Earlier quoted context omitted.

Urls are encrypted.

well, not the whole url, obviously, otherwise the router wouldn't know where to send the request

The entire URL is encrypted, the router doesn't need to know anything about the URL to route the packets. The only thing that can leak when you make an HTTPS connection is the DNS query.

Re: End-to-end encryption in the browser

#53

Post by sneak »

minitech wrote: post #43
sneak wrote: post #35

From one of HN's own stars: Javascript Cryptography Considered Harmful: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... There are some out of date bits, but the core of the post is still as true as it was back in 2011.

Very little of that article is applicable. The website is served over HTTPS, the browser has a crypto API now. The encryption in this project decreases the impact of any future compromise of the server (if a share link is never visited post-compromise, it’s safe) and makes it necessary for an attacker to show their hand by serving malicious code to the client. (With browsers as they are now, that can be made hard to…

All the other js resources on the page can still backdoor the app, though, and exfiltrate your keys. SRI and no longer executing javascript served with the right content-type in an img src is helpful along these lines, but even with SRI on every script tag, the sub-scripts pulled in from the integrity-checked third party js can pull in arbitrary further resources which can then overwrite your functions to steal your keys.

Even a strict CSP doesn't totally close the hole.

It's sort of crazy how difficult (that's a euphemism—I would term it "impossible") it is to even attempt to secure browser-based crypto, over and above the normal challenges involved in crypto implementation. I wouldn't use clientside js crypto for anything more secret than a grocery list.

Re: End-to-end encryption in the browser

#54

Post by seemslegit »

SamBam wrote: post #48
seemslegit wrote: post #16

As with every in-browser encryption deployment - what's the threat model here ? > I now sleep much better at night. If the hosting service gets compromised, it doesn’t really matter as none of the content can be decrypted without the key. Which can be easily exfiltrated by the compromiser as they are now in a position to deliver and run arbitrary javascript in your users browser where the keys reside Also, why can't…

> As with every in-browser encryption deployment - what's the threat model here ? I believe the biggest win is that existing content will not be accessible to a hacker even if they fully compromise the website, unless users re-open them. So, sure, plenty of content may get compromised if the site gets hacked, but some large percentage of old content will not be. > Also, why can't I draw an actual non-flawed circle ?…

> I believe the biggest win is that existing content will not be accessible to a hacker even if they fully compromise the website, unless users re-open them. So, sure, plenty of content may get compromised if the site gets hacked, but some large percentage of old content will not be.

The attacker won't need to wait for the users to open a specific drawing - just browse to the website, from there they can grab the keys for all drawings they have assuming that not that many of them exist in the first place and the attacker has the list of key ids from the compromised backend.

It does call for a much more noisy and visible attack which is by itself a valuable mitigation.

Re: End-to-end encryption in the browser

#55

Post by bconnorwhite »

m1el wrote: post #17

I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.

Why encrypt passwords? E2E encryption is similar in that as it is much for the website owner as the client. Data is a liability

Re: End-to-end encryption in the browser

#56

Post by est31 »

geofft wrote: post #46
m1el wrote: post #17

I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.

It's using end-to-end encryption to address a slightly different threat model than the usual one: the website operator doesn't want the liability/danger of holding cleartext data. E2E does solve this even in the browser scenario. Now an attacker who dumps the server's disks doesn't compromise user data, they'd have to activate modify the website. This raises the bar of a successful targeted attack and aldosterone bas…

> It's true that this doesn't let you avoid trusting the provider, but you're not going to get that anyway - and this scheme is certainly no worse. (Arguably you're not going to get that on native apps either these days, thanks to closed-source app stores and automatic updates, and automatic updates are a very good thing.)

There is no guarantee, but security researchers often check the contents of apps like WhatsApp, Threema, etc. However, that doesn't help you if you specifically get a special version of the app that sends your content to the app writers. For websites, how hard this is depends on your infrastructure, but it is more or less trivial. For app stores like Google Play or apple app store, there is no such feature to push a special version to a subset of the population specified by name. You can only push it to entire classes of devices.

So suddenly Google, Apple, etc. have to be in on the attack which drastically reduces the number of people who can pull off supply chain attacks. Maybe you should be still worried about the US government, but while Saudi princes can bribe the Threema creator, they can't compel Apple to push a malicious update the Threema creator signed to select people only. So they'll have to hack the device via other means.

Re: End-to-end encryption in the browser

#57

Post by thanksforfish »

m1el wrote: post #17

I appreciate the effort, but this is one of those cases in which there isn't much security added by encryption. If I assume the website owner is malicious (or subverted by powers that be), I cannot trust the JS code provided by the website. Key disclosure is as trivial as one line hidden somewhere in megabytes of JS code delievered from the server. Which makes "end-to-end" part nearly meaningless.

> there isn't much security added by encryption

Compared to just using HTTPS?

While there are ways the encryption can be removed or subverted that's a far cry from adding no benefit. Compared to just using HTTPS for client to server encryption, this protects the user from a bunch of server-based attacks. Certainly not all, but it does meaningfully raise the bar.

Keep in mind that security needs to be usable, and needs to exist in tools users actually use. If I'm a user if a web app, then browser based e2e encryption helps me. Downloading the diagram, installing PGP tools, figuring out how to use it, sending the file via a different mechanism... probably not something an average user wants to try.

Re: End-to-end encryption in the browser

#59

Post by _squared_ »

sneak wrote: post #35

From one of HN's own stars: Javascript Cryptography Considered Harmful: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... There are some out of date bits, but the core of the post is still as true as it was back in 2011.

It's not just "some out of date bits", 90% of this post is ridiculously outdated.

Making an end-to-end encrypted web app with WebAssembly, WebCrypto, Service Workers and free TLS by Let's Encrypt is totally viable nowadays. Also, the Web userbase is largely using evergreen browsers like Firefox and Chrome.

Re: End-to-end encryption in the browser

#60

Post by smolder »

dogma1138 wrote: post #52
marcus_holmes wrote: post #31

Earlier quoted context omitted.

well, not the whole url, obviously, otherwise the router wouldn't know where to send the request

The entire URL is encrypted, the router doesn't need to know anything about the URL to route the packets. The only thing that can leak when you make an HTTPS connection is the DNS query.

TLS server name indication can also leak your host, sadly.
Post reply on HN