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

41–50 of 112 posts

Re: End-to-end encryption in the browser

#41

Post by smolder »

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…

Let's say someone vacuums up all the packets going over the wire passively and has some way of breaking TLS. Redundant encryption would be a further obstacle to reading the contents. TLS gets MITM'd in some environments, so it's useful there.

Re: End-to-end encryption in the browser

#42

Post by dwheeler »

ckocagil wrote: post #15

Is this going to be legal in the US under EARN IT?

Almost certainly not. EARN IT doesn't technically forbid encryption, it just lets an unelected board decide the legal requirements for communication without being sued into oblivion. But the unelected board will be under the control of those who object to encryption they can't break.

It would probably be legal if the program also sent the crypto keys somewhere for later use.

Re: End-to-end encryption in the browser

#43

Post by minitech »

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 detect, but it’s a start. There’s always the risk of serving it up to someone who’s logging every response.)

Re: End-to-end encryption in the browser

#44

Post by smolder »

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.

Modifying source to extract keys runs a risk of detection; it is overt. So it's preferable to passively snoop. If someone has a way to passively snoop TLS contents, the extra encryption protects data from them.

Re: End-to-end encryption in the browser

#45

Post by dwheeler »

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.

Agreed. If it stored data on a different server (allowed via CORS) then there could be some additional security, since then as a long as the JavaScript isn't subverted on the same site, you're storing encrypted data on a different server.

But yes, if you run JavaScript, you're always trusting that site to not do a "quiet update" of the code to something malicious. I don't see any obvious way to counter that, short of downloading the JavaScript code & running it yourself.

Re: End-to-end encryption in the browser

#46

Post by geofft »

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 basically eliminates risk from untargeted attacks, which is well worth doing.

(Also now warrants that can compel disclosure have nothing they can target, eliminating Lavabit-style attacks. There's still the possibility of court orders making you write software like the proposed use of the All Writs Act against Apple, but that's on much less certain legal ground.)

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

Re: End-to-end encryption in the browser

#47

Post by _bxg1 »

m1el wrote: post #40
_bxg1 wrote: post #36

Earlier quoted context omitted.

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 can build a native app from the codebase myself. I can be sure that a native up won't change in-between launches. > In any E2E context you have to trust the client code. I don't have to trust code which is continuously being delievered from the server. This is an intractable problem.

Others have said it's open-source. Build it yourself, inspect what your browser downloads, hash and compare like normal.

Re: End-to-end encryption in the browser

#48

Post by SamBam »

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 ?

Adding sloppiness when white boarding is a common pattern to indicate roughness. It subtly cues the viewer not to treat it as a completed product, and allows them more freedom to make changes. If you wanted clean lines, there are many web drawing tools for that too.

Re: End-to-end encryption in the browser

#49

Post by j4_hnews »

One of the problems with hacking the hashtag (#) in the URL is that this fragment identifier is supposed to be used to identify a portion of the document. As such unexpected things can happen when you try to exploit the hash tag for other purposes.

For example, with older of versions of Microsoft Office you cannot use a pound character in a hyperlink:

https://support.microsoft.com/en-us/help/202261/you-cannot-u...

Some email applications may unexpectedly strip the tag, attempting to be smart about handling it in the RFC 3986 sense (not anticipating this use-case at all). When the data appended to the # is a dependency to view the link, it can more easily render the link unusable.

Re: End-to-end encryption in the browser

#50

Post by geofft »

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…

Depends on the attack, really. Some realistic threats:

- The hosting service doesn't wipe physical disks they discard.

- The hosting service doesn't wipe virtual disks between customers.

- Your offsite backup provider gets compromised.

- Someone conducts a non- targeted attack, dumps whatever SQL database they see, and leaves before they get noticed.

- Someone conducts a targeted attack but gets noticed before they can develop a working patch to compromise the service.

- Someone (e.g., a government) pressures your hosting provider for data but doesn't want you to know. Modifying your JS files would risk being noticed.

Post reply on HN