P2P, but still calling home

We have configured jitsi-meet to properly work in P2P mode when it is only 2 parties interacting. In the status of the meeting provided by jitsi meet’s green connection diagnosis button, we can see that a p2p connection has successfully been established. So far so good.

But when checking in chrome:webrtc-internals, we can see that there is still a connection held by both to our conferencing server, sending some smaller amount of data. Our data protection guy said, that this is not allowed to get certification. So the question is how can we disable this calling home during a p2p session?

Alternatively, it would also suffice if we could prove that no audio/video/chat data is being sent along that route via the conferencing server during the p2p session. Is that maybe easier to achieve?

Any help / hint highly appreciated :slight_smile:

The data you’re seeing in P2P mode is likely websocket information being shared. Websocket information is what’s displayed as connection stats on the participants’ videos.

Ok, so I guess that’s something we don’t really want to disable (but can it be disabled?) - and how could I prove that this is only these connection stats shared via websocket?

You can open the Developer tool, Network tab before joining the conference in the tab then, you can see the websocket being established and all messages that are being exchanged.
Mind that chat always goes through xmpp server.

You can’t.

We have that connection in case any other participant joins, since we then migrate to it. It’s not used while In P2P, it just contains keeepalive data.

Here’s the Network tab in your developer console showing websocket exchange

Screen Shot 2022-03-28 at 5.42.37 PM

Thanks for all your valuable input so far! I’ll need to reproduce it myself, but your explanations make perfectly sense. @damencho so I guess to guarantee that all personal communcation is via P2P, we would need to disable the chat feature. Is that right?


Just mind that p2p connection is not always possible, and to make it always possible you need a turn server where the media will be relayed through turn server. And if the p2p connection does not succeed it will fallback to use the jitsi-videobridge.

So if you want to guarantee p2p connection, make sure that you don’t have a turnserver and the bridge’s udp port 10000 is blocked, and make sure that you are ok with the fact that the connection between users will not be always established.

A few observations:

  1. JM is not certified to be secure from compromised server and it can’t be. When you control the code distributed to clients, you control everything. Not exchanging media data through the server don’t mean so much. Signaling, exchange setup is done through the server too and you can’t change that. IMO a truly certifiable 2 ways exchange can only be done with a 100% client solution (like the old Jitsi desktop, but with certified and verifiable builds), the client app used by some server solution may be valuable from some point of view but don’t bring anything from this point of view.

  2. There have been one post on this forum complaining that at some random time, JM was promoting P2P to 2 workstations exchanging with Jvb. I’m way too lazy to search it for you, sorry. Possibly it was caused by bad network conditions causing redirections to Jvb (Udp connections are better in bad network conditions)

  3. with this setup you can’t use Jibri to record. If you want recording, you have to setup it at one of the exchanging workstations (and the other part of the exchange will not made aware of it by the platform of course).

End-toEnd Encryption solves that.

the (unofficial) document linked in this post is not so optimistic. Has there been any major change ?

I wrote that document. What is not so optimistic about it?

(p 7, comparaison with other products, skipping quotes about these products as this is off-topic here)

Protecting against insiders is likely tre trickiest of all three vectors as the tools
that exist to verify authenticity are provided by the very same insiders (a very
common case in today's world of cloud distribution for software). In order to
authenticate a meeting, participants therefore need to be able to verify the tools
In the case of (...) Jitsi, all source code is available to auditors, however
actual audits themselves are rarely public and when they are, they are rarely
being re-run for every new version of the product.

the doc states the obvious: the protection against malicious insiders is limited to insiders that control the inside network but not the servers themselves. It’s a very limited attack. If the malicious agent is already inside a hoster, well, it’s unlikely the attack will be limited to the network. Unless it’s a legal intrusion and the general situation can be viewed as a state of rights. In this case there is not much to fear anyway.

The question was a bout the JVB. E2EE protects against a JVB compromise.

if the JVB is in the same location as the rest of the system, it’s not much reassuring. In the context of the OP, it’s rather unlikely that a P2P limited system has a setup like meet.jit.si. The bandwidth requirements are not the same at all. And a JVB compromised has login into the Xmpp server anyway.

That’s a lot to assume.

That does not allow it to tamper with the Olm session messages.

Requirements for separate JVB are the polar opposite of a secure server. You separate JVB to setup a scalable system to host big events at some points of time and most of the time you don’t have much traffic.
Big events != highly secure in my view. To hold highly confidential meetings, you need the opposite.
Ideally it would be a in-house server with only 1-1 meetings, or maybe a few meetings with more users but they must be trusted and as such very restricted.
If you hold a meeting with 30 users there is not much point to setup E2EE as I think even E. Ivov has acknolewdged, at least one of them with leak (probably more than half in real life), and that’s why it does not make sense to raise the limit of 20 users for E2EE.

In a secure server, there is not much use for bandwidth, and so for scalable JVBs. It’s easier to secure the whole setup and trust it.

Point is that having an open port and login right into a system allows hunting for priv escalation, that’s some price to pay for E2EE.

Again, assumptions. If you have a k8s cluster you may not even know where the JVB will end up running, and it doesn’t matter.

What are you talking about? That can be said about anything exposed to the Internet then. The JVB will connect to Prosody securely over XMPP and it has a prosody account, not any kind of super-power.

I think we are splitting hairs at this point.

I think this whole thread is a fool’s errand. You simply can’t guarantee that no media will ever go through the JVB because we need it to be there for the call.

There are other solutions for pure P2P (well, as pure as it can get, since at one point you’ll need TURN, not to mention saying “it’s P2P” without comparing certificate fingerprints is pointless) which are likely better suited for the OPs use case.