Archivo del Autor: Alberto Gonzalez Iniesta

Instalar un servidor de videoconferencia libre, Jitsi Meet (II, Configuración de Prosody)

Una vez conocidos los componentes, veremos ahora la configuración de los mismos. Mi objetivo no es tanto dar unas instrucciones paso a paso, sino explicar que partes de la configuración sirven para qué propósito y qué opciones tenemos en función de las características que deseemos en nuestra instalación.

Prosody (autenticación de usuarios y componentes Jitsi)

Los paquetes Debian que proporciona el proyecto Jitsi crean un fichero de configuración con todo lo relacionado con Jitsi. Esto permite evitar cambios en el fichero principal y aislar la configuración propia de Jitsi de otra configuración que ya pudiéramos tener en Prosody. Entiendo, por tanto, que tendremos un fichero /etc/prosody/conf.avail/EXAMPLE.NET.cfg.lua y que habrá un enlace simbólico a este fichero desde /etc/prosody/conf.d/EXAMPLE.NET.cfg.lua. Donde EXAMPLE.NET será el dominio de nuestra instalación (p.e. meet.inittab.org).

La (falta de) autenticación de usuarios

Como ya hemos comentado, Prosody es el encargado de la autenticación de usuarios. Ésta se configura en un VirtualHost que llevará por nombre el mismo que nuestro dominio. El siguiente ejemplo permite la entrada de cualquier usuario en nuestro Jitsi Meet, es decir no realiza autenticación de usuarios:

VirtualHost "EXAMPLE.NET"
  authentication = "anonymous"
  ssl = {
    key = "/etc/prosody/certs/EXAMPLE.NET.key";
    certificate = "/etc/prosody/certs/EXAMPLE.NET.crt";
  }
  speakerstats_component = "speakerstats.EXAMPLE.NET"
  conference_duration_component = "conferenceduration.EXAMPLE.NET"
  modules_enabled = {
    "bosh";
    "pubsub";
    "ping";
    "speakerstats";
    "turncredentials";
    "conference_duration";
  }
  c2s_require_encryption = false

Antes de ver las opciones de autenticación, quería hacer dos puntualizaciones sobre la configuración creada por el paquete «jitsi-meet-prosody«. Éste genera una clave y certificado autofirmado (los que están en /etc/prosody/certs) y deshabilita la obligación de usar TLS en las conexiones de clientes (c2s_require_encryption = false). Aunque pueda parecer inseguro, la realidad es que nuestras credenciales ya viajan seguras por la conexión HTTPS con el servidor web. Si quisiéramos cubrir el tramo entre nuestro servidor web y Prosody, podríamos configurar un certificado válido, por ejemplo de Let’s Encrypt y activar (true) la opción c2s_require_encryption:

  ssl = {
    key = "/etc/letsencrypt/live/EXAMPLE.NET/fullchain.pem";
    certificate = "/etc/letsencrypt/live/EXAMPLE.NET/privkey.pem";
  }
  c2s_require_encryption = true

En posteriores artículos veremos como limitar el acceso a nuestra instancia de Jitsi Meet autenticando usuarios.

El siguiente bloque define un componente en Prosody para la creación de las salas/conferencias (muc: Multi User Conference) que usará Jitsi Meet:

Component "conference.EXAMPLE.NET" "muc"
  storage = "memory"
  modules_enabled = {
    "muc_meeting_id";
    "muc_domain_mapper";
  }
  admins = { "focus@auth.EXAMPLE.NET" }
  muc_room_locking = false
  muc_room_default_public_jids = true

En él vemos que focus@auth.EXAMPLE.NET, el usuario que usa Jicofo, será el administrador de las salas. Este bloque será modificado cuando usemos autenticación con «tokens» para gestionar los moderadores y participantes en las salas.

Otro bloque similar es el que usan los diferentes componentes de Jitsi Meet para comunicarse entre ellos (informar de que videobridges y jibris están disponibles y cual es su carga para que Jicofo decida en qué videobridge crear nuevas salas o qué Jibri se encargará de una petición nueva de grabación):

Component "internal.auth.EXAMPLE.NET" "muc"
  storage = "memory"
  modules_enabled = {
    "ping";
  }
  admins = { "focus@auth.EXAMPLE.NET" }
  muc_room_locking = false
  muc_room_default_public_jids = true

También vemos que el usuario de Jicofo es el administrador de este muc.
Los usuarios de los componentes de Jitsi Meet no se autentican en el dominio principal (EXAMPLE.NET) sino en uno propio (auth.EXAMPLE.NET). Esto permite que podamos cambiar la configuración de autenticación para los asistentes, en el dominio principal, sin afectar a la autenticación de los componentes, que se hace en el dominio auth.EXAMPLE.NET:

VirtualHost "auth.EXAMPLE.NET"
  ssl = {
    key = "/etc/prosody/certs/auth.EXAMPLE.NET.key";
    certificate = "/etc/prosody/certs/auth.EXAMPLE.NET.crt";
  }
  authentication = "internal_plain"

Una vez más vemos que los certificados usados para este VirtualHost son autofirmados y creados por la instalación del paquete «jitsi-meet-prosody«.
Si bien este dominio no tiene por qué existir en el DNS, y por tanto no disponer de un certificado válido, si será necesaria la propagación del certificado (en los directorios /usr/local/share/ca-certificates) a los servidores adicionales a éste que ejecuten videobridges, jibris o jigasi si queremos que verifiquen la identidad del servidor Prosody cuando se autentiquen en él. De otra manera tendremos que usar una opción en ellos para deshabilitar la comprobación de este certificado (TODO: aquí vendrá el enlace a esa opción cuando esté su artículo).

La autenticación en este VirtualHost, authentication = "internal_plain", se realiza de forma local por Prosody. Por este motivo los usuarios de los componentes deben ser dados de alta con la herramienta prosodyctl. Para los componentes instalados en el mismo servidor que Prosody, esto se hace automáticamente por la paquetería de Debian.
Pero si instalamos componentes en otros servidores deberemos hacerlo nosotros manualmente. Veamos como.

Prosody mantiene un directorio por cada VirtualHost que tiene autenticación "internal_plain", en nuestro caso (auth.EXAMPLE.NET) podemos verlo así:

# ls -s /var/lib/prosody/auth%2eEXAMPLE%2eNET/accounts/ -l
total 16
-rw-r----- 1 prosody prosody 40 Apr 27 18:37 focus.dat
-rw-r----- 1 prosody prosody 34 Apr 27 18:37 jvb.dat
-rw-r----- 1 prosody prosody 40 Apr 27 18:38 prometheus.dat

En el nombre del directorio (y en los ficheros que contenga) se codifican, en código porciento, los caracteres especiales como puntos o guiones. Por eso el nombre «feo» del directorio. Dentro de él vemos un fichero con cada usuario registrado en este VirtualHost. Para dar de alta un usuario, para un componente nuevo, usaremos el siguiente comando:

# prosodyctl register USUARIO auth.EXAMPLE.NET CLAVE

Queda alguna configuración más que comentar, para usuarios invitados cuando usemos autenticación de participantes, o para la autenticación especial de Jibris, pero la veremos más adelante.

Con este artículo espero que se entienda, más o menos, el papel de Prosody uniendo el resto de piezas y las posibilidades de «fortificarlo» más de querer ser extrictos con la seguridad. En el próximos artículos veremos la autenticación de usuarios mediante LDAP.

Aprovecho para recordaros que en el Playbook de Ansible de la UDIMA para Jitsi Meet todas las tareas de instalación y configuración están automatizadas y casi podríais ahorraros leer estos peñazos que escribo 🙂
$ exit

Instalar un servidor de videoconferencia libre, Jitsi Meet (I, la teoría)

Últimamente parece que las videoconferencias se han puesto de moda, como el papel higiénico. Y si bien hay muchas alternativas, la inmensa mayoría podrían no respetar tu privacidad y algunas tienen un historial de problemas de seguridad que asusta.

Por suerte hay una alternativa plenamente funcional y libre: Jitsi Meet.

No necesitas nada para usar Jitsi Meet*

* Salvo un navegador actual o su aplicación móvil/de escritorio

Si no tienes medios (servidor, ancho de banda, ganas de complicarte la vida), puedes usar su servicio público que funciona estupendamente. Es muy sencillo, simplemente dale un nombre a tu conferencia y pasa la URL resultante (por ejemplo: https://meet.jit.si/UnPingüino) a todos los participantes que quieras invitar.

Evita, eso sí, nombres fáciles o comunes («pepe», «prueba», «test») para la conferencia o puede que entre más gente de la que esperas, ya que las conferencias en el servidor público no limitan quien entra en ellas.

Pero si lo que quieres es no depender de terceros, controlar quien puede entrar en tus conferencias, o proteger tu privacidad, puedes instalar Jitsi Meet en un servidor propio. Y a eso es a lo que hemos venido.

Las piezas del puzzle

Nada es perfecto, y si en algo peca(ba) Jitsi Meet es en su documentación. Tal era la situación que salió un proyecto paralelo sólo para documentarlo: EasyJitsi
Os recomiendo echarle un ojo para tener más información.

Lo primero que debemos hacer antes de montar Jitsi Meet es entender que piezas lo componen y para que sirven cada una de ellas.

Prosody

Aunque no es parte del proyecto Jitsi, Prosody es una de las piezas más importantes de esta arquitectura. Se trata de un servidor XMPP. O en términos más claros; un servidor de mensajería instantánea.
XMPP es un grupo de protocolos que definen y permiten todas las características esperables en un servicio de mensajería: autenticación de usuarios, conversaciones con varios participantes (rooms/canales), envío de ficheros, … Es el protocolo sobre el que se construye Google Talk / Hangouts / Chat, aunque Google decidiera no usar el estándar para interoperar con otras implementaciones XMPP. Pero tranquilos, con más de 1.500 millones de usuarios de Gmail pronto tampoco tendrá que intercambiar correo con nadie que no sean ellos y podrá inventarse las extensiones que lo mejoren y liberen de viejos estándares. ¡Hala!, ya me despaché. Sigamos…

Prosody será el encargado de autenticar al resto de componentes de Jitsi Meet y, en caso de quererlo, a los usuarios que se conecten a nuestro servicio de Meet. Además gestiona la comunicación entre componentes y usuarios. Por ejemplo permitiendo que Jicofo sepa de la existencia de videobridges y Jibris en servicio.

Jicofo (Jitsi Conferenre Focus)

Es el encargado de dirigir la orquesta. Lleva el control de los recursos, decide en que videobridge se hospeda una conferencia (en función de la carga de los disponibles) o que Jibri será el que transmitirá (a Youtube, por ejemplo) o grabará la sala que lo así solicite.

Videobride

Es el encargado de recibir y hacer llegar los flujos de audio y vídeo a los participantes de una conferencia. Aunque en una conferencia de dos personas es posible que los vídeos vayan de un a otro participante directamente, sin mediar el videobridge, en cuanto los participantes son tres o más, todos envían su señal de vídeo al videobridge, que la repite al resto de participantes.

Este funcionamiento es además característica fundamental de Jitsi Meet. Los videobridge no mezclan vídeo, según llega de un cliente sale al resto. Eso se traduce en menos latencia, al no perder tiempo procesando vídeo, a costa de un uso alto (con muchos participantes) de ancho de banda. Por ejemplo, y dependiendo de la calidad que usemos, si tenemos 10 participantes, con la cámara abierta, enviando vídeo a 3Mbps, además de estar recibiendo 30Mbps estaría sacando unos 300Mbps de tráfico.

Jibri (Jitsi BRoadcasting Infrastructure)

Permite grabar, en disco o nube, o retransmitir a Youtube (por ahora) una sesión. Está compuesto por varios componentes: el propio Jibri que se conecta con prosody para recibir las órdenes de grabación de Jicofo, un navegador Chrome que se conecta como un usuario más a la sesión que grabará, y ffmpeg que se encarga de codificar el vídeo final.

Una característica a tener en cuenta de Jibri es que una sola instancia es capaz de grabar una sola sesión. Así que si quieres grabar más de una simultáneamente necesitarás tener más de un servidor/docker con Jibri.

Un servidor web y Jitsi Meet

Jitsi Meet, propiamente dicho, sería la parte frontal de todo el invento. Es una aplicación en Javascript que estará alojada en un servidor web. En el momento que escribo esto, nginx el servidor mejor soportado por Jitsi Meet para hacer este trabajo.

Otros componentes

Opcionalmente, en las últimas versiones, se puede instalar/configurar un servidor TURN/STUN para facilitar las comunicaciones de clientes detrás de NAT. De no hacerlo se pueden usar servidores públicos, en principio sin grandes compromisos (a mi entender) salvo la dependencia en la disponibilidad del servicio.

Jigasi es la última pieza del puzzle. Este componente permite integrar Jitsi Meet con una centralita de Voz IP. Ya sea para realizar llamadas desde una conferencia en curso (Meet ordena a Jigasi llamar) o para que participantes puedan unirse a una conferencia a través de una llamada telefónica (la centralita de Voz IP dirige las llamadas a Jigasi que las hace llegar a Jitsi Meet).

En la próxima entrega entraré en más detalle sobre la configuración de cada uno de ellos. Si os corre prisa echarlo a andar podéis usar su instalación docker, pegaros con sus paquetes, o probar el «playbook» de Ansible que la Universidad a Distancia de Madrid (UDIMA) ha publicado en su Github. Y sí, puede que yo tenga algo que ver con esto último 😛

Certificados SSL gratis

Hoy vengo a contaros que se pueden conseguir certificados SSL válidos en todos los navegadores, y sistemas operativos, por cero Euros. Aunque realmente lo que quiero contar es como ponerlo en marcha rápidamente, que es lo que espero no sepáis para que terminéis de leer esto 🙂

Let’s Encrypt lleva unos meses funcionando y posiblemente para cuando termine de escribir esta entrada ya habrán generado más de dos millones de certificados. Su objetivo no es acabar con la mafia y el timo de (la mayoría de) los certificados SSL de pago. Su propósito es el que tráfico de Internet viaje cifrado, para que al menos les cueste algo más de presupuesto espiarnos a todos aquellos que lo hacen.

No voy a entrar en detalle sobre el protocolo que desarrollaron (ACME), sólo comentaré las piezas que necesitamos conocer y espero que con un poco de copiar y pegar estéis funcionando en minutos.

Software

Existen varias implementaciones del «cliente ACME» necesario para gestionar la petición de certificados. De entre ellos yo elegí acme-tiny porque su código es sencillo de entender y no tiene apenas dependencias, básicamente Python y openssl. En su repositorio de github tenéis sus instrucciones de uso, muy fáciles de seguir, pero si lo queréis algo un poco más fácil he creado un pequeño script en shell, usa acme-tiny para funcionar y sólo requiere como argumento el nombre, o nombres, de dominio para los que solicitar el certificado.

También necesitaremos un servidor web, aunque el certificado SSL sea para un servidor de correo, XMPP, o lo que se os ocurra. Es necesario porque Let’s Encrypt hará una petición a nuestro servidor web para validar que el dominio del certificado solicitado es realmente nuestro. El funcionamiento a grandes rasgos es: El «cliente ACME» solicita un certificado a Let’s Encrypt, estos piden al cliente que ponga un fichero que pruebe que el dominio es nuestro (challenge) en el servidor web y posteriormente Let’s Encrypt pide al servidor web del dominio en cuestión el fichero acordado. Si el fichero está allí y es correcto, se entiende que el dominio está bajo nuestro control y el certificado se emite.

Configuración

Lo primero que necesitaremos (además de tener acme-tiny  (enlace para «wget-ear») y opcionalmente mi script (enlace para «wget-ear»)) es un directorio para guardar claves privadas y certificados. Para no ejecutar acme_tiny como root crearemos ese directorio con permisos de escritura para un usuario no privilegiado (no es buena idea usar alguno bajo el que se ejecute Apache/nginx o algún servicio), podemos usar nuestro propio usuario (en mi caso será «agi«). Ya que, en Debian, tenemos los directorios /etc/ssl/(private|certs), yo elegí /etc/ssl/letsencrypt:

# mkdir /etc/ssl/letsencrypt
# chown agi:ssl-cert /etc/ssl/letsencrypt
# chmod 750 /etc/ssl/letsencrypt

Bajaremos el certificado intermedio de Let’s Encrypt para que no de problemas la cadena de validación de nuestro certificado SSL. Lo dejaremos en el directorio creado:

# cd /etc/ssl/letsencrypt
# wget https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem

Crearemos una clave privada para establecer la comunicación con Let’s Encrypt:

# cd /etc/ssl/letsencrypt
# openssl genrsa 4096 > account.key
# chmod 600 account.key
# chown agi account.key

Ahora crearemos el directorio donde el «cliente ACME » dejará los ficheros de validación (challenge) y que el servidor web tendrá que devolver cuando Let’s Encrypt lo solicite:

# mkdir /var/www/letsencryptchallenges
# chown agi /var/www/letsencryptchallenges

Y configuraremos el servidor web para que sirva el contenido de ese directorio. Si tenemos un sólo dominio lo podemos hacer en la configuración es éste, y si tenemos varios configurar el directorio de forma global. A forma de ejemplo, esta sería la configuración para un servidor Apache:

Alias /.well-known/acme-challenge/ /var/www/letsencryptchallenges/
<Directory /var/www/letsencryptchallenges>
  Options None
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

Y esta para un servidor nginx:

location /.well-known/acme-challenge/ {
  alias /var/www/letsencryptchallenges/;
  try_files $uri =404;
}

Llegado este punto, si no vas a usar mi script deberías seguir las instrucciones de acme-tiny para crear un CSR (Petición de firma de certificado), instalar el certificado y programar una tarea periódica que lo renueve.

Si vas a usar mi script deberías repasar las variables de configuración que tiene al principio para ajustar los ficheros y directorios que usará (los comentados anteriormente). Si estás siguiendo literalmente los pasos que llevamos hasta ahora posiblemente sólo tendrás que cambiar el path al script acme_tiny.py (apuntar la variable ACME_TINY al path donde lo dejaras y no olvidar dar permisos de ejecución a ambos). Si ya has recargado la configuración del servidor web, para que se sirva correctamente el directorio de los ficheros challenge, sólo queda una cosa que hacer, pedir el nuevo certificado:

## Ejecutar con el usuario no privilegiado, no como root!
## Lo más sencillo es dejar new_cert en el PATH (p.e. /usr/local/bin)

$ new_cert midominio.com

## Si queremos un certificado para varios (sub)dominios podemos pasar todos
## como argumentos al script.
## IMPORTANTE: En este caso, asegúrate de que el servidor web devolverá
## el fichero challenge correctamente en todos ellos
$ new_cert midominio.com www.midominio.com eldominiodemiprimo.com

Si todo fue bien, deberíamos tener varios ficheros, que toman su nombre del primer dominio especificado en la llamada a new_cert, en el directorio de trabajo que usemos. Los importantes son: DOMINIO.key, la clave privada, y DOMINIO_chained.crt, el certificado solicitado con el certificado intermedio de Let’s Encrypt. Con ellos tendremos que configurar el virtual HTTPS de nuestros dominios. Ejemplo en Apache:

<VirtualHost *:443>
  ServerName DOMINIO
  SSLEngine on
  SSLCertificateFile /etc/ssl/letsencrypt/DOMINIO_chained.crt
  SSLCertificateKeyFile /etc/ssl/letsencrypt/DOMINIO.key
......
</VirtualHost>

Ejemplo en nginx:

server {
  listen 443;
  server_name DOMINIO;
  ssl on;
  ssl_certificate /etc/ssl/letsencrypt/DOMINIO_chained.crt;
  ssl_certificate_key /etc/ssl/letsencrypt/DOMINIO.key;
...
}

Existen varios parámetros (tanto en los servidores web mencionados como en otro tipo de servidores) para mejorar la seguridad y compatibilidad SSL. En el sitio github de acme_tiny mencionan algunos (para deshabilitar SSLv3 e inferiores y corregir posibles ataques conocidos), aunque yo soy fan de la herramienta de análisis (y  recomendaciones) de Qualys SSL Labs. Así que no os quedéis en instalar el certificado y darle un repaso a parametrización del SSL.

Mantenimiento

Los certificados de Let’s Encrypt, al menos en el momento que escribo estas líneas, tienen una vigencia de tres meses. Por ello es importante que preparemos un mecanismo automático de renovación. Que consiste en algo tan simple como una entrada de cron que solicite un nuevo certificado antes de que caduque el actual. En mi caso tengo un fichero en /etc/cron.d llamado local-letsencrypt (el prefijo local- me permite diferenciar los ficheros instalados por el gestor de paquetes de los creados por mi) con el siguiente contenido (y donde digo nginx, digo apache2, postfix, prosody, dovecot, …):

# Ajustar el nombre de usuario, el path a new_cert y el comando para recargar
# la configuración del servidor correspondiente (salvo que uséis nginx y systemd)
0 6 1 * * agi /usr/local/bin/new_cert DOMINIO(s) && sudo systemctl reload nginx

# Y no olvidéis permitir a vuestro usuario ejecutar ese comando con sudo en
# el /etc/sudoers:
agi ALL=NOPASSWD: /bin/systemctl reload nginx

## O sin depender de sudo (recomendación de Tincho):
0 6 1 * * root su -u agi -c "/usr/local/bin/new_cert DOMINIO(s)" && systemctl reload nginx

Cuidado con las cosas gratis

Para los que no se fían de las cosas gratis, les recomiendo que sigan los pasos anteriormente descritos y luego envíen 200 EUR a mi cuenta de Paypal. Una vez al año, por la renovación, claro. Les garantizo que sus  datos viajarán cifrados igualmente que con el certificado más caro de [insertar entidad certificadora aquí].

$ exit