Halfway through a phone conversation amid the doom and gloom of the global pandemic, someone complained about commercial online videoconferencing services creaking at the seams due to the massive increase in demand.

This led me to think about open source video conferencing options. After a little bit of reading, I discovered Jitsi [1], a truly impressive open source project for building and deploying secure videoconference services. Jitsi, courtesy of 8x8 Inc. [2], has an Apache2 license and includes Jitsi Meet [3], a free video conferencing platform, and Jitsi VideoBridge, a Selective Forwarding Unit (SFU) that powers multiperson videoconferencing. For an overview of the project, visit their website [4] or check out their GitHub page [5].

Jitsi offers secure and scalable videoconferences, either as a standalone app or embedded into your own web application. Jitsi has been around since 2003 in one incarnation or another, with continual fine tuning over recent years.

You do not need an account to start a video call with Jitsi, and it is very browser-friendly and mobile-compatible. Jitsi also allows screen sharing, voting with your hand, and online chat. In this article, I'll show you how to use Jitsi to create a fully encrypted, open source, free-to-use, videoconferencing service.

Getting Started

I'll walk you through what you need to get Jitsi up and running. Also, I'll assist in switching off as many network ports as possible so that you're only exposing the HTTPS port to the public, and I'll provide some fine-tuned firewall rules. To get an insight into all the features Jitsi offers, I will install the full suite of Jitsi software. You will be pleasantly surprised at how little the disk footprint is.

For my videoconferencing server, I'll use DigitalOcean [6], which refers to servers as "droplets." When creating the droplet, I'll ask the cloud platform to install Ubuntu 18.04 (Bionic Beaver) as it has a shelf life until April 2028. I'll assume that you can create a DigitalOcean account on your own. Setting up a droplet manually is easy – if you are new to DigitalOcean, visit their website for more information on setting up a droplet [7].

After logging in over SSH, run

apt update; apt upgrade -y

followed by a reboot to update the operating system software. After running the following command:

$ cat /etc/os-release

you will get the output shown in Listing 1, confirming that the server is running the correct Ubuntu version.

NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

The next trick is to install Apache2 (or NGINX if you prefer). During installation, Jitsu will figure out which web server you are using and then work via that server. Install the Apache2 web server with:

$ apt install apache2

After entering the droplet's IP address into a browser, you will see that Apache2 is running as expected (Figure 1).

Figure 1: Happiness is Apache2 serving HTML as expected.

Next, I'll follow the installation instructions from Jitsi's website [8].

To ensure that I'm connecting to the right repository, as the root user, I'll set up the key for the Jitsi repository with the following:

$ wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
OK

Then, I'll open up a file called /etc/apt/sources.list.d/jitsi-stable.list and save the following line to it:

deb https://download.jitsi.org stable/

After that, I'll do a quick update as shown in Listing 2.

$ apt update
Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Get:2 http://mirrors.digitalocean.com/ubuntu bionic InRelease [242 kB]
Get:3 https://download.jitsi.org stable/ InRelease [2415 B]
Hit:4 http://mirrors.digitalocean.com/ubuntu bionic-updates InRelease
Hit:5 http://mirrors.digitalocean.com/ubuntu bionic-backports InRelease
Get:6 https://download.jitsi.org stable/ Packages [36.4 kB]
Fetched 281 kB in 1s (363 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

As you can see from the output in Listing 2, the Jitsi repo has been connected to as hoped and accessed without complaint following the key that I installed.

Installing Jitsi

I'm now ready to install the videoconferencing suite, barring some firewall tweaking. The commands in Listing 3 install the full package.

$ apt install jitsi-meet
ca-certificates-java fontconfig-config fonts-dejavu-core java-common jicofo jitsi-meet jitsi-meet-prosody jitsi-meet-web jitsi-meet-web-config jitsi-videobridge libavahi-client3 libavahi-common-data libavahi-common3 libcups2 libfontconfig1 libjpeg-turbo8 libjpeg8 liblcms2-2 libnspr4 libnss3 libpcsclite1 libxi6 libxrender1 libxtst6 lua-bitop lua-event lua-expat lua-filesystem lua-sec lua-socket lua5.1 openjdk-8-jre-headless prosody x11-common

As expected, the installation involves a reasonably large number of files, but it only takes about 215MB of extra space on my server. You might notice that the x11-common package will be installed; usually this package wouldn't be used on a headless server driven by the command line. Consequently, you might want to have this server dedicated to Jitsi.

The jitsi-meet package installs the whole suite, which I will do to show all of Jitsi's features. You also can just install the individual components you need as follows:

$ apt install jitsi-videobridge
$ apt install jicofo
$ apt install jigasi

Upon launching the jitsi-meet package, you will be asked for a hostname. Choose a sensible one. Assuming you own a domain name, create a DNS name (an A record) for your server's IP address to save time later. I've chosen this hostname:

call.chrisbinnie.tld    IN    A   123.123.123.123

Enter your hostname in the pop-up box and then choose Generate a new self-signed certificate on the next screen. (You will get a chance later to obtain a Let's Encrypt certificate.)

At this stage, screeds of data are flying up the terminal as the Jitsi software runs through its installation. Listing 4 shows the tail end of the output without errors before returning you to a prompt.

Running hooks in /etc/ca-certificates/update.d...
done.
done.
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...

Next Jitsi will auto-configure a Let's Encrypt certificate for free and associate it with your hostname. You need to wait for your DNS to become available (if your DNS isn't ready, then just run it again when the DNS is available) to run a sophisticated Let's Encrypt script. To confirm that your DNS is live, run this redacted command:

$ host -v -t a call.chrisbinnie.tld
  ns1.nameserver.tld

and then run the Let's Encrypt script:

$ /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

In this brief process, you're prompted for an email address. Then, as if by magic, certificates are mysteriously installed, taking all the configuration pain away (Listing 5).

 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/call.chrisbinnie.tld/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/call.chrisbinnie.tld/privkey.pem
   Your cert will expire on 2020-06-22. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le
Configuring apache2

You can renew the certificate easily in the future by running the command again and look for the output as shown in Listing 5.

Firewall Rules

Your next step in to set up your firewall rules.

I won't lock down your SSH port to a specific IP address in this example, because I don't want you locked out mid-configuration. You can use iptables or even TCP Wrappers to lock down your SSH yourself. Once testing is finished, you also need to change the SSH port and harden your SSH daemon (if you wish).

In order to configure iptables from Netfilter, I'll first create a simple script, /root/iptables.sh (Listing 6), and then make it executable with the command

chmod +x /root/iptables.sh

01 # Clear old config first
02 iptables -P INPUT ACCEPT
03 iptables -P FORWARD ACCEPT
04 iptables -P OUTPUT ACCEPT
05 iptables -t nat -F
06 iptables -t mangle -F
07 iptables -F
08 iptables -X
09
10 # Drop inbound and forwarding but allow outbound
11 iptables -P INPUT DROP
12 iptables -P FORWARD DROP
13 iptables -P OUTPUT ACCEPT
14
15 # Allow localhost in/out
16 iptables -A INPUT -i lo -j ACCEPT
17 iptables -A OUTPUT -o lo -j ACCEPT
18
19 # Allow established traffic to flow
20 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
21
22 # Apparently Jitsi can use these ephemeral ports so allow them inbound
23 iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT
24
25 # Enable HTTPS access
26 iptables -A INPUT -p tcp --dport 443 -j ACCEPT
27
28 # Allow HTTP for Let's Encrypt temporarily
29 iptables -A INPUT -p tcp --dport 80 -j ACCEPT
30
31 # Change the default port in /etc/ssh/sshd_config from 22 after testing
32 iptables -A INPUT -p tcp --dport 2002 -j ACCEPT

so that I have a backup of my firewall rules.

These firewall rules are just an example, so you might need to adjust them according to your needs. You can always log in via the DigitalOcean console (in your browser) if you get stuck here and lose SSH access.

To run the script in Listing 6 enter:

$ /root/iptables.sh

To verify that the firewall rules are in place, use:

$ iptables -nvL

To make sure your custom iptables firewall rules persist after a reboot, install the very handy iptables-persistent package with:

$ apt install iptables-persistent

Then, choose yes to save IPv4 rules and select no for IPv6 rules as there aren't any. A quick reboot is needed to check that you can still get back into the server by SSH.

If I run the iptables -nvL command again to verify that the firewall rules have persisted, I will see the output displayed in Listing 7.

Chain INPUT (policy DROP 23 packets, 1768 bytes)
 pkts bytes target  prot opt in  out  source     destination
  174 24898 ACCEPT  all  --  lo  *    0.0.0.0/0  0.0.0.0/0
   65  7817 ACCEPT  all  --  *   *    0.0.0.0/0  0.0.0.0/0  ctstate RELATED,ESTABLISHED
    0     0 ACCEPT  udp  --  *   *    0.0.0.0/0  0.0.0.0/0  udp dpts:10000:20000
    0     0 ACCEPT  tcp  --  *   *    0.0.0.0/0  0.0.0.0/0  tcp dpt:443
    0     0 ACCEPT  tcp  --  *   *    0.0.0.0/0  0.0.0.0/0  tcp dpt:80
    4  1095 ACCEPT  tcp  --  *   *    0.0.0.0/0  0.0.0.0/0  tcp dpt:22
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target  prot opt in  out  source     destination
Chain OUTPUT (policy ACCEPT 62 packets, 9148 bytes)
 pkts bytes target  prot opt in  out  source     destination
  174 24898 ACCEPT  all  --  *   lo   0.0.0.0/0  0.0.0.0/0

In short, the rules in Listing 7 mean that outbound traffic is allowed. However, inbound traffic is only permitted if it's part of a conversation already taking place and HTTP is open (close this soon after you finish testing since the script leaves it open, but note that your LetsEncrypt certificate refreshes need this port open) as well as HTTPS and SSH ports (which you should lock down yourself and change the port number). UDP ports are also enabled for ephemeral connections in the 10000-20000 range (this may not be required).