Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is Jitsi Meet end-to-end encrypted? #409

Closed
lucastx opened this issue Nov 16, 2015 · 30 comments
Closed

Is Jitsi Meet end-to-end encrypted? #409

lucastx opened this issue Nov 16, 2015 · 30 comments

Comments

@lucastx
Copy link

@lucastx lucastx commented Nov 16, 2015

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
Copy link
Member

@emcho emcho commented Nov 16, 2015

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.

@emcho emcho closed this Nov 16, 2015
@gasche
Copy link

@gasche gasche commented Nov 15, 2016

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
Copy link
Member

@emcho emcho commented Nov 15, 2016

@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
Copy link

@gasche gasche commented Nov 15, 2016

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
Copy link

@TjWallas TjWallas commented Mar 19, 2017

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
Copy link

@jerclarke jerclarke commented Dec 18, 2017

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
Copy link

@pdarcos pdarcos commented Jan 4, 2018

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
Copy link
Member

@bgrozev bgrozev commented Jan 4, 2018

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
Copy link

@pdarcos pdarcos commented Jan 4, 2018

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

@jerclarke
Copy link

@jerclarke jerclarke commented Jan 4, 2018

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
Copy link
Member

@bgrozev bgrozev commented Jan 4, 2018

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
Copy link
Member

@bgrozev bgrozev commented Jan 4, 2018

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).

guusdk pushed a commit to guusdk/jitsi-meet that referenced this issue Apr 5, 2018
sowelisuwi added a commit to prism-break/prism-break that referenced this issue Jan 15, 2019
This reverts commit b7fb1be.

See: jitsi/jitsi-meet#409

Since that's inferior to other entries (like Ring), it doesn't
appear to make sense to include Jitsi Meet at the moment.
@martinberg212
Copy link

@martinberg212 martinberg212 commented Jul 21, 2019

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
Copy link
Member

@damencho damencho commented Jul 22, 2019

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
Copy link

@pdarcos pdarcos commented Jul 24, 2019

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
Copy link
Member

@bgrozev bgrozev commented Jul 24, 2019

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
Copy link

@garretwilson garretwilson commented Feb 3, 2020

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
Copy link
Member

@saghul saghul commented Feb 3, 2020

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
Copy link

@lrq3000 lrq3000 commented Feb 20, 2020

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

@saghul
Copy link
Member

@saghul saghul commented Feb 20, 2020

Yes they are encrypted, as they travel through HTTPS.

@CAPTCHA167902
Copy link

@CAPTCHA167902 CAPTCHA167902 commented Jun 29, 2020

สวัสดี

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

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

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

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

@CAPTCHA167902
Copy link

@CAPTCHA167902 CAPTCHA167902 commented Jun 29, 2020

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

@CAPTCHA167902
Copy link

@CAPTCHA167902 CAPTCHA167902 commented Jun 29, 2020

@damencho
Copy link
Member

@damencho damencho commented Jun 29, 2020

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

@lrq3000
Copy link

@lrq3000 lrq3000 commented Jun 29, 2020

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
Copy link

@newscloud newscloud commented Jul 2, 2020

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
Copy link

@darkdragon-001 darkdragon-001 commented Jul 2, 2020

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
Copy link
Member

@saghul saghul commented Jul 2, 2020

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.

@andreasmjg
Copy link

@andreasmjg andreasmjg commented Jul 30, 2020

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
Copy link
Member

@saghul saghul commented Jul 30, 2020

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.

@jitsi jitsi locked as resolved and limited conversation to collaborators Jul 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests