Hacker News Reader

Comment by gfodor | Hacker News Reader

with closed source, hosted software E2EE is as much about trust as it is about technology since you can't verify its implementation. arguably, if trust is there, E2EE doesn't get you much anyway other than for scenarios where the company itself is breached.

in any case, if the trust isn't there, you can't validate the E2EE, so your risk profile with regards to using the software doesn't change much.

View on HN

You can verify closed source E2EE as long as you can inspect the traffic going client-server. The problem is that most E2EE apps allow auto-updating, so baking in something that transmits info to a third party is easy (but detectable with enough eyes on the code).

But what's stopping the software from, say, having a backdoor that is only exposed under certain conditions? For example, if you are under an FBI investigation. I suppose you could automate the verification on a per-call basis. Unfortunately, every bit over the wire would need to be seen by a fool-proof algorithm to ensure your safety. Seems not tractable.

Agreed. You can only verify E2EE for the traffic you inspect, not for traffic you don't. If they open-sourced the client it'd help a lot, but I'd also like to point out that you probably have stuff in your current device that has DMA and network access that is not open source either (PSP, IME, 4G modem, and so on) and that could break that encryption too.

If you are under serious investigation I wouldn't trust anything "smart" manufactured in a country under that investigations jurisdiction.

Yup fair point. Circling back to Zoom, I think the trust part of this has been violated enough that such an inspector tool ought to be considered strictly necessary to use it if you are security minded. So in the end, there's not much of a point to the announcement imo.

If the closed source E2EE app is sending encrypted messages but leaking bits of the key in how those messages are padded, for example, how would you detect that?

As for the threat model of open source E2EE apps auto-updating to an insecure version, you're right that this needs some extra defences. One way would be to use a binary-transparency log[0] to make sure that the open source project had publicly committed to a specific binary at least 24 hours in advance of pushing the auto-update.

This system relies on there being auditors out there who would raise the alarm if a malicious update was released, or a hash was included in the log for which there was no corresponding (reproducibly buildable) source code.

[0] https://wiki.mozilla.org/Security/Binary_Transparency

I imagine you mean inspecting everything that gets transmitted besides the -2E part, but even if you could there are a thousand ways for not-really-safely-encrypting a communication without you being able to notice

Apple FaceTime is also closed source, E2E and verifiable

What is the process for verifying that FaceTime isn't leaking the encryption keys to Apple's servers?

I don’t know, but as a black box it’s been extensively looked at. But nothing is unhackable even E2E.

How would one know that this black box works the same for every user? What would stop Apple from distributing a compromised update to everyone or to selected users?

Yep any protocol and any app can have this problem.

The protection against this problem is to have the app (or the platform it's running on) check before installing an update that the hash of the binary it has downloaded has been recorded in a public transparency log.

With closed source software, though, this doesn't give as much confidence, since a company could create a version which they send to everyone but which contains an "if (userId == NSA_TARGET)" conditional branch.

Reply on news.ycombinator.com