Ir al contenido

Servicio propio de comunicación segura con Matrix y Jitsi

Elección del nombre del servidor

Contents

Matrix es un estándar abierto para la comunicación descentralizada, que distribuye de forma segura las salas de chat persistentes sobre una federación abierta de servidores, evitando cualquier punto único de control o fallo. Propiciamos su utilización sustituyendo servicios más anticuados y de código cerrado.

En este artículo vamos a desplegar Matrix Synapse con Nginx como proxy reverso en Debian 10.

Matrix es un protocolo y una red abiertos para la comunicación descentralizada, respaldados por un estándar abierto e implementaciones de referencia de código abierto para servidores, clientes, SDKs de clientes, puentes, bots y más. Ofrece todas las características que se pueden esperar de un sistema de chat moderno: retroceso infinito, transferencia de archivos, notificaciones de escritura, recibos de lectura, presencia, búsqueda, notificaciones push, stickers, llamadas y conferencias VoIP, etc. Incluso proporciona encriptación de extremo a extremo (basada en el algoritmo de doble trinquete de Signal) para cuando quieras algo de privacidad.

Además, Matrix soporta de forma nativa puentes a otros protocolos, como Telegram y WhatsApp. Esto significa que puedes usar un cliente Matrix para unirte y usar grupos T/W como si fueran salas Matrix.

Synapse es la implementación de referencia de Matrix de un “servidor doméstico” escrito por el equipo de desarrollo del núcleo de Matrix. Está pensado como un escaparate del concepto Matrix para demostrar la especificación en el contexto de una base de código.

Los servidores domésticos se utilizan como punto de acceso para que los clientes se conecten a la red de Matrix. Almacenan el historial de chat personal de los usuarios y la información de la cuenta de forma similar a como lo haría un servidor IMAP/SMTP. Al igual que el correo electrónico, podemos ejecutar un servidor doméstico propio de Matrix para mantener el control personal y la propiedad de sus comunicaciones e historial. Matrix no tiene un único punto de control ni un proveedor de servicios obligatorio.

Registros DNS

Es recomendable utilizar subdominios separados para los distintos servicios como medida de higiene, y para que los ataques de scripting entre sitios sean menos efectivos. En este ejemplo, configuramos los DNS para:

    • matrix.dominio.edu.ar (Synapse, y para alojar una ruta .well-known para publicitar el servicio Matrix)
    • element.dominio.edu.ar (Element/Web)
    • jitsi.dominio.edu.ar (Jitsi vídeo conferencia)

Cuando se utiliza un subdominio se recomienda hacer un registro SRV que apunte al subdominio de matrix:

 _matrix._tcp.dominio.edu.ar 3600 IN SRV 10 0 8448 matrix.dominio.edu.ar

Prerequisitos

apt-get install build-essential python3-dev libffi-dev \
  python-pip python-setuptools libssl-dev \
  python-virtualenv libjpeg-dev libxslt1-dev
Es importante elegir el nombre del servidor antes de instalar Synapse, ya que no puede ser cambiado más tarde.

El nombre del servidor determina la parte del “dominio” de los identificadores de usuario de nuestro servidor: todos ellos tendrán el formato @usuario:dominio.edu.ar. También determina cómo otros servidores Matrix llegarán al nuestro para la federación.

Para una configuración de prueba podemos definir esto en el nombre de host del servidor. Para una configuración más preparada para la producción, se recomienda especificar el dominio (dominio.edu.ar) en lugar de un nombre de host específico de Matrix (de la misma manera que nuestra dirección de correo electrónico es probablemente usuario@dominio.edu.ar en lugar de usuario@correo.dominio.edu.ar) – pero hacerlo puede requerir una configuración más avanzada.

Configurar la federación

La federación es el proceso por el cual los usuarios de diferentes servidores pueden participar en la misma sala. Para que esto funcione, esos otros servidores deben poder contactar al nuestro para enviar mensajes.

El server_name configurado en el archivo de configuración de Synapse (a menudo homeserver.yaml) define cómo se identificarán los recursos (usuarios, salas, etc.) (por ejemplo: @usuario:dominio.edu.ar, #sala:dominio.edu.ar). Por omisión, también es el dominio que otros servidores utilizarán para intentar alcanzar nuestro servidor (a través del puerto 8448). Esto es fácil de configurar y funcionará siempre que configuremoss el nombre del servidor para que coincida con el nombre de host DNS público de la máquina.

Para que esta configuración funcione, habrá que escuchar las conexiones TLS en el puerto 8448. La forma preferida de hacerlo es utilizando un proxy reverso.

Si bien hay paquetes oficiales en los repositorios, los documentos de matrix-synapse recomiendan usar sus propios paquetes. Para ello, primero habilitamor esos paquetes, añadiendo la clave GPG y el repositorio de matrix-synapse:

apt install -y lsb-release wget apt-transport-https
wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/matrix-org.list
apt update
apt install matrix-synapse-py3

En caso de problemas con la instalación del servidor Synapse, Matrix ha descrito algunos consejos útiles para la resolución de problemas en la página web de Synapse en GitHub.

Durante la instalación, introducimos el dominio elegido como nombre del servidor. Se debe tener en cuenta que el nombre no puede cambiarse posteriormente sin reinstalar el servidor. También, indicamos si vamos a permitir que Synapse reporte estadísticas de datos anónimos o no.

Una vez que todo está instalado, iniciamos el servidor matrix-synapse, y lo habilitamos para que se inicie automáticamente al arrancar el sistema.

systemctl start matrix-synapse
systemctl enable matrix-synapse

Antes de poder iniciar Synapse, necesitamos generar un archivo de configuración que defina los ajustes del servidor.

En primer lugar, es necesario generar a una cadena aleatoria que se emplea como secreto de registro de Matrix Synapse. Esto lo hacemos usando el siguiente comando.

cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1

Copiamos y guardamos la clave generada para utilizarla luego.

rgzzglba4KiJo5qIMcAUu3eEWsMtV8wu

Luego editamos el archivo de configuración homeserver.yaml, que se encuentra en el directorio /etc/matrix-synapse.

nano /etc/matrix-synapse/homeserver.yaml

Buscamos la entrada registration_shared_secret y la modificamos con la clave aleatoria generada anteriormente. Resulta importante notar que la clave debe ir entre comillas dobles.

registration_shared_secret: "YC9h8djIiCaCinWxkE2zt9cgvXYGX25P"

Guardamos y cerramos el archivo homeserver.yaml.

Para aplicar la nueva configuración. reiniciamos el servicio matrix-synapse.

systemctl restart matrix-synapse
Dado que en en un artículo anterior abordamos la instalación de jitsi detrás de un proxy reverso utilizaremos el mismo esquema de base. Es decir nuestro proxy reverso gestionará certificados y hará los reenvíos hacia matrix y element.

Vamos a cambiar la configuración predeterminada del servidor para que sólo escuche la dirección localhost en el puerto 8008 editamos el archivo homeserver.yaml.

nano /etc/matrix-synapse/homeserver.yaml

En el siguiente segmento y definimos la dirección de escucha a 127.0.0.1 y comprobamos que la bandera de reenvío está establecida en true como se muestra a continuación. El resto se puede dejar como está, definimos que el SSL termina en el proxy para que Matrix no tenga que preocuparse por la configuración de TLS.

  - port: 8008
    tls: false
    bind_addresses: ['127.0.0.1']
    type: http
    x_forwarded: true

Guardamos y cerramos el archivo.

A continuación, habilitamos nginx para que actúe como proxy reverso creando un archivo de configuración para tal finalidad. Vamos a /etc/nginx/sites-enabled y copiamos el bloque de configuración al final del archivo default a nuevos archivos llamados matrix.dominio.edu.ar y element.dominio.edu.ar.

Renombramos el campo server_name en los nuevos archivos para que coincida con el nombre de cada host, y apuntamos root a una ubicación adecuada por dominio (ej. /var/www/matrix.dominio.edu.ar o /var/www/element.dominio.edu.ar para element)

A continuación detallamos la configuración del archivo de host virtual para el dominio de Synapse (matrix.dominio.edu.ar), redirige todo el tráfico del puerto 80 (HTTP) al puerto 443 (HTTPS), configura el puerto SSL con los certificados creados, redirige cualquier petición al punto final /_matrix en el dominio al servidor Matrix Synpse, y configura el puerto 8448, que es utilizado por las APIs de la Federación de Matrix para permitir que los homeservers de Matrix se comuniquen entre sí.

server {
listen 80;
server_name dominio.edu.ar;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;

# Para el puerto de federación
listen 8448 ssl http2 default_server;

server_name matrix.unau.edu.ar;

include /etc/nginx/snippets/location-letsencrypt.conf;
include /etc/nginx/snippets/ssl-params.conf;

ssl_certificate /etc/letsencrypt/live/matrix.unau.edu.ar/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/matrix.unau.edu.ar/privkey.pem;

location ~* ^(\/_matrix|\/_synapse\/client) {
# nota: no añadir una ruta (incluso una sola /) después del puerto en
# `proxy_pass`, de lo contrario nginx canonizará la URI y causará
# errores de verificación de firma errores.
proxy_pass http://IP-INTERNA:8008;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;

# Nginx por omisión sólo permite subir archivos de hasta 1M de tamaño
# Aumentar client_max_body_size para que coincida con max_upload_size
# definido en homeserver.yaml
client_max_body_size 50M;
}

Una vez que guardamos y cerramos el archivo, habilitamos el host virtual Nginx, y nos aseguramos de que no haya problemas.

ln -s /etc/nginx/sites-available/matrix.dominio.edu.ar /etc/nginx/sites-enabled/
nginx -t

A continuación, debemos habilitar el registro en synapse cambiando enable_registration: true en /etc/matrix-synapse/homeserver.yaml y reiniciando synapse vía systemctl restart matrix-synapse.

Ahora debemos anunciar al resto de Matrix cómo encontrar nuestro servidor. La forma más fácil de hacerlo es publicar información en https://matrix.dominio.edu.ar/.well-known/matrix/server que indica el nombre de host y el puerto donde se puede encontrar synapse para nuestro dominio – en este caso, es matrix.dominio.edu.ar:443:

Para ello agregamos este bloque a la configuración de nuestro proxy reverso.

location ^~ /.well-known/matrix/server {
return 200 '{"m.server": "matrix.dominio.edu.ar:443"}';
add_header Content-Type application/json;
}

Registrar una cuenta de usuario administrador

Al instalar el servidor Matrix Synapse también son instalados algunos ejecutables en el servidor, que pueden utilizarse para tareas específicas. register_new_matrix_user es uno de ellos, y permite registrar un nuevo usuario desde la línea de comandos.

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Esto inicia una configuración de usuario interactiva, introducimos el nombre de usuario y la contraseña deseados, luego seleccionamos yes/no para habilitar, o no, los privilegios de administración.

New user localpart [root]: username
Password: password
Confirm password: password
Make admin [no]: yes|no
Sending registration request...
Success.

Acceder a Matrix

Verificamos que el servidor Matrix está funcionando y es accesible abriendo el dominio configurado en un navegador web.

https://matrix.dominio.edu.ar

Deberíamos ver una página como la siguiente.

Con el usuario creado podemos iniciar sesión en el servidor a través del cliente web de Element alojado en https://app.element.io/, o descargar Element para nuestro sistema operativo.

Sea uno u otro, para iniciar sesión en nuestro servidor, hacemos clic en el enlace Editar, junto a “Iniciar sesión en su cuenta de Matrix en matrix.org”.

Introducimos el dominio del servidor como la URL del Servidor de base y hacemos clic en Continuar.

Introducimos el nombre de usuario y contraseña y hacemos clic en Iniciar sesión.

 

Dado que el servidor de base no incluye un cliente de manera predeterminada, y para brindar una solución completa, vamos a instalar Element ya que tiene una interfaz de usuario pulida y fácil de usar.

Element

Bajamos la última versión desde https://github.com/vector-im/riot-web/releases.

mkdir /var/www/element.dominio.edu.ar
cd /var/www/element.dominio.edu.ar
wget https://github.com/vector-im/element-web/releases/download/v1.9.0/element-v1.9.0.tar.gz

Comprobamos la firma GnuPG (recomendable, dado que Element se encarga de almacenar las claves de cifrado de extremo a extremo)

apt install -y gnupg
wget https://github.com/vector-im/element-web/releases/download/v1.9.0/element-v1.9.0.tar.gz.asc

Obtenemos la clave de firma para el repositorio de versiones de element, idealmente desde un servidor de claves…

gpg --keyserver keyserver.ubuntu.com --search-keys releases@riot.im

…y/o podemos descargar o cotejar la clave de firma desde packages.riot.im

wget https://packages.riot.im/riot-release-key.asc
gpg --import riot-release-key.asc
gpg --verify element-v1.9.0.tar.gz.asc

Esto debería reportar “Good signature”, aunque no confiará en la clave de liberación de Element.

También se puede optar por confiar explícitamente en la clave editándola, introduciendo “trust” y luego “5” para la confianza definitiva.

gpg --edit-key 74692659bda3d940

Descomprimimos el archivo y creamos un enlace, contemplando las futuras actualizaciones. De ese modo solo cambiaremos el enlace.

tar -xzvf element-v1.9.0.tar.gz
ln -s element-v1.9.0 element
chown www-data:www-data -R element
cd element
cp config.sample.json config.json

A continuación, modificamos elconfig.json para cambiar la base_url del servidor de base para que sea https://matrix.dominio.edu.ar (dónde encontrar la API cliente-servidor para nuestro servidor), y cambiar el server_name para que sea matrix.dominio.edu.ar (el nombre de nuestro servidor).

En este punto deberíamos poder ingresar a https://element.dominio.edu.ar, registrar una cuenta, ingresar, y charlar con el resto de Matrix.

Jitsi

Es posible indicar a Element que use Jitsi desde su config.json en /var/www/element.dominio.edu.ar/config.json y cabiando el preferredDomain del bloque jitsi de https://jitsi.riot.im a nuestra instancia https://jitsi.dominio.edu.ar.

Luego de refrescar nuestro Element/Web deberíamos poder usar Jitsi desde nuestro nuevo Element tiene la capacidad de incrustar Jitsi de forma nativa directamente en la aplicación.

Mensajería

Convengamos que todo el mundo tiene libertad para elegir sus propias aplicaciones de mensajería y colaboración, por lo que resulta inmediatamente evidente la necesidad de contar con una plataforma capaz de fusionar una amplia gama de aplicaciones, Matrix lo hace posible.

Todas las organizaciones, sean grandes o pequeñas, tienen una gran mezcla de aplicaciones de mensajería y colaboración. En este sentido, un concepto importante en Matrix es la interoperabilidad. Esto significa que Matrix está abierto a intercambiar datos y mensajes con otras plataformas utilizando un estándar abierto. Nos referimos a la conexión con otras plataformas como puente. Los diferentes puentes existentes se pueden consultar en https://matrix.org/bridges.

A modo de ejemplo nos abocaremos a integrar dos plataformas de mensajería: Telegram y WhastApp.

Telegram

Dependencias

apt install python3 python3-venv python3-virtualenv

WhatsApp

Dependencias

Al compilar con cifrado de extremo a extremo se debe tener un compilador C, python3 dev headers.

apt install python3-dev build-essential

Además, también es necesario libolm3 con dev headers instalados. Dado que no está disponible en los repos de Debian 10 es necesario agregar los repos backport

echo "deb http://ftp.debian.org/debian buster-backports main contrib" >> /etc/apt/sources.list
apt update
apt install -t buster-backports libolm-dev

Hoy en día, Matrix ofrece una excelente alternativa a las soluciones centralizadas:

  • Plena autonomía sobre cómo alojar y almacenar nuestras conversaciones
  • Libertad total para hablar con cualquier otra persona en la red global de Matrix (o cualquier otra persona conectada a Matrix)
  • Privacidad total a través de la encriptación completa de extremo a extremo para los chats, la transferencia de archivos y las llamadas de voz/vídeo 1:1 (cuando está activado)
  • Total transparencia al ser 100% de código abierto (así como beneficiarse de la comunidad de código abierto en general)

Como podemos ver, resulta bastante sencillo implementar nuestra propia instancia de Matrix totalmente funcional.

Etiquetas: