Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proof of concept: end-to-end encryption in Jitsi Meet

jitsi.org

Post reply on HN
Print view View original

141–150 of 151 posts

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#141

Post by sigwinch28 »

cheald wrote: post #132
sigwinch28 wrote: post #101

Earlier quoted context omitted.

Yes, my comment w.r.t. the hash is that it's inherently a bad final implementation because it's visible to the server via malicious Javascript. I really hope that it can be as simple as "share a password with someone"/"send an invite link to someone" because as the parent effectively said, this would be a complete UX nightmare.

I'm having trouble envisioning how you could possibly put together a solution where the encryption key wouldn't be visible to Javascript, malicious or otherwise. How would that work?

Assuming that the client is essentially a web app then yes, the javascript must be able to read the encryption key.

However, it's not a hard requirement that the server delivers the javascript to us: it could be hosted locally, e.g. a trusted Electron wrapper around a set of HTML/CSS/JS stored on my computer, for some definition of trusted.

This is how a lot of other e2e-encrypted messaging app can be used, e.g. Signal, WhatsApp, Riot.im: a "trusted" set of client code over which the untrusted server has no control.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#143

Post by michaelt »

PureParadigm wrote: post #130
dcposch wrote: post #126

Earlier quoted context omitted.

This goes straight to one of the biggest holes in the web platform: there is no mechanism for code signing or release tracking. The web already has the world's most widely used public key infrastructure. When I go to amazon.com, I can be confident that my browser is talking to a service operated by Amazon, with nobody spying on or modifying messages in flight. However, I have zero guarantees regarding the HTML/CSS/JS…

For code signing to work you need to trust whoever is signing the code. As you mentioned, with HTTPS, all the contents are already signed by the web server. If Jitsi published a native app and signed it, would that even help you? You still have to trust them because they could have signed anything. Maybe you mean to compare it to a copy that has already been audited by someone else? Then you might as well use the aud…

If you are running a project like Tor Browser, that needs the highest security going, you would want:

1. Signing with an offline key, so an attacker can't make a release just by hacking the web server, and the key doesn't end up on however many hundred CDN web servers around the world.

2. Clear boundaries between releases, and a slow enough release schedule that third-party auditors can keep up.

3. Non-repudiation, so users know everyone else saw the same version they saw.

4. Reproducible builds from code in a public repo, so third-party auditors know what was released is what they reviewed.

5. An update process that verifies 1-3 before applying an update.

These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#144

Post by BrowserMeeting »

shadowgovt wrote: post #9

It's a nice tech demo, but it runs into the same problem that so many of these systems run into: individual users don't want to be arsed to self-manage their encryption keys. You can't solve the UX on that, and users will ignore your service in favor of one that doesn't require that of them. As service provider, you could keep their keys, but if they trust you with their keys, why aren't they trusting you with being…

You have to give them an “A” for effort. They are coming out in front of the encryption wars, even if it’s a half baked approach.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#145

Post by LinuxBender »

Arathorn wrote: post #129
PureParadigm wrote: post #123

There's a lot of discussion here about key exchange, and how you need to trust whatever service is managing the keys. From the demo, it looks like the key is basically a password. If you can share the password out-of-band through another secure channel (perhaps post it in a Signal chat or something), then your meeting should be secure. It can even be included as part of the link. But then doesn't the Jitsi web server…

yup, if you trust people to pass the URL around securely with a secret in a fragment, and you trust the recipients to keep the URL secret, and you're okay for anyone who ever discovers that secret to be able to decrypt and replay recordings of your conferences... then that may be acceptable. Otherwise, you'll want a way to ensure that only devices belonging to users you've explicitly invited are able to participate (…

Would there be a way to make the secret only valid for n period of time that is customizable by the admins or users?

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#146

Post by elric »

saghul wrote: post #138
elric wrote: post #135

Earlier quoted context omitted.

Seems like Jitsi relies on Chrom(e|ium) for a lot of things. Desktop sharing? Chrome plugin. Desktop client? Chromium/Electron. I tried setting up an instance for my company to replace zoom, but I can't go around demand that people install any particular browser.

That is not really true. Yes, our Firefox support has not been great, but we are working on making it better: https://github.com/jitsi/jitsi-meet/issues/4758 > Desktop sharing? Chrome plugin. This was a browser limiation, which is no longer needed since about 2 years ago. > Desktop client? Chromium/Electron. You need to ue it! Use the browser, or the mobile apps.

Jitsi Meet even shows a popup saying Firefox is not supported, and the only fully supported browsers are Chrome and Chromium.

You're right that screen sharing does seem to work in Firefox! Thanks for pointing that out. It looks like FF on my Linux box is blocking it, but I guess that's a permission issue I need to fix locally.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#147

Post by dane-pgp »

Joeri wrote: post #136
dcposch wrote: post #126

Earlier quoted context omitted.

This goes straight to one of the biggest holes in the web platform: there is no mechanism for code signing or release tracking. The web already has the world's most widely used public key infrastructure. When I go to amazon.com, I can be confident that my browser is talking to a service operated by Amazon, with nobody spying on or modifying messages in flight. However, I have zero guarantees regarding the HTML/CSS/JS…

With appcache / service workers and indexeddb you could probably build a tiny auditable offline loader, and then have it “install” payloads of which you can first verify signatures or audit the code. The main question remains why though.

The idea of using a service worker to install a persistent loader is a good one, and it was used by the WebSign system:

https://www.reddit.com/r/crypto/comments/42kzx1/thoughts_on_...

Unfortunately it relied on the HPKP Suicide technique, since otherwise a compromised server could send a malicious update to the service worker code. Now that HPKP has been abandoned by browsers, WebSign is no longer viable (and it always required you to trust that the server really was throwing away its private keys).

As for the question of "why", it seems like you are asking either "Why would someone choose to write/use a webapp when they could just write/use a native app instead?" or "Why would a webapp developer/user care about the threat model of a web host being compromised?". Both of those questions have reasonable answers for at least some non-zero number of webapps.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#148

Post by buu700 »

dane-pgp wrote: post #147
Joeri wrote: post #136

Earlier quoted context omitted.

With appcache / service workers and indexeddb you could probably build a tiny auditable offline loader, and then have it “install” payloads of which you can first verify signatures or audit the code. The main question remains why though.

The idea of using a service worker to install a persistent loader is a good one, and it was used by the WebSign system: https://www.reddit.com/r/crypto/comments/42kzx1/thoughts_on_... Unfortunately it relied on the HPKP Suicide technique, since otherwise a compromised server could send a malicious update to the service worker code. Now that HPKP has been abandoned by browsers, WebSign is no longer viable (and it alwa…

Actually WebSign is still in production at Cyph, and never strictly depended on HPKP, with the caveats that:

1. Rather than simply prevent an attack, it shows a scary warning that compromised code will be run on the next reload, and

2. It relies on things that aren't intended as security features, and so is inherently more fragile than it was originally. In particular, if an attacker could fill up enough of a user's disk space, some browsers may just evict the WebSign instance.

We recommend that regular users of Cyph install the desktop and mobile apps, but it's at least a reasonably safe solution that significantly improves usability.

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#149

Post by dane-pgp »

michaelt wrote: post #143
PureParadigm wrote: post #130

Earlier quoted context omitted.

For code signing to work you need to trust whoever is signing the code. As you mentioned, with HTTPS, all the contents are already signed by the web server. If Jitsi published a native app and signed it, would that even help you? You still have to trust them because they could have signed anything. Maybe you mean to compare it to a copy that has already been audited by someone else? Then you might as well use the aud…

If you are running a project like Tor Browser, that needs the highest security going, you would want: 1. Signing with an offline key, so an attacker can't make a release just by hacking the web server, and the key doesn't end up on however many hundred CDN web servers around the world. 2. Clear boundaries between releases, and a slow enough release schedule that third-party auditors can keep up. 3. Non-repudiation, s…

> These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design.

If by "webapps" you mean "applications that run inside a web browser" then I disagree, since it is possible to pin a specific (presumably third-party audited) version of a webapp by using a static local bookmarklet or saved file. See my other comment [1].

You're right, though, that this is not the typical user experience for a web app, and you might reasonably believe that all webapps should be visibly associated with a domain on the internet.

Personally I think it is acceptable if a high security webapp requires a slightly less convenient UX compared to normal webapps. Nevertheless, it should still be quicker and safer to "install" a bookmarklet than install a native application like the Tor Browser.

[1] https://news.ycombinator.com/item?id=22862376

Re: Proof of concept: end-to-end encryption in Jitsi Meet

#150

Post by Joeri »

dane-pgp wrote: post #147
Joeri wrote: post #136

Earlier quoted context omitted.

With appcache / service workers and indexeddb you could probably build a tiny auditable offline loader, and then have it “install” payloads of which you can first verify signatures or audit the code. The main question remains why though.

The idea of using a service worker to install a persistent loader is a good one, and it was used by the WebSign system: https://www.reddit.com/r/crypto/comments/42kzx1/thoughts_on_... Unfortunately it relied on the HPKP Suicide technique, since otherwise a compromised server could send a malicious update to the service worker code. Now that HPKP has been abandoned by browsers, WebSign is no longer viable (and it alwa…

With appcache and a long lived expiration header on the manifest it would be possible to guarantee that no updates to the original loader are ever downloaded, hence no risk of server compromise. Regrettably appcache is deprecated.
Post reply on HN