Proof of concept: end-to-end encryption in Jitsi Meet • Hacker News Board

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

#121

Post by tpolzer » Mon, Apr 13, 2020, 10:53 PM UTC

crazygringo wrote: post #120

I'm actually really curious as to whether verifiable E2EE is possible in normal business videoconferencing -- if someone here can enlighten me I'd really appreciate it. It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandw…

Key distribution is a problem, yes (as discussed in other comments here).

Upload bandwidth isn't so much of a problem with the number of participants, as you of course wouldn't encrypt the whole data stream separately for each peer. Instead, you would encrypt it with a rotating symmetrical key that you can then safely exchange with all peers (at negligible bandwidth cost). You would still depend on the server to replicate your encrypted stream (and do NAT traversal etc), but it wouldn't be able to peek inside.

A separate problem is that you usually want your server to actually create reencoded video of your stream for participants with bad internet. There's potentially some ways to do that without server involvement with some clever video encoding (so that instead of reencoding you can just throw away some chunks), but afaik there's nothing production ready for video codecs here.

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

#122

Post by PureParadigm » Mon, Apr 13, 2020, 10:53 PM UTC

crazygringo wrote: post #120

I'm actually really curious as to whether verifiable E2EE is possible in normal business videoconferencing -- if someone here can enlighten me I'd really appreciate it. It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandw…

> It seems clear that there has to be a single key, rather than separate keys for each pair of participants, since in a large meeting we need all video streams running through a server and everyone receiving the same streams, for manageable upload bandwidth.

Why is this the case? Watching streams on Twitch or YouTube with HTTPS are all encrypted individually for each connection. It's not like TV or radio where you have to broadcast the same thing to everyone.

> But therefore... as long as you're trusting the server with key distribution/management in the first place... don't you necessarily have to simply trust that the server isn't peeking?

I think you're right that you'll need to trust key distribution. Some companies might actually have PKI set up properly and can do this. Other individuals who are particularly privacy conscious may also have this. Just because verifiable E2EE might not be applicable to a mass market doesn't mean it's not incredibly useful for those who do need it.

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

#123

Post by PureParadigm » Mon, Apr 13, 2020, 11:05 PM UTC

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 have to access password when you enter it on their website/have it in the link? Nope! It looks like they're putting the password in an anchor fragment in the URL, which is not sent to the web server [1]. So all encryption/decryption is being done client side (and is therefore real end-to-end encryption).

Yes, it's possible the web server is sending you evil JavaScript that is extracting your password anyway, but at least that's something you can in principle check. For all end-to-end encryption to work, you have to know your client is not compromised.

[1] https://stackoverflow.com/a/3081862

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

#124

Post by TheCycoONE » Mon, Apr 13, 2020, 11:06 PM UTC

Arathorn wrote: post #118

fladd wrote: post #117

Earlier quoted context omitted.

Shipping next week in Riot "stable" already? Does that mean that also device verification will be functional by then? That would be fantastic (and also pretty impressive, given that it is unfortunately still entirely non-functional in the develop branch right now)!

Yeah, the hope is to ship in stable later this week. Verification should be working in develop as right now, if cross-signing is enabled (although it had a few regressions last week) - if not, please file bugs...

On Satuday a friend and I running our own synapse homeservers used Riot develop to set up cross signing and validate each other. On Monday we invited more friends who were on matrix.org to join us and ran into no end of trouble. In the end it seems like they ended up with plain old device signing. Was this regression, or a lack of support in matrix.org's homeservers?

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

#125

Post by appleflaxen » Mon, Apr 13, 2020, 11:37 PM UTC

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…

that is a really terrible anecdote to hear; I tried jitsi, love it, and want to support 8x8, but I don't want to fight with customer service when/if I decide to cancel.

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

#126

Post by dcposch » Mon, Apr 13, 2020, 11:50 PM UTC

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 that service returns. It can return code modified for me specifically, different from what any other user of that app is running. For traditional server side rendered web apps, this is normal and expected. SPAs often return identical app resources for every user, and all user specific data is later transmitted via API calls... but nothing in the web enforces this.

For decentralized or end-to-end encrypted apps, this is very bad. Most Ethereum apps today, for example, are used primarily via Metamask browser extension. Nothing stops an operator of such an app from just serving a different, malicious version to one specific user, based eg on IP. Such a compromise would be very hard to prove.

Similarly, Jitsi might like to give users confidence that they are running the same code as everyone else, and that the code is logged, versioned, and open to security analysis.

In principle, an approach similar to Certificate Transparency could provide this kind of assurance.

For this to really work well, they would also have to practice good dependency hygiene and ship unminified bundles.

--

This is an important web primitive that's currently missing. Do any browsers have a solution somewhere in the pipeline?

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

#127

Post by upofadown » Mon, Apr 13, 2020, 11:51 PM UTC

xiphias2 wrote: post #109

upofadown wrote: post #106

Earlier quoted context omitted.

Perhaps it would be more illuminating to say that E2EE is mostly pointless if you don't verify keys. Then all you have to do is encrypt on the network links to get the same level of security for a lot of these things that claim E2EE as they have the power to do trivial MITM.

The point is that instead of requiring end users to verify public keys, it's better UX to give them the ability if they want, but not require. I remember an email standard that sent public keys inside the emails, and the replies are encrypted with that public key. Sure, MITM is possible, but it's easy to detect, at the same time the UX is easy to scale to billions of people.

That's autocrypt. It is awesome and should be default on all email clients. As part of the autocrypt standard MITM is not detectable as that would just provide users with information they could do nothing about. Autocrypt is fine just as long as the users are made to understand that the privacy protection is a lot less than the protection they would get from a PGP key they actually got from someone directly. No UX in the world can overcome that incontrovertible fact.

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

#128

Post by fladd » Mon, Apr 13, 2020, 11:53 PM UTC

Arathorn wrote: post #118

fladd wrote: post #117

Earlier quoted context omitted.

Shipping next week in Riot "stable" already? Does that mean that also device verification will be functional by then? That would be fantastic (and also pretty impressive, given that it is unfortunately still entirely non-functional in the develop branch right now)!

Yeah, the hope is to ship in stable later this week. Verification should be working in develop as right now, if cross-signing is enabled (although it had a few regressions last week) - if not, please file bugs...

It is not working a all. I cannot verify a single one of my devices. With cross-signing enabled. It used to work just fine, and then one day there was a Riot update that broke everything. The issue seems to be known to you, though. Please see also my comment on the already open issue at https://github.com/vector-im/riot-web/issues/12959#issuecomm...

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

#129

Post by Arathorn » Mon, Apr 13, 2020, 11:58 PM UTC

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 (and you'll want to keep the secret evolving for forward secrecy, as amusing as it'd be for you to invite your sysadmin to a conference, only for him to go and decrypt the conversation prior to him joining to find out what you were saying before he came in...) - and this require key management to track who's who and who's trusted.

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

#130

Post by PureParadigm » Mon, Apr 13, 2020, 11:59 PM UTC

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…

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 auditor's web server to get the client (and you can do this because Jitsi can be self-hosted). So I think it just comes down to connecting to web servers run by people you trust, since HTTPS already takes care of integrity checking.