So You Want to Build an End-to-End Encrypted Web App
1–10 of 38 posts
Re: So You Want to Build an End-to-End Encrypted Web App
#2> This is not just a theoretical either: Google Duo supports E2EE group calls on Android, iOS… and web!
Google Duo does NOT support E2EE group calls on web... They actually don't support ANY group calls in the web app.
Lack of good support for e2ee multiparty calls is probably why - the hope is that adoption of insertable streams will change that.
Re: So You Want to Build an End-to-End Encrypted Web App
#3I started building an end to end encryption API once that includes server/client setups. I promise I'll finish it one day (there's still client - client to do. client - server is all done) https://gitlab.com/DrRoach/NetworkAPI
Re: So You Want to Build an End-to-End Encrypted Web App
#4I appreciate when technical writers use humor (those headlines!)
Re: So You Want to Build an End-to-End Encrypted Web App
#5If 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.
Re: So You Want to Build an End-to-End Encrypted Web App
#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 of your current TLS cert verifying your host, it would also verify the full URL and content including headers. It's a bit untenable for regular use, but some apps could leverage it for extra trust.
> When designing E2EE protocols for persistent vs ephemeral applications, we need to figure out where we need long-term identity in terms of cryptographic keys, and where we don’t.
I would hope that web apps always lean towards ephemeral key use whenever possible (i.e. key generation and post of public key in browser upon authentication, with private key only in local JS memory for just that page). If this means the webapp has to be built to work with 20 different keys for a user because they opened 20 tabs, so be it. I know people are afraid of doing anything like key generation in the browser, but we can't ride-off the possibility of e2ee web apps altogether. I fear the browser allowing access to the OS's key management or the system's TPM for key storage because it may lead to overuse/over-reliance on long-term keys, but I'm sure it'll happen if it hasn't already.
Re: So You Want to Build an End-to-End Encrypted Web App
#7The 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 an app signing cert can be. If you're serious about security, your app signing cert will be on an airgapped machine. The TLS cert however has to be available on a networked machine in order to sign messages.
Re: So You Want to Build an End-to-End Encrypted Web App
#8I haven't seen any mentions or this extension that allows verifying pages before they are rendered: https://github.com/tasn/webext-signed-pages
Another thing is non exportable WebCrypto keys that can limit the damage even if the page is compromised.
Re: So You Want to Build an End-to-End Encrypted Web App
#9Speaking of E2E Encryption, the Jitsi Team is looking for feedback on their own implementation of E2E over WebRTC.
Re: So You Want to Build an End-to-End Encrypted Web App
#10The 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.