Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upIs Jitsi Meet end-to-end encrypted? #409
Comments
This comment has been minimized.
This comment has been minimized.
Please, use our mailing lists for future questions: https://jitsi.org/lists
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. |
This comment has been minimized.
This comment has been minimized.
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.
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. |
This comment has been minimized.
This comment has been minimized.
@gasche apologies for not ptoviding enough information. Here is a more detailed answer:
|
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
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: |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Thanks @bgrozev That's what I thought but it's good to have confirmation. |
This comment has been minimized.
This comment has been minimized.
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) |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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). |
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.
This comment has been minimized.
This comment has been minimized.
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
WebRTC does not prevent e2e audio.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Thanks for the info guys. Where can I find more info on your implementation of PERC? This is something that really interests me. Cheers |
This comment has been minimized.
This comment has been minimized.
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 |
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.