Edit: Thanks to Don Barry for pointing out the WebRTC security issues described below. (2018-04)
Jitsi is a libre software (LGPL license) allowing encrypted instant messages (OTR protocol) and voice/video conferences (ZRTP protocol). It runs on most common operating systems. It is compatible with several instant messaging and voice/video call protocols, including (among others) SIP and XMPP.
While strictly speaking this is not a limitation of Jitsi itself, encrypted video calls may be in practice problematic with most protocol providers. Jitsi recommends an ippi SIP account (compatible with ZRTP encryption). Alternatively, the WebRTC based Jitsi Meet–also libre software, Apache License–is a remarkable solution. Privacy is of primary importance to the project, and the software was used, e.g., to communicate with Edward Snowden during the Libre Planet 2016 keynote.
Jitsi should be installed through the package management software of the given distribution (apt, yum, pacman, ...). For Debian, at the time of writing (December 2016) Jitsi is only available on the Unstable repositories, where it seems to have broken dependencies. The procedure below shows how to install it on Debian Stretch (currently the Testing distribution) using the packages provided on Jitsi repositories.
| On this page: |
The official documentation provide informations about Jitsi client installation on Debian. The user is confusingly directed towards a repository containing several packages. Those packages are suggested to be installed before adding Jitsi's repository to avoid a GPG error.
Jitsi client packages are those named in the form jitsi_2.8.5426-1_amd64.deb, where the version 2.8.5426-1 can vary and the architecture amd64 should be chosen as appropriate. First, verify that the required dependencies are already installed: dpkg -I jitsi_2.8.5426-1_amd64.deb. Then, try to install the package. I got an installation error that left a broken package to be removed. A workaround is to download the RPM package and to convert it to a Debian package with the alien program:
$ sudo apt install alien
$ wget https://download.jitsi.org/jitsi/rpm/jitsi-2.8-5426.x86_64.rpm
$ fakeroot alien --to-deb jitsi-2.8-5426.x86_64.rpm
Install the generated deb package:
$ sudo dpkg -i jitsi_2.8-5427_amd64.deb
If there is no error, Jitsi can be launched:
$ jitsi &
An `ICE failed' error may suggest that the protocol provider does not support encryption. The FAQ page, recommends using an ippi account.
While on a secure chat with both ends authenticated through a Google Talk account, some instant message arrived unencrypted if, besides Jitsi, also the Google Talk Firefox plug-in was running at the same time. This is potentially compromising and would deserve more investigation. However, when Jitsi was the only active client on my desktop, the messages always arrived encrypted. Hence, as a general rule, while a secure chat is active it is advisable to close all Google Talk clients other than Jitsi. Of course, Google Talk should be avoided, too. Several other XMPP providers are more reliable for privacy, security and user's freedom.
An instance of Jitsi Meet is also provided at https://meet.jit.si/. No installation nor account registration is required (if using Debian Iceweasel browser, note that Jitsi Meet needs version ≥ 40). It is based on the WebRTC protocol and allows many functionalities, among which conference video calls, instant messaging, screen sharing, document sharing (Etherpad) and live streaming. More information about how to configure a new Jitsi Meet instance on a server can be found at the project webpage.
It is a great solution to invite people to video call through a libre, secure and performing software, the only requirement being a browser supporting the WebRTC protocol such as Firefox, Chromium or Opera.
Jitsi Meet (as compared to Jitsi standalone) relies entirely on WebRTC security, which provides no independent mechanism to guard against man in the middle attacks (MITM). As a result, at the design level Jitsi still remains significantly more trustworthy with its ZRTP verification of the negotiated keys. Of course, either might have implementation bugs that would allow attackers of various levels of stream access to break security.
Recent enhancements to the WebRTC spec provide the option of an "identity provider" to detect MITM, but these themselves rely on central authorities and certificates, meaning that privileged state actors still have ways in.
Ref: jitsi github, jitsi docs