End-to-end encryption in the browser • Hacker News Board

Re: End-to-end encryption in the browser

#21

Post by m1el » Mon, Mar 23, 2020, 1:46 PM UTC

lipis wrote: post #19

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 open source :)

And how can I be sure that the code delivered by the server is the same code as in the public codebase?

Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.

Re: End-to-end encryption in the browser

#22

Post by reimertz » Mon, Mar 23, 2020, 1:47 PM UTC

Awesome work! Definitely not common knowledge that parameters after # isn't sent over the wire. Can be used in fun ways.

I did the same thing but for text with https://anolog.org.

Sadly, since I used anonymous gists hosted on Github as my Data store, which they shut down last year, the service doesn't work anymore. :(

Re: End-to-end encryption in the browser

#23

Post by lipis » Mon, Mar 23, 2020, 1:49 PM UTC

m1el wrote: post #21

lipis wrote: post #19

Earlier quoted context omitted.

It's open source :)

And how can I be sure that the code delivered by the server is the same code as in the public codebase? Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.

In theory you can generate the code locally and compare it with the deployed version to see that it's one to one.. But maybe we could do something in order to improve the said security check.

Re: End-to-end encryption in the browser

#24

Post by 3pt14159 » Mon, Mar 23, 2020, 1:49 PM UTC

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…

Well it helped one of those password manager companies during cloudbleed. There is a couple of threat models where it does help. Mitigates bitsquatting too.

Re: End-to-end encryption in the browser

#25

Post by 1f60c » Mon, Mar 23, 2020, 1:51 PM UTC

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…

> Also, why can't I draw an actual non-flawed circle ?

On my laptop (a MacBook Pro) holding down the Shift key accomplishes that. As for the hand-drawn edges, that's just part of the aesthetic :-)

Re: End-to-end encryption in the browser

#26

Post by seemslegit » Mon, Mar 23, 2020, 1:54 PM UTC

1f60c wrote: post #25

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…

> Also, why can't I draw an actual non-flawed circle ? On my laptop (a MacBook Pro) holding down the Shift key accomplishes that. As for the hand-drawn edges, that's just part of the aesthetic :-)

Yeah was referring to the edges, if you gonna add a "sloppiness" level in the toolbar might as well have proper edges

Re: End-to-end encryption in the browser

#27

Post by MaxBarraclough » Mon, Mar 23, 2020, 1:57 PM UTC

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.

LastPass has the same problem.

Re: End-to-end encryption in the browser

#28

Post by marcus_holmes » Mon, Mar 23, 2020, 1:58 PM UTC

tialaramex wrote: post #18

inetknght wrote: post #12

Earlier quoted context omitted.

URLs are encrypted. Hostnames aren't encrypted in HTTPS, unless TLS SNI is encrypted. The problem with URLs is that a lot of products will log the URL to disk, and many operators forget or aren't aware they might need to have security plans around data in the logs.

A worse and impossible to mitigate problem in other scenarios is that user agents will cheerfully "bookmark" or "favourite" a URL or just let you "share" it and it's often not obvious to the end user that this shares their current state which they probably don't want not just the thing they're looking at. Example: you try to share the forum help link but instead give the recipient your logged in account... This is th…

yeah, this.

Having the key in the url seems insanely insecure to me.

Re: End-to-end encryption in the browser

#29

Post by franky47 » Mon, Mar 23, 2020, 2:00 PM UTC

m1el wrote: post #21

lipis wrote: post #19

Earlier quoted context omitted.

It's open source :)

And how can I be sure that the code delivered by the server is the same code as in the public codebase? Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.

If the JavaScript bundle that is being served is built on a public CI/CD service, it could be possible to do the following, for transparency and verification:

- Include in a header comment: the build URL, Git SHA-1 of the commit, and other metadata

- Sign the bundle using public/secret key cryptography

Having the build URL and sources URL help with discoverability and transparency, while integrity can be verified with the signature.

Adversary models now shift from the bundle provider to the CI/CD platform that runs the build, and any PKI used for the public key for signature verification. If the public key is versioned with the code, it can help reduce trust to a single entity (where the code is stored).

Re: End-to-end encryption in the browser

#30

Post by [deleted] » Mon, Mar 23, 2020, 2:00 PM UTC

lipis wrote: post #23

m1el wrote: post #21

Earlier quoted context omitted.

And how can I be sure that the code delivered by the server is the same code as in the public codebase? Nothing stops the owner of the service to run arbitrary JavaScript in Users' browser.

In theory you can generate the code locally and compare it with the deployed version to see that it's one to one.. But maybe we could do something in order to improve the said security check.

[deleted]