Is Jitsi Meet end-to-end encrypted?

[duasfl8r]

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

[garretwilson]

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.

Yes. Please.

I'm searching for the same thing, and I can only find this thread. Now I have to go parse through all the comments.

Will someone please put up an in-depth security FAQ for Jitsi?

[saghul]

We added a “Security” section to the README as a result of this conversation. Please give it a read. Happy to answer any questions!

[lrq3000]

A question: are the text messages in the chat encrypted from the clients to the server, or only audio/voice data is encrypted?

[saghul]

Yes they are encrypted, as they travel through HTTPS.

[CAPTCHA167902]

สวัสดี

ฉันให้การฝึกอบรมด้านความปลอดภัยและ Jitsi Meet เป็นเครื่องมือที่เรามักจะพูดถึงเมื่อพูดถึงทางเลือกอื่นใน Skype ฉันรู้ว่า "ปกติ" Jitsi คือ E2E แต่ฉันไม่สามารถหาได้ที่ Jitsi Meet docs หากเป็นจริงสำหรับ WebRTC เวอร์ชัน

ฉันสงสัยว่าข้อมูลนี้ (หรือการปฏิเสธ) สามารถรวมอยู่ในไฟล์ README ของ repo นี้ได้หรือไม่

ขอบคุณสำหรับการทำงานอย่างหนักของคุณ! คุณร็อค

ผมต้องการให้เราทำความเข้าใจใหม่ให้ดีกว่าเก่าที่มีอยู่ในตอนนี้ครับทุกๆท่าน ผมยินดีที่ได้ร่วมงานกับพวกคุณทั้งหลายครับ

[CAPTCHA167902]

เป็นว่าเราเข้าใจกันแล้วนะครับผม ขอช่วยอะไรหน่อยเถอะครับทุกๆท่านที่เคารพ

[CAPTCHA167902]

#7196

[damencho]

@CAPTCHA167902 https://jitsi.org/security/ There is a section "Does Jitsi support end-to-end encryption?"

[lrq3000]

That's actually an excellent link, it clarifies both the E2EE and analytics. I guess this page was updated recently because I do not recall these questions being clarified on the website a few months ago. Thank you for pointing it out @damencho

[newscloud]

I've been writing a comparison of Zoom, Signal and Jitsi this week ... and I find the information publicly available about Jitsi's use of WebRTC difficult to assess.

The "End to End Encryption" https://jitsi.org/blog/e2ee/ post isn't really end to end ... it's misleading. Even if an organization hosts a video bridge , it's not E2EE for the users.

Can you explain how WebRTC security used by Jitsi encrypts data transferred across the Internet, who issues these keys, what size are these keys and what algorithm(s) are used ? And essentially how secure are these packets?

[darkdragon-001]

As linked in the End to End Encryption post you mentioned, Insertable Streams feature is used which allows end-to-end encryption in addition to the WebRTC transport encryption.

[saghul]

The "End to End Encryption" https://jitsi.org/blog/e2ee/ post isn't really end to end ... it's misleading.

It's truly End To End. The server has no access to decrypt the media. I suggest you start by asking questions instead of making false statements to begin with. The reason why "read the source code" is the current best source for this is because it's very early stages and being worked on.

Can you explain how WebRTC security used by Jitsi encrypts data transferred across the Internet, who issues these keys, what size are these keys and what algorithm(s) are used ?

When using WebRTC you use the de-facto WebRTC encryption: DTLS-SRTP with ephemeral keys. With insertable streams we are able encrypt the payload that goes inside the DTLS-SRTP encrypted packets. Thus, when the video bridge decrypts the SRTP packets it won't be able to see the media, as it's encrypted using our encryptor with insertable streams.

Currently we use AES-GCM with 128 bit keys derived from a user supplied passphrase using PKDF2. This is bound to change as we are in the process of introducing per participant keys and use libolm's double ratchet for secure signalling of these keys.

[andreas1107]

This makes sense - great thread. So basically Jitsi meetings, even if one-to-one, are maybe end-to-end encrypted unless you switch on the experimental E2EE feature which is supported in only Chromium-based browsers and the Jitsi electron-based app.

IMO there is one amendment needed to https://jitsi.org/security/ (my emphasis):

Jitsi meetings in general operate in 2 ways: peer-to-peer (P2P) or via the Jitsi Videobridge (JVB). This is transparent to the user. P2P mode is only used for 1-to-1 meetings

The security page should make it clear that the connection is not necessarily E2E encrypted unless the exprimental feature is turned on with a password. It should be explicitly stated that this uncertainty remains even in calls with only two participants.

It should also be pointed out that the mode used in the call -- P2P offering E2E encryption or JVB offering link encryption only -- can change at any point during the call and that this change from E2E to link encryption (or vice versa) is not shown to the call participants as a user design feature.

And of course that the call participants can check what the status is at point in time by hovering over the three bars showing the quality of the connection - but that this status is only true for that moment and can change at any later point in time.

One question: Can different implementations of Jitsi (for example 8x8's own implementation) force/prefer the JVB mode? (I assume yes)

Especially the layman will come to Jitsi as it has a reputation of being "more private/secure", and the confusing wording on the security page will just reinforce this impression for good or bad. Don't get me wrong - I consider Jitsi to be the most secure way to have video calls on desktop (at least until Signal finally releases video calling on their desktop app).

So probably the wording should be amended.

Also, it would IMO makes sense to give background info on Jitsi owners 8x8 - a company partially funded by Blackrock - and the relationship/governance structures in place between 8x8 and the Jitsi team and Jitsi JVB, as well as what independent reviews of the code and infrastructure are in place (if any). Just to deter folks from having any thoughts around Jitsi potentially being a honeypot. :-)

Thank you for the great work!

[saghul]

I don't think we need to make such amendment. Of course a single sentence out of a longer article can be confusing. We are are not claiming to be E2EE in cases where we aren't.

Also, it would IMO makes sense to give background info on Jitsi owners 8x8 - a company partially funded by Blackrock - and the relationship/governance structures in place between 8x8 and the Jitsi team and Jitsi JVB, as well as what independent reviews of the code and infrastructure are in place (if any). Just to deter folks from having any thoughts around Jitsi potentially being a honeypot. :-)

I don't really know what you expect from these tangents.

I'm going to lock this issue since the current state of affairs is dramatically different than when it was first opened in 2015. Please open new issues henceforth.