Clarification on how encryption relates to LetsEncrypt certificates and a few other questions

Hi,
I recently installed a Jitsi Meet instance on a server (Debian 11 bullseye) of mine according to this guide. It was painless, but I’d like to confirm some things about call security.

Just to make sure I understand the basics here:

  1. Jitsi Meet video calls are encrypted by default via DTLS-SRTP, which is not(?) dependent on the turn server having access to the LE certs, and is browser-agnostic (meaning I don’t need to use chromium for its WebRTC capabilities to have encrypted calls).

  2. DTLS-SRTP is on by default for both one-on-one calls and calls with 3+ people, the difference being that with 3+ person calls the DTLS-SRTP layer is ‘stripped’ upon receipt by the bridge. I understand the packets themselves aren’t stored in anything other than live memory, but is a layer of DTLS-SRTP added once it leaves the bridge to the recipient(s)? Please correct me if I’m incorrect on any of the above points. Also, to make sure I’m getting my terminology correct, the videobridge is what I’m running on my server, correct?

  3. Assuming the above assumptions are correct, e2ee is overkill for my purposes, since I’m in control of the server running the videobridge.

So here are my questions:

Ideally I would like to at least have access to e2ee as an option; is it reliant on the LetsEncrypt certificates for the domain? If it is, is this script the way to fix the well-known permissions issue on Debian? I know just enough bash to have a vague understanding of what it’s doing, but would it change any LE certs other than the Meet instance? I’m running an nginx website on the same server.

Also, I’m getting an odd error when I test out calls:

Mar 09 22:14:20 domain.com turnserver[1525]: 2135: : ERROR: A peer IP x.x.x.x denied in the range: 10.0.0.0-10.255.255.255
Mar 09 22:14:20 domain.com turnserver[1525]: 2135: : ERROR: A peer IP x.x.x.x denied in the range: 192.168.0.0-192.168.25
5.255                                                                                                                               
Mar 09 22:14:20 domain.com turnserver[1525]: 2135: : ERROR: A peer IP x.x.x.x denied in the range: 192.168.0.0-192.168.25
5.255

Those block ranges seem pretty wide, and the calls were working more or less fine even when I was testing them on my laptop (with a vpn), my desktop, and my phone. If the IPs are blocked, how are the calls getting through?

Lastly, thanks for making such a cool tool. I was pretty excited to see an open-source and somewhat-free video chat service, and I’m very impressed with it so far.

yes

The videobridge aka JVB is running on your server, with Prosody the exchange server, Jicofo the orchestrator, and a bunch of Javascript that is just distributed to the clients and is doing an essential part of the Jitsi-meet job on the clients - ah and don’t fotget the Turn server to workaround pesky firewalls.

e2ee is appropriate for a single purpose, users that need ultra secure meetings and it’s thinkable that bad operators could subvert server operators to setup probes that could spy on exchanges without the server manager being the wiser. It’s not a likely scenario except for users having powerful opponents (with resources at a state level). If by ‘being in control of the server’ means that the server is physically at a place you control, it’s exceedingly unlikely. I can only think of one organization with the resources to do that.

Not Let’sEncrypt, but valid certificates (Let’sEncrypt or other) yes since certs are used to encryptr all http exchanges including the chat.

well, that’s your responsability to manage it then. The script is just copying the certificates at the right place for coturn, so it’s not likely to break anything. Jitsi-meet by itself (not coturn) is using the certs at their default location, so if your other sites are doing the same there should be no conflict.

Your coturn server is not working because you are using a private IP address and this is blocked by default Coturn confguration. It’s a security measure else Coturn can be used to access unwanted resources.
It should be removed only if you are sure that no firewall is needed at all on your private IP range, and everything is secured.
If not, you have to use the public IP address to connect to Coturn (that is, for the Coturn process, the server name that is given to clients in the Prosody configuration resolves to a public IP address). If it does not work (may need hairpinning on the network config), Coturn may not work at all - as it seems that you use your server without it, it may not be a real problem. If it is, a possibility could be to run Coturn in a container and use an internal firewall.

Thanks for the responses.

Your coturn server is not working because you are using a private IP address and this is blocked by default Coturn confguration

That’s odd. I don’t know much networking beyond setting up a pihole, but aren’t IP addresses in that range primarily local addresses? I’m a little confused as to how I could be using a local address if the VPS is in another country.

I can’t do a remote diagnostic of your network, all I can say is that it’s the exact error message, and it’s even giving you the range: 192.168.0.0-192.168.255.255: it is a private address range.

I wasn’t asking for one, only input. I’ll look into it.

By default, browsers will try all local addresses + discovered public addresses as ICE candidates, because they don’t know if maybe the other peer (i.e. the other user in P2P, or the JVB), or the TURN server, or both, is on the same internal network as them.

So if your logging level is high enough you can end up seeing internal addresses of the user’s networks in the logs on JVB and/or TURN server when those candidates are attempted. If there’s no routing between user and JVB/TURN server for that internal range then those candidates will just fail and others, which are routable, will succeed; that is normal behaviour.

The TURN server default config has rules to block all RFC1918 ranges to prevent anyone from using the TURN server as a relay to a private network that might exist ‘behind’ the TURN server, so if browsers try to set up relay candidates using private IPs, you will see those errors in the logs.