Skip to content

Instantly share code, notes, and snippets.

@obfusk

obfusk/jitsi.md

Last active May 23, 2020 03:55
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save obfusk/c8470c65bb5367df83e0af03a3147dc7 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save obfusk/c8470c65bb5367df83e0af03a3147dc7 to your computer and use it in GitHub Desktop.
Download ZIP
jitsi security
Raw
jitsi.md

Scanning the internet for jitsi servers is pretty trivial. If you run your own server without authentication:

  • Anyone can use your server.
  • Vanity URLs are not safe.

In other words: you have pretty much the same security problems as when using meet.jit.si (except it's slightly harder to find and you presumably don't have to worry about the current lack of e2ee -- assuming you trust your hosting provider -- since you control the server).

My recommendations:

  • Always use authentication on self-hosted servers unless you intend for them to be used by anyone (like meet.jit.si and other public servers).
  • Always use secure meeting names (thanks to #6754 there will now be a warning about insecure ones). Even when using a self-hosted server and authentication; unless you completely disable guest access.
  • Assume anyone can join (and "bomb" / spy on) your meeting if you've shared the URL publicly. passwords can help, but you need to share those with participants as well. A secure meeting name is essentially the same as a password. The exception is self-hosted servers with authentication and no guest access.
  • Use a new room name every time if you can.

Increased moderation/vetting/"waiting room" options (as @kousu mentioned) for public servers seem necessary if you want to be able to host "public" meetings. Such as allowing the moderator to decide who can be seen and speak. And kick someone out.

I think the current "stateless" model (where rooms are deleted when everyone has left and there are no "user accounts") makes sense for many public servers. It is reasonably secure if you only share the URL with the intended participants. Great for friends/family/work/classroom if you (can) make sure to only share the URL with the intended participants.

It does however make it very hard to prevent unwanted guests when the URL is public. Moderation can help, but you still need a way for moderators to "vet" participants. In some cases, requiring participants to use a name that is known by the moderator can help (e.g. in a classroom scenario), but does not provide any guarantees (since anyone can claim any name).

I think universities/schools should probably run their own servers and use LDAP to authenticate students (like my university's gitlab does). And disallow guest access. A public server that allows github authentication might also be nice. But someone will have to pay for that.

I don't think that you can have a "secure" meeting with a publicly shared URL on a public server without some form of authentication (i.e. account system).

Maybe we want something similar to how public IRC servers like freenode deal with moderation and accounts (nickserv) for meetings that are meant to be public (like IRC): allow anyone to participate, but make trolling harder. This would however need to be "stateful". Does anyone know if there are any public servers that have implemented something like this already?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment