Web client and JavaScript crypto

[dconnolly]

I know web client support is not part of phase 1, but many existing Zoom users (such as ChromeOS¹) will need it. Has there been any consideration of what the threat model looks like when trying to deploy implementations of things like Ed25519 (since it's not supported in the webcrypto API), either from a side channel perspective or just a web security model perspective? Answers such as 'no we haven't thought about it' and/or 'the web is fundamentally harder to secure an E2EE design like this, use the !web clients if your personal threat model requires it' are understandable.

¹ The current Chrome app (not to be confused with the Chrome extension), seems to just be a wrapper around the existing Zoom web app. I know Chrome apps are supposed to go away eventually, but the existing one could be turned into a full software bundle on its own and avoid some of the security dilemma of deploying secure js on ~every page load.

[paulmillr]

(check out the tiny implementation of ed25519+ristretto255 in typescript/js: noble-ed25519)

With web, it's impossible to make any constant-time assumptions. Because of garbage collection, JIT, and other stuff. Algorithmic constant-timeness only gets us somewhere, but not there.

[kwantam]

in this vein, it may be worthwhile to consider whether something like CT-wasm would be a good target for a web client impl.

https://github.com/PLSysSec/ct-wasm https://arxiv.org/abs/1808.01348 (paper appeared at POPL'19)

[paulmillr]

@kwantam no. Wasm won't help here. The web platform is still going to be used with its gc and jit. It's a big misconception that wasm helps with security -- i'd argue it makes it worse, since you cannot verify binary code. And no, "verifying bin hash" is not an option since no one includes those.

[kwantam]

@paulmillr, I think you are making assumptions that essentially boil down to "there's no way to make anything secure," which I don't find productive or convincing.

"You cannot verify binary code" is either incorrect or is using a weird definition of "verify." By this do you mean that you'd prefer to see javascript so that you can read all of the code that zoom delivers to you at the beginning of every meeting, to make sure there are no back doors? I don't intend this question to be obnoxious, I'm just struggling to come up with a more charitable interpretation.

In any case, if your claim is that there's no way to check that the code on the client hasn't been tampered with, then it should be pretty clear that there's no way to get anything approaching security. But I think you'll have to do better than "no one includes [hashes]" to make that argument. This is, after all, the whole point of SRI and related concepts, and all of these should be considered prerequisite to running any cryptographic code delivered from the server to the client, constant-time or no.

I'm also not sure how to interpret "the web platform is still going to be used with its gc and jit," since this doesn't really respond to my point.

In any case, I should clarify that I certainly do not regard wasm as some magic bullet; but we've learned the side-channel lesson enough times by now that probably we shouldn't take seriously any "secure" system that disregards constant-timeness, especially in an environment as adversarial as the browser.

[paulmillr]

we've learned the side-channel lesson enough times by now that probably we shouldn't take seriously any "secure" system that disregards constant-timeness

We can agree on that.

My goal was not bringing unproductiveness to the discussion. I just want a way to verify the code i'm running, and to me it's a much bigger problem than constant-timeness. It's also a huge problem in js community, everyone creates packages that use 50 dependencies, which makes the output impossible to audit.

So, if there would be some movement towards wasm, I just want to ensure the code would stay auditable. That's it.

[kwantam]

So, if there would be some movement towards wasm, I just want to ensure the code would stay auditable. That's it.

Extremely fair, and it's definitely true that binaries make this harder. One solution is reproducible builds + signed binary + open source implementations---but this is a lot to get right!

[jpgoldberg]

Answers such as [...] 'the web is fundamentally harder to secure an E2EE design like this, use the !web clients if your personal threat model requires it' are understandable.

As someone who has given that answer many times, that is what I would expect as the only reasonable answer here.

I agree with those who point out that wasm is still a long way from solving the problem of the limits of what is available in WebCrypto. Among other things there will need to be progress on https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md#proposed-origin-bound-permission And I believe that I understand why progress on that will be slow.

There is the additional problem with how web clients are delivered, as there is only TLS protecting their integrity, while !web clients will typically be code signed.

So I think that it is fair to design what for native clients and acknowledge that web clients will not offer the same security guarantees as the native clients. You tie your hands badly if you try to design for web-clients. I believe that the implied approach here of deferring any discussion of how web clients will work is correct, but it should be acknowledge that web clients may have to be substantially delayed or will not have the same security guarantees as the native clients.

[dconnolly]

So I think that it is fair to design what for native clients and acknowledge that web clients will not offer the same security guarantees as the native clients. You tie your hands badly if you try to design for web-clients. I believe that the implied approach here of deferring any discussion of how web clients will work is correct, but it should be acknowledge that web clients may have to be substantially delayed or will not have the same security guarantees as the native clients.

I basically agree with your whole comment, just want to make sure that this new design is taking into account the fact that it cannot be safely deployed to the existing web-based clients. I'm always hoping that this can be solved for web apps, but it will probably require a fundamental shift in the web platform as it exists to do so. :/

[eligrey]

One thing is for sure: Zoom is going to need to implement a service worker to regulate and control webapp updates. Ideally this service worker could also be configured to require user authorization before applying updates.

[nealmcb]

Note @astamos has a related post with a nice graduated set of levels of protection against a variety of threats at https://twitter.com/alexstamos/status/1264240804849049600, also available via threadreaderapp: alexstamos on levels of privacy protections in interpersonal communication platforms See that for exposition on these levels:

0. Unencrypted
1. Encrypted on the Wire
2. End-to-End with Server Trust
3. End-to-End with User Verification
4. End-to-End with Automated Transparency
5. E2E with Automated Transparency and Reproducible Builds

[LeaKissner]

Thank you for your cogent comment! As you point out, @dconnolly , the web is much, much harder to secure for E2EE designs. For example, there is currently no good way to secure against the ability of a compromised server to potentially serve you targeted code which might exfiltrate your keys. It's also quite difficult to persistently store keys in a place which avoids being accidentally backed up to a server. (We would, of course, welcome browser security features in these spaces.)

We are cautious about shipping our own primitives in JS or WASM as it’s awfully hard to properly guarantee that they’ll be free from side channel attacks as a result of being interpreted code run in a VM specifically designed for speed rather than security with regards to constant time computations.

We will continue to watch the space and revisit this decision accordingly.