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

So You Want to Build an End-to-End Encrypted Web App

zfnd.org

Post reply on HN
Print view View original

21–30 of 38 posts

Re: So You Want to Build an End-to-End Encrypted Web App

#21

Post by lostmsu »

beders wrote: post #17
beders wrote: post #12

E2E is an illusion on anything other than a free Linux running on a free BIOS with no security enclave. You can't have E2E on mobile devices, you can't have E2E on any other OS. (And you'll probably have a hard time finding the right combination of hardware and Linux distro to have it on Linux)

Just in case you don't get it: The moment the information is unencrypted and made available via a userinterface, you've lost all control. You don't control the iOS rendering loop. You don't control the Android rendering system. (You might think you do though as much of Android is open source). You don't control the OS core libraries, you don't control the microcode of the CPU. You don't control the blitting to a scre…

You forgot that somebody can snoop on the unencrypted image on your screen.

Re: So You Want to Build an End-to-End Encrypted Web App

#22

Post by beders »

akerl_ wrote: post #19
beders wrote: post #12

E2E is an illusion on anything other than a free Linux running on a free BIOS with no security enclave. You can't have E2E on mobile devices, you can't have E2E on any other OS. (And you'll probably have a hard time finding the right combination of hardware and Linux distro to have it on Linux)

This seems to pick an arbitrary expansion of what “end to end” means, where “end” is “the OS layer on the source/destination computers”. What if the monitor is backdoored and sends copies of the display buffer to The Secret World Government? What if the keyboard has a hardware keylogger? What if we’re all living in an elaborate computer simulation of a global pandemic? As an alternate comparison: it’s still end-to-en…

Yes, I understand perfectly what is is.

But people attribute security properties to it that it doesn't have!

What good is protection against MITM if I can just read it off your device while you type it?

You have no security with mobile devices. It is foolish to think so.

Re: So You Want to Build an End-to-End Encrypted Web App

#23

Post by akerl_ »

beders wrote: post #22
akerl_ wrote: post #19

Earlier quoted context omitted.

This seems to pick an arbitrary expansion of what “end to end” means, where “end” is “the OS layer on the source/destination computers”. What if the monitor is backdoored and sends copies of the display buffer to The Secret World Government? What if the keyboard has a hardware keylogger? What if we’re all living in an elaborate computer simulation of a global pandemic? As an alternate comparison: it’s still end-to-en…

Yes, I understand perfectly what is is . But people attribute security properties to it that it doesn't have! What good is protection against MITM if I can just read it off your device while you type it? You have no security with mobile devices. It is foolish to think so.

I feel like you meant the question to be rhetorical, but for the sake of clarifying: there is tremendous value in protecting against MITM, even if there remain other attack vectors.

Encrypting traffic end-to-end over the network protects against entire categories of attack. For some attackers (for example: ISPs), end-to-end encryption essentially removes their ability to compromise traffic contents. For other attackers, it forces them to ignore those categories of attack and instead narrows them to things like compromising the device. Notably, Linux is not magically immune to device compromise, even if you’re running a magical open-source BIOS. And unlike Windows/OSX, Linux doesn’t have Apple/Microsoft paying large, motivated security teams whose work is pushed to all their devices. At best, Linux has commercial distro providers like RedHat paying for security work. At worst, it relies on the good will and skill sets of open source maintainers. In trade, Apple/Microsoft offer lower customizability/visibility into the OS. But since the average user is not interested in (or qualified to do) security hardening of devices, Linux isn’t likely to buy them anything meaningful in the field of device security.

All of this is to say “life is hard. We shouldn’t make it harder by protesting the concept of E2E encryption due to the obvious fact that it does not cure all ailments.”

Re: So You Want to Build an End-to-End Encrypted Web App

#24

Post by chrisweekly »

tialaramex wrote: post #10
rictic wrote: post #7

The equivalent to the app signing cert for a web app is the TLS cert. If security is important to you, don't let third parties control your TLS cert! It's so common now to let CDNs (primarily cloudflare) run your TLS frontend that this article apparently doesn't even consider the idea of hosting an app entirely from servers the app author controls. That said, it's true that a TLS cert is necessarily more exposed than…

The technology you want is Delegated Credentials: https://tools.ietf.org/html/draft-ietf-tls-subcerts-07 The certificate is public, it's fine for copies of that to be in all edge devices, the problem today is that the associated private key has to be on those edge devices too, and that's what Delegated Credentials solves.

+1 x 1000 This.

Re: So You Want to Build an End-to-End Encrypted Web App

#25

Post by e12e »

michelpp wrote: post #5

If you want to do this with something like libsodium there is a Key Exchange API https://doc.libsodium.org/key_exchange Knowing only each others public keys, two parties can exchange session keys for bidirectional encryption.

> Knowing only each others public keys

Do you even need a "protocol" if the clients trust each other?

Client A generates a random key, maybe a nonce - and a session Id - then encrypts that with Bs public key, signs with As private key - and sends that to B. Only B can decrypt the message, A and B now share a key.

Or maybe that is the protocol.

Anyway, if you know someone's public key and they know yours - you're already bootstrapped for a secure channel?

Ed: m seeing the page, I see this is more à link to the api for libsodium, and that obviously makes sense - to have standard implementation (and I guess this does some tricks for generating public/private session keys from long lasting public keys?

Re: So You Want to Build an End-to-End Encrypted Web App

#26

Post by dane-pgp »

kodablah wrote: post #6

> you can trust in TLS when you’re downloading signed software too; but for the web, you only trust in the connection, there’s nothing else to save you if you can’t trust that connection. While Signed HTTP Exchanges were originally developed for a more nefarious purpose (to allow the URL to be changed by a trusted proxy), I think the idea or one like it can apply to serving trusted web content. Think of it as instead…

I'm hopeful that Signed HTTP Exchanges lead to what you describe, but another Chrome-originating technology that could be extended/abused to achieve a similar goal is the tag.

There is already a little trick[0] that can be done with bookmarklets (or locally saved files) which allow you to bootstrap a page with a known set of JavaScript code running on it, but it has the disadvantage that the URL bar doesn't contain a familiar domain. If the spec[1] ends up supporting SRI[2] integrity hashes in a sensible way, this little bootstrapping technique could actually be practical.

[0] https://news.ycombinator.com/item?id=17776456

[1] https://wicg.github.io/portals/

[2] https://www.w3.org/TR/SRI/

Re: So You Want to Build an End-to-End Encrypted Web App

#27

Post by AlexCoventry »

kodablah wrote: post #6

> you can trust in TLS when you’re downloading signed software too; but for the web, you only trust in the connection, there’s nothing else to save you if you can’t trust that connection. While Signed HTTP Exchanges were originally developed for a more nefarious purpose (to allow the URL to be changed by a trusted proxy), I think the idea or one like it can apply to serving trusted web content. Think of it as instead…

> Signed HTTP Exchanges

Has anyone compiled a list of sites which offer Signed HTTP Exchanges/Real URL AMP feeds? Is there a straightforward way to make one?

Re: So You Want to Build an End-to-End Encrypted Web App

#28

Post by laughinghan »

> this basically boils down to TOFU (trust on first use), but the trust does not perpetuate across uses, so it’s more like, TOAU (trust on any use). The trust is ephemeral, the meeting is ephemeral, the ID is ephemeral. For a lot of meetings, this is perfectly acceptable.

I think I would call this TFSU (Trust For Single Use). Trust On Any Use sounds like complete and total trust.

Re: So You Want to Build an End-to-End Encrypted Web App

#29

Post by the8472 »

dane-pgp wrote: post #26
kodablah wrote: post #6

> you can trust in TLS when you’re downloading signed software too; but for the web, you only trust in the connection, there’s nothing else to save you if you can’t trust that connection. While Signed HTTP Exchanges were originally developed for a more nefarious purpose (to allow the URL to be changed by a trusted proxy), I think the idea or one like it can apply to serving trusted web content. Think of it as instead…

I'm hopeful that Signed HTTP Exchanges lead to what you describe, but another Chrome-originating technology that could be extended/abused to achieve a similar goal is the tag. There is already a little trick[0] that can be done with bookmarklets (or locally saved files) which allow you to bootstrap a page with a known set of JavaScript code running on it, but it has the disadvantage that the URL bar doesn't contain a…

Combine SRI with CSPs and cache-control: immutable and you could already commit a page to never change. All that's missing for TOFU is fingerprinting this combination, watching for changes and surfacing the information to the user.

Re: So You Want to Build an End-to-End Encrypted Web App

#30

Post by lisper »

the8472 wrote: post #29
dane-pgp wrote: post #26

Earlier quoted context omitted.

I'm hopeful that Signed HTTP Exchanges lead to what you describe, but another Chrome-originating technology that could be extended/abused to achieve a similar goal is the tag. There is already a little trick[0] that can be done with bookmarklets (or locally saved files) which allow you to bootstrap a page with a known set of JavaScript code running on it, but it has the disadvantage that the URL bar doesn't contain a…

Combine SRI with CSPs and cache-control: immutable and you could already commit a page to never change. All that's missing for TOFU is fingerprinting this combination, watching for changes and surfacing the information to the user.

Unfortunately that by itself does not guarantee security. The code that is verified by the bookmarklet could download additional code when it runs, and that code would not be verified.
Post reply on HN