[HN Gopher] So You Want to Build an End-to-End Encrypted Web App
___________________________________________________________________
So You Want to Build an End-to-End Encrypted Web App
Author : madrafi
Score : 75 points
Date : 2020-06-05 09:25 UTC (13 hours ago)
(HTM) web link (www.zfnd.org)
(TXT) w3m dump (www.zfnd.org)
| Boulth wrote:
| I 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.
| beders wrote:
| 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)
| akerl_ wrote:
| 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-end encrypted
| communication if I take the securely received message, print
| out a copy, and tape it to a bulletin board at the town square.
|
| The "end-to-end" refers to the transmission path. It's a
| defense against MITM, and can be accomplished by plenty of
| systems that aren't Linux.
| beders wrote:
| 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.
| akerl_ wrote:
| 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."
| UweSchmidt wrote:
| Any specific software and hardware that qualifies or comes
| close?
| beders wrote:
| 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 wrote:
| E2E is a property of the software, not the software license.
| beders wrote:
| 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 wrote:
| 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 wrote:
| 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.
| lostmsu wrote:
| You forgot that somebody can snoop on the unencrypted image
| on your screen.
| rictic wrote:
| 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 wrote:
| 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.
| chrisweekly wrote:
| +1 x 1000 This.
| michelpp wrote:
| 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.
| oneng wrote:
| Speaking of E2E Encryption, the Jitsi Team is looking for
| feedback on their own implementation of E2E over WebRTC.
|
| https://jitsi.org/blog/e2ee/
| kodablah wrote:
| > 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.
| supermatt wrote:
| > 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 wrote:
| Coming soon? https://9to5google.com/2020/05/08/google-duo-web-
| group-calls...
| lsh123 wrote:
| Check WhatsApp. There is very limited multi device support but
| all messages and calls are always e2ee.
| h3cate wrote:
| 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
| rarrrrrr wrote:
| I appreciate when technical writers use humor (those headlines!)
___________________________________________________________________
(page generated 2020-06-05 23:00 UTC)