I looked at Jitsi recently as I was thinking about self-hosting it (I have the bandwidth).
My concerns:
It seems to be based on XMPP and require an XMPP server. They offer a quick-start guide on configuring it however I am not sure how secure the default configuration is - I'm worried the quick start guide is about "get it working", not "make it secure" and I don't have XMPP knowledge nor the desire to learn a complicated protocol just to be able to run this securely.
Why does it need an XMPP server? I do not want nor care about XMPP and everyone will be joining via browsers anyway. As far as I'm concerned it's just one (very big) moving part that I don't want to be responsible for.
Overall it left a sour & sad taste in my mouth. There's no way I'm putting this thing on the public Internet; the attack surface seems too large and too many opportunities to screw it up.
Jitsi uses XMPP(prosody) for MUC- basically coordination and control of sessions. XMPP is not exposed directly to the user, they use a BOSH client abstraction to convert that to http. It is actually good design and scales well. we have scaled the bridge to 500 plus concurrent sessions without lot of production tuning in non P2P mode (generally harder more resource intensive).
This still means the outside world can interact with the XMPP server, correct?
If so then this is my concern - an XMPP server seems like a huge attack surface for the tiny bit of functionality Jitsi needs (I'm confident it's using less than 10% of the actual capabilities of the XMPP server, which means the rest of the code paths are mostly untested in this scenario and are ripe for abuse and potential exploits).
In your case, is this an internal server or is it open to the Internet?
It is authenticated, i.e. only logged in users have access. Prosody is well tested XMPP implementation and is used in many production application. meet.jit.si is unauthenticated deployment and many people use it.
I wouldn't call it a tiny bit of functionality, MUC and SFU are the two main components of any video conferencing solution. XMPP helps provide MUC capability, Jicofo is the component you can see the implementation here https://github.com/jitsi/jicofo
BOSH does not allow all operations available via XMPP standard, there are restrictions possible, to maintain security.
I too balked at the stack required to self host jitsi, it felt overly complicated for personal use.
But given the interest in video chat now and the sorry state of affairs of the ecosystem, I gave it another go this week. It still seems convoluted, but they provide a docker compose file to deal with all of those complexities. I used it and set a server up using docker compose within a few minutes.
As far as I can tell, the annoying thing of self hosting is going to be user management. Realistically you shouldn't allow guests to create meetings, and that means you need an ldap server if you want more than a couple of users.
You could use LDAP, but really the default configuration allows for Prosody commands, e.g. prosodyctl adduser user@example.com
What I did was set up a vanilla Jitsi Meet instance (on DigitalOcean) and then create a shared user / pass per room share with my team. Feel free to message me if you have any questions.
Jitsi grew out of Google's Jingle extensions to the Jabber protocol for voice and video calls. And WebRTC call initiation requires at least a custom solution for exchanging SDP messages. So if you don't want to have an XMPP server in your setup, you need another server to handle all that signaling.
My argument is that it would require less code (thus less potential bugs and vulnerabilities) to implement the SDP exchange. I'm suspecting that Jitsi only uses a tiny bit of the capabilities of the XMPP server which means most of it is there doing nothing besides being a potential liability.
My concerns:
It seems to be based on XMPP and require an XMPP server. They offer a quick-start guide on configuring it however I am not sure how secure the default configuration is - I'm worried the quick start guide is about "get it working", not "make it secure" and I don't have XMPP knowledge nor the desire to learn a complicated protocol just to be able to run this securely.
Why does it need an XMPP server? I do not want nor care about XMPP and everyone will be joining via browsers anyway. As far as I'm concerned it's just one (very big) moving part that I don't want to be responsible for.
Overall it left a sour & sad taste in my mouth. There's no way I'm putting this thing on the public Internet; the attack surface seems too large and too many opportunities to screw it up.