Jitsi video/voice meetings over TCP 443 with SSL inspection on client side

Many of our external users will be using a strict firewall and on top of that SSL inspection with IDP/IPS in order to monitor trafic going in to the clients. This in order to be able to block potential threats from
e.g external websites.

The signaling part client to jitsi web is not an issue, but the webRTC part is being blocked.

With Jitsi(webRTC) over TCP 443 over TURN this is a completely different trafic pattern and content. I believe I already have the answer to the questions, but I need it verified

Is there any config that can be done on the Jitsi(prosody, jvb, jicofo etc) side to allow for this kind of setup?

Or is this to be exepected due to the nature of webRTC framwork/encryption?

1 Like

You monitor traffic in to the clients ? but Jitsi-meet is an outgoing traffic. At no point is Coturn connecting to your workstations.
I have managed firewalls in the past and it’s always the same story since TLS has appeared; if your traffic is known of your firewall, it may intercept and examine TLS 1.2, but most of the time you have to turn off inspection or it breaks TLS handshake and nothing works. Your customer should understand that if they want their users to use Jitsi-meet, they have to connect to the server. If customer is using their own server, it should not be a problem. If they are using meet.jit.si, it’s a problem since it’s in the cloud and IP address is not fixed. But seriously if they are that paranoid, they should use their own server.


So basically what you are saying is to tell our external users to whitelist, disable intercept/inspect of SSL/TLS1.2, for our meeting service(Jitsi/webRTC based) specifically?

This was my conlclusion as well but wanted to be absolutley sure before we take the next step

That seems the only option. FYI the DTLS traffic seems to be going the way of the dodo in a future that is not immediate but with the general acceleration of computer history may not be so far (I’d say 2 years but it’s just a guess), after that, well, anything could happen vs firewalls. It’s a constant arm race between Google/IETF vs firewalls.