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

131–140 of 151 posts

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

#131

Post by Arathorn »

dcposch wrote: post #126
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…

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…

If you talk HTTPS to a given host, assuming that TLS has not been compromised and the host itself has not been compromised, you can trust the app published by the developer to be correct. For stuff which is pulled in from other hosts which you don't control (e.g. CDNs), you can use subresource integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subres....

Agreed that it feels like there should be another mechanism to publish subresource integrity hashes for your own resources somewhere so that people can spot if your server or TLS gets compromised though (similar to CT). Sounds like someone else had the same idea at https://lists.w3.org/Archives/Public/public-webappsec/2014Ju... - I wonder why it didn't go anywhere?

Meanwhile, if you don't want to trust TLS or the host which originates the code, then for now you're probably better off using a desktop app (e.g. electron, although that comes with a whole different attack surface) or a browser extension which can be distributed as signed code.

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

#132

Post by cheald »

sigwinch28 wrote: post #101
Arathorn wrote: post #94

Earlier quoted context omitted.

I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the keys of who's actually in the room, rather than just trusting a static key which will inevitably leak. They're presumably also planning to re-key via a ratchet to avoid a single leaked key compromising the whole conference recording.

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?

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

#133

Post by jcims »

jcims wrote: post #15

Tech support question haha. I run Jitsi Meet (the service at meet.jit.si) on an iPad that I bought last year. After about an hour the audio completely fails. No audio in. No audio out. I can't really tell if it's something with the app or if it's my terrible little dsl router/nat box dropping the audio stream. I don't have this problem on the desktop or laptop clients, just the iPad, so I'm guessing it's the app...bu…

welp...

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

#134

Post by dane-pgp »

Arathorn wrote: post #131
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…

If you talk HTTPS to a given host, assuming that TLS has not been compromised and the host itself has not been compromised, you can trust the app published by the developer to be correct. For stuff which is pulled in from other hosts which you don't control (e.g. CDNs), you can use subresource integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subres... . Agreed that it feels like there should be anothe…

It makes sense to use SRI to control the subresources which get loaded, but there is a clever trick which can be done to ensure that an entire webapp uses a fixed bundle of code.

The trick was discussed on Hacker News some time ago[1], but the basic idea is to use a bookmarklet (or saved local page) which contains a single tag with an integrity hash baked into it. The loaded script (once the hash check passes) then acts as a bootloader for all the other resources that it pulls in, eval'ing them only if their hashes (or perhaps signatures) match a hardcoded list (or public key).

Of course there are some UX issues with this, such as the location bar not containing an actual domain (and reassuring padlock), although it might be possible to fix this depending on how the proposed tag[2] interacts with SRI. Also, the process of creating the bookmarklet is more awkward than just clicking a link, and it may have to be repeated every time a new version of the webapp is released (or rather, when the new version has been audited by one or more trusted entities).

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

[2] https://web.dev/hands-on-portals/

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

#135

Post by elric »

christefano wrote: post #74

Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.

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.

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

#136

Post by Joeri »

dcposch wrote: post #126
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…

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.

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

#137

Post by saghul »

christefano wrote: post #74

Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.

It is our belief that by doing this we'll also be helping adoption. If a browser vendor (any of them) propoes an API, but nobody uses it, why would the rest care to implement it?

The ability to do E2EE is kind of a big deal, even though insertable streams can be used for other things, so we hope other browser vendors join the effort.

There have been other approaches in the past such as PERC [0] and ongoing related ones like MLS [1], this is a relevant topic these days.

[0]: https://datatracker.ietf.org/group/perc/documents/ [1]: https://datatracker.ietf.org/wg/mls/about/

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

#138

Post by saghul »

elric wrote: post #135
christefano wrote: post #74

Sad to see this is dependent on an extension to WebRTC that’s (currently) Chrome / Chromium-only. It’s still a proposed API, and I don’t see when this will be supported by any other browsers.

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.

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

#139

Post by saghul »

cdolan wrote: post #29

I just learned Jitsi is supported in part by 8x8. That gives me concern and I'll have to research the ties there before switiching ti Jitsi. I'm making this a top level comment given its length, but I wrote this after seeing Vinnl's question on 8x8. I was an 8x8 customer for about 10 years as a small/medium business. I would never buy from them again. I now use Zoom, but am considering switching given the recent priv…

I can't speak to any of that, but you don't need 8x8 in order to run Jitsi.

Jitsi is the same project it was when it was run by an independdent company. It's the same project it was when Atlassian acquired it, and continues to be the same project now at 8x8.

It's Apache 2 licensed, and you are more than welcome to use it without dealing with 8x8 at all.

Disclaimer: I'm a Fellow Jitster at 8x8.

Post reply on HN