Is Jitsi Meet end-to-end encrypted?

[lucastx]

Hi,

I give security trainings and Jitsi Meet is the tool we usually talk about when discussing alternatives to Skype. I know "normal" Jitsi is E2E but I can't find at Jitsi Meet docs if this is true for the WebRTC version.

I wonder if this information (or the denial of it) could be included at this repo's README file.

Thank you for your hard work! You rock.

[emcho]

Please, use our mailing lists for future questions: https://jitsi.org/lists

I know "normal" Jitsi is E2E but I can't find at Jitsi Meet docs
if this is true for the WebRTC version.

Depends on what you mean. Jitsi Meet is a client for Jitsi Videobridge, so all connections go through it. Jitsi Videobridge is something you install on your own premises so you do control the full end-to-end experience.

[gasche]

I find this answer a bit worrying. I'm a user of https://meet.jit.si/ and the question seems very simple and natural to me. Do the conversations that I'm having using Jitsi Meet travel in the clear over the internet? If not, can you explicitly point out who has access to them in clear form? (The two clients of course, but maybe also the Jitsi server itself? Anyone else?)

For example, is it reasonable to use Jitsi Meet from an untrusted wifi network? (For banking websites for example, the answer is often "it's not optimal but still reasonable because HTTPS" -- at least if your browser is decently configured.)

These are pretty basic questions and there should be a clear answer to them somewhere users can find: not having answers to the question is a usability bug. @emcho does not provide an answer to this question and just redirect to the list -- but we shouldn't have to send an email, or slog through mailing-list archives, to find answers to this question. When I google for "jitsi security", this github issue is the only clearly-relevant place that I find, and I think it would therefore be nice if there was a answer to this specific question here -- but I also think that the answer should be made more apparent in Jitsi Meet's documentation (which is relevant to this repository), and on the https://meet.jit.si/ website in particular.

Here are more details on "I can't find clear answers on the web". I know that the maintainers of this repository don't have responsibility or control over all the places I'm describing below, but on the other hand I don't know where I should report the sub-issues below, so any advice would be appreciated.

• Googling for "jitsi security" points to the Jitsi FAQ, that does not answer this question. (I understand that the faq is about Jitsi in general, not about Jitsi Meet in particular.). The only question with "security" in the question is § I have a few questions regarding ZRTP, SRTP and VoIP security in general. Where can I find some answers?, which points to the ZRTP FAQ which is (1) way too technical for casual users and (2) doesn't say anything about Jitsi Meet.
• The https://meet.jit.si/ website has an item related to security, namely "Secure Rooms", but it does not mention the security of the actual communication. I strongly think the website should clarify this aspect.
• the jitsi-meet github repository reminds in its README that Jitsi Meet is "Secure, Simple and Scalable", but not include any information on what "Secure" actually means. I think that the README should be clarified by providing an answer to this question: "who has access to my Jitsi Meet conversations?". (The answer may depend on the configuration of the Jitsi Meet instance; if so, please say so, but please also give an explicit answer for the http://meet.jit.si/ that is what a lot of casual users would use and is explicitly mentioned in the README.)
• Finally googling for "jitsi meet security" does point to a [jitsi-dev] conversation that seems to indicate that the https://meet.jit.si/ does not use end-to-end encryption, but that the stream is still encrypted from the clients to the server, and thus that you only need to trust the https://meet.jit.si/ server. (Some information on exactly who is running the server might be useful to assess if that is a choice users are willing to make.)

To summarize: other Jitsi users ending up on this issue from a web search, the short answer is "yes, https://meet.jit.si/ encrypts the communication, only the two clients and our server has access to them". Maintainers of Jitsi Meet-related information online: please add the question and answer in a place users can find them.

[emcho]

@gasche apologies for not ptoviding enough information. Here is a more detailed answer:

• WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption. (As a matter of fact, unless you consistently vocally compare DTLS fingerprints with your peers, the same goes for one-to-one calls)
• As a result: when talking on meet.jit.si your stream is encrypted on the network but decrypted on the machine that hosts the bridge.
• meet.jit.si is maintained by us: the Jitsi team at Atlassian
• most importantly: what I was trying to convey with my first answer was that meet.jit.si is just one instance of the Jitsi Meet app (which is what the question is about). You can therefore deploy your own version of Meet, on your own server and in that case your security guarantees will be roughly equivalent to that of an end-to-end encrypted call. This is what's unique to Jitsi Meet in terms of security.

[gasche]

Thanks for the thorough answer, and no need to apologize. I think it would be good if the various websites could provide it as well: is there something else I need to do to help make sure that this very useful information reaches the other users?

[TjWallas]

Bounce.

I have to say it was really a difficult journey to get here and find an answer to this question. Similar to what @gasche highlighted in his comment.

@emcho While I do agree that the Github issue tracker is no place to ask questions and that the mailing list is a better communication medium for that, I believe there still is room for this issue as an improvement to the information relayed through the website. This could also be a good opportunity to add this piece of information to the README or FAQ section of this repo (or Wiki).

Finally, for future users who end up here, I would like to further direct you to a good read on WebRTC security:
https://webrtc-security.github.io

[jerclarke]

Thanks for the thorough answer, and no need to apologize. I think it would be good if the various websites could provide it as well

FWIW as a tech lead for privacy-conscious NGO I echo the need for this information to be up front and easily findable by anyone encountering marketing claims that the system is secure. If you say it's secure, add a link to what you mean by that right next to the claim (or on the word "secure"), and make the explanation explicit.

If we want true privacy, we need to install it ourselves, but the hosted version is secure from a transmission perspective and only some serious infiltration (legal or technical) of your servers would result in exposure, so for most users meet.jit.si is likely to be acceptable. This is a decision that can only be made with the relevant information.

Maybe you don't need to apologize, but not because there isn't a problem. Rather than apologize, please fix the problem and make these distinctions clear with a document stating the security reality of Jitsi which is easily found by anyone.

FWIW this criticism isn't only for Jitsi of course, but for all "secure" and "private" apps, few of which adequately express the threat models they do and do not satisfy. Please be a leader in this regard, and raise the bar for us all!

Thanks for listening and apologies if my tone comes off as hostile. I'm really glad you make Jitsi Meet and run a public instance, both are wholesome and valuable public services ❤️

[pdarcos]

Hi,

@emcho wrote

WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption. (As a matter of fact, unless you consistently vocally compare DTLS fingerprints with your peers, the same goes for one-to-one calls)

Hmm, I'm a little confused now. I understand what Emil is saying, except I thought that 1to1 (if they can achieve p2p) calls through jitsi-meet are actually e2e encrypted. OK, you'd have to compare fingerprints of the certs to make sure there's no MITM but p2p calls are not decrypted server side, correct?

In other words, all traffic is decrypted server side except for p2p calls with 1 to 1 communication. Is this correct?

Thanks

[bgrozev]

Hmm, I'm a little confused now. I understand what Emil is saying, except I thought that 1to1 (if they can achieve p2p) calls through jitsi-meet are actually e2e encrypted

This is technically correct, but was not mentioned explicitly because unless a TURN server is deployed the p2p session will not always succeed and when this happens there isn't an explicit notification to the user. And also the switch from p2p to the bridge can happen without any user interaction (e.g. if a third participant joins, which could potentially happen if for example one of the two users reloads). In short, there are no guarantees that p2p will be used.

[pdarcos]

Thanks @bgrozev That's what I thought but it's good to have confirmation.

[jerclarke]

This is technically correct, but was not mentioned explicitly because unless a TURN server is deployed the p2p session will not always succeed and when this happens there isn't an explicit notification to the user. And also the switch from p2p to the bridge can happen without any user interaction (e.g. if a third participant joins, which could potentially happen if for example one of the two users reloads). In short, there are no guarantees that p2p will be used.

Is there/should there be a separate ticket about these missing user notifications? The app itself should send signals about the level of privacy whenever it changes, which would both help people who know the rules to apply them (i.e. stop saying private things when the state changes) and give hints to people who don't know the rules at how they work (i.e. The notification when the third person joins will train users inherently that more-than-two conversations are not e2e encrypted)

[bgrozev]

Personal opinion: this would trouble and confuse users with unnecessary notifications (note that the information is available in the "gsm bars" menu if one wishes to see it). It is also inherently unreliable: if the security provided by the bridge mode is not acceptable, then the potential to automatically downgrade to it (albeit with a notification) should also be unacceptable.

[bgrozev]

Note that the purpose of the p2p mode is not to provide additional security. It is to improve the connection quality (and reduce the traffic for the service provider), and for this use-case any notifications are an unnecessary burden for the user -- it should just be seamless (and has been intentionally designed this way).

[martinberg212]

WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption. (As a matter of fact, unless you consistently vocally compare DTLS fingerprints with your peers, the same goes for one-to-one calls)

This is simply a false statement. In fact the signal protocol allows just this, authenticated e2e group calls with DTLS while compliant with WebRTC.

Here is the description of one signal implemenation https://wire.com/en/security/

Quote

Voice and video calls use the WebRTC standard. More precisely, DTLS and KASE are used for key negotiation and authentication and SRTP is used for encrypted media transport. This means that voice calls are end-to-end encrypted with perfect forward secrecy enabled without compromising HD call quality.

WebRTC does not prevent e2e audio.

As a result: when talking on meet.jit.si your stream is encrypted on the network but decrypted on the machine that hosts the bridge.

This is kinda contradicting the statement from meet.jit.si about the communication being fully encrypted. Is this statement referring to transport encryption (https) only?

Please consider implementing e2e for conference calls if you take the security/confidentiallity of your users serious.

[damencho]

This is simply a false statement. In fact the signal protocol allows just this, authenticated e2e group calls with DTLS while compliant with WebRTC.
Here is the description of one signal implemenation https://wire.com/en/security/

You cannot apply this in use case of using SFU like the videobridge. This is when using a mesh connection which is not our case. We have a videobridge which significantly increases the number of people in a conference and adds intelligence in the middle compared to full mesh.

We had been working on PERC https://webrtcglossary.com/perc/ but that also needs to be implemented and by the browsers to be of any use.

Security is always a top priority. So if you do not trust meet.jit.si, everything is there to deploy your own instance and have control of the whole media path, that's why everything is open source.

[pdarcos]

Thanks for the info guys.

Where can I find more info on your implementation of PERC? This is something that really interests me.

Cheers

[bgrozev]

As damencho mentioned we are interested in doing e2e encrypted conferences, but it is much more difficult with an SFU-based system (and full-mesh just doesn't scale). Things like simulcast which require the SFU to change some more of the RTP header fields make it even harder. Our work on PERC was never complete, but you can read about it here (send me an email at boris at jitsi dot org if you want the full text): https://ieeexplore.ieee.org/document/8169752