6 ms·

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

167 points by madrafi 6y ago

Boulth 6y ago
I haven't seen any mentions or this extension that allows verifying pages before they are rendered: https://github.com/tasn/webext-signed-pages 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.
oneng 6y ago
Speaking of E2E Encryption, the Jitsi Team is looking for feedback on their own implementation of E2E over WebRTC. https://jitsi.org/blog/e2ee/ https://jitsi.org/blog/e2ee/
supermatt 6y ago
> 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.
- philips 6y ago
  Coming soon? https://9to5google.com/2020/05/08/google-duo-web-group-calls/ https://9to5google.com/2020/05/08/google-duo-web-group-calls...
- lsh123 6y ago
  Check WhatsApp. There is very limited multi device support but all messages and calls are always e2ee.
- supermatt 6y ago
  Not sure why I got downvoted - go try it yourself. Group calls are not supported at all in the webapp. As announced last month it is coming soon - but certainly not yet.
h3cate 6y ago
I 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 https://gitlab.com/DrRoach/NetworkAPI
rarrrrrr 6y ago
I appreciate when technical writers use humor (those headlines!)
michelpp 6y ago
If you want to do this with something like libsodium there is a Key Exchange API https://doc.libsodium.org/key_exchange https://doc.libsodium.org/key_exchange Knowing only each others public keys, two parties can exchange session keys for bidirectional encryption.
- e12e 6y ago
  > 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?
kodablah 6y ago
> 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.
- dane-pgp 6y ago
  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 <portal> 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 <portal> 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 https://news.ycombinator.com/item?id=17776456 [1] https://wicg.github.io/portals/ https://wicg.github.io/portals/ [2] https://www.w3.org/TR/SRI/ https://www.w3.org/TR/SRI/
  - the8472 6y ago
    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.
rictic 6y ago
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 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.
- tialaramex 6y ago
  The technology you want is Delegated Credentials: https://tools.ietf.org/html/draft-ietf-tls-subcerts-07 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.
  - chrisweekly 6y ago
    +1 x 1000 This.
  - rictic 6y ago
    That definitely helps, at least for short term compromise of TLS servers.
beders 6y ago
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)
- UweSchmidt 6y ago
  Any specific software and hardware that qualifies or comes close?
  - beders 6y ago
    I really don't know which firmware nowadays qualifies as secure i.e. without backdoors. The times where we had complete control over our hardware seem to be over. Would also like to know about the current state of Open Hardware.
- millstone 6y ago
  E2E is a property of the software, not the software license.
  - beders 6y ago
    Yeah, even that is not true. Do you know what Apple does with text you enter into a text field? Or the letters you type on a virtual keyboard? It's closed source and even if it were open source, you have no way of checking if the binary has been produced by that source code. You don't control anything.
    - millstone 6y ago
      I agree, I don't control any of that. But E2E is a technical property of a system. It's not a social property regarding who controls what.
- beders 6y ago
  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 screen device or the recording of photons on a camera. And I'm not even talking about external manipulation to exfiltrate data. You might control the content of the IP packages sent. You don't control any other IP packages sent.
laughinghan 6y ago
> 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.
- OJFord 6y ago
  Or Each.
camhart 6y ago
While this article points out there are still opportunities for a malicious actor to gain access to the private keys stored locally in the browser, wouldn't that still be an improvement over only using https and server side encryption? I'm not a crypto expert--so forgive my ignorance.
emilfihlman 6y ago
It used to be possible to actually do TOFU without PKI in browser with caching, trusted sha signatures and user certificates but it was deprecated.

167 points by madrafi 6y ago

I haven't seen any mentions or this extension that allows verifying pages before they are rendered: https://github.com/tasn/webext-signed-pages 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.

oneng 6y ago

Speaking of E2E Encryption, the Jitsi Team is looking for feedback on their own implementation of E2E over WebRTC. https://jitsi.org/blog/e2ee/ https://jitsi.org/blog/e2ee/

supermatt 6y ago

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

philips 6y ago
Coming soon? https://9to5google.com/2020/05/08/google-duo-web-group-calls/ https://9to5google.com/2020/05/08/google-duo-web-group-calls...
lsh123 6y ago
Check WhatsApp. There is very limited multi device support but all messages and calls are always e2ee.
supermatt 6y ago
Not sure why I got downvoted - go try it yourself. Group calls are not supported at all in the webapp. As announced last month it is coming soon - but certainly not yet.

h3cate 6y ago

I 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 https://gitlab.com/DrRoach/NetworkAPI

rarrrrrr 6y ago

I appreciate when technical writers use humor (those headlines!)

michelpp 6y ago

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

e12e 6y ago
> 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?

kodablah 6y ago

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

dane-pgp 6y ago
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 <portal> 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 <portal> 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 https://news.ycombinator.com/item?id=17776456 [1] https://wicg.github.io/portals/ https://wicg.github.io/portals/ [2] https://www.w3.org/TR/SRI/ https://www.w3.org/TR/SRI/
- the8472 6y ago
  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.

rictic 6y ago

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

tialaramex 6y ago
The technology you want is Delegated Credentials: https://tools.ietf.org/html/draft-ietf-tls-subcerts-07 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.
- chrisweekly 6y ago
  +1 x 1000 This.
- rictic 6y ago
  That definitely helps, at least for short term compromise of TLS servers.

beders 6y ago

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)

UweSchmidt 6y ago
Any specific software and hardware that qualifies or comes close?
- beders 6y ago
  I really don't know which firmware nowadays qualifies as secure i.e. without backdoors. The times where we had complete control over our hardware seem to be over. Would also like to know about the current state of Open Hardware.
millstone 6y ago
E2E is a property of the software, not the software license.
- beders 6y ago
  Yeah, even that is not true. Do you know what Apple does with text you enter into a text field? Or the letters you type on a virtual keyboard? It's closed source and even if it were open source, you have no way of checking if the binary has been produced by that source code. You don't control anything.
  - millstone 6y ago
    I agree, I don't control any of that. But E2E is a technical property of a system. It's not a social property regarding who controls what.
beders 6y ago
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 screen device or the recording of photons on a camera. And I'm not even talking about external manipulation to exfiltrate data. You might control the content of the IP packages sent. You don't control any other IP packages sent.

laughinghan 6y ago

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

OJFord 6y ago
Or Each.

camhart 6y ago

While this article points out there are still opportunities for a malicious actor to gain access to the private keys stored locally in the browser, wouldn't that still be an improvement over only using https and server side encryption? I'm not a crypto expert--so forgive my ignorance.

emilfihlman 6y ago

It used to be possible to actually do TOFU without PKI in browser with caching, trusted sha signatures and user certificates but it was deprecated.