User Tools

Site Tools


doc:appunti:linux:sa:matrix

This is an old revision of the document!


Matrix Messenger

Come installare un server per la messaggistica Matrix su una Debian GNU/Linux 10 Buster.

Il ruolo di un server Matrix è quello di memorizzare le chat personali di un utente e le informazioni dell'account in un modo molto simile a quello di un server di posta IMAP/SMTP.

Il server di riferimento sviluppato da Matrix per la propria piattaforma è Matrix Synapse. Si tratta di una implementazione adeguata ad eseguire un home server.

Queste sono le caratteristiche della nostra installazione:

  • Installazione di un server sotto un nome di dominio, esempio matrix.example.org.
  • Accesso tramite protocollo HTTPS grazie a certificati SSL rilasciati da Let's Encrypt.
  • Attivazione di un reverse proxy HTTP con Apache. Questo offre il vantaggio di poter esporre il protocollo HTTPS ai client sulla porta 8448 (standard di Matrix) e sulla porta 443, senza richiedere i privilegi di root.
  • Disabilitazione della auto-registrazione (gli utenti vengono creati dall'amministratore).
  • Attivazione delle notifiche via mail, che consente di associare pubblicamente il proprio account Matrix ad un indirizzo di posta elettronica per facilitare la ricerca del nostro contatto.

Cosa occorre:

  • Un server Debian GNU/Linux 10 Buster con IP pubblico.
  • Un nome a dominio con possibilità di aggiungere record DNS.
  • Un account di posta elettronica per inviare mail.

Installazione di matrix-synapse in Debian 10 Buster

In Debian esiste il pacchetto matrix-synapse versione 1.24.0, ma è nella suite buster-backports, quindi è necessario aggiungere tale repository in /etc/apt/sources.list:

deb     http://deb.debian.org/debian buster-backports main contrib non-free
deb-src http://deb.debian.org/debian buster-backports main contrib non-free

Durante l'installazione del pacchetto viene chiesto il nome che avrà il server Matrix, nel nostro caso indicheremo matrix.example.org. È importante scegliere bene il nome in questa fase, infatti se dovessimo cambiare idea sarà necessario reinstallare il server da capo perché molti ID dipendono da quel nome e per il momento non esistono strumenti di migrazione.

Al termine dell'installazione il server dovrebbe essere in ascolto sulla porta 8008/TCP utilizzando il protocollo in chiaro HTTP e sulla porta 8448/TCP con il protocollo cifrato HTTPS. Per impostazione predefinita le porte sono collegate solo su localhost. Nel nostro caso l'avvio del programma falliva perché i certificati SSL/TLS non erano presenti.

Queste le porte generalmente utilizzate da Matrix:

8008/TCP Protocollo in chiaro HTTP.
8448/TCP Protocollo cifrato HTTPS. Nel nostro caso abbiamo disabilitato questa porta, sarà il server web Apache a ricevere le richieste HTTPS e inoltrarle in HTTP sulla 8008 via Reverse Proxy.

La configurazione del programma sta in un file di configurazione e in un database (predefinito SQLite):

  • /etc/matrix-synapse/homeserver.yaml
  • /var/lib/matrix-synapse/homeserver.db

Informazioni di debug si trovano nel syslog di sistema e nel log specifico.

  • /var/log/syslog
  • /var/log/matrix-synapse/homeserver.log

Per i nostri scopi (vedere avanti) vogliamo che il server stia in ascolto in HTTP (senza crittografia) solo sulla porta 8008/TCP e che risponda solo sull'indirizzo localhost 127.0.0.1. Le impostazioni relative di homeserver.yaml sono:

no_tls: True

listeners:
    bind_addresses:
      - '::1'
      - '127.0.0.1'

Il file yaml contiene informazioni sensibili (ad esempio la password per la creazione di utenti o per accedere al server SMTP), pertanto è opportuno proteggerlo con mode 640 e proprietario matrix-synapse. Quando si modifica il file di configurazione è necessario riavviare il servizio con:

systemctl start matrix-synapse.service

Evitare l'auto-registrazione

L'impostazione predefinita Debian di matrix-synapse contiene

enable_registration: false

Ciò significa che ogni utente di questo nodo Matrix dovrà essere creato dall'amministratore. In alternativa è possibile avere l'auto-registrazione, come viene offerta ad esempio dal nodo di riferimento matrix.org.

Ottenere i certificati SSL/TLS da Let's Encrypt

L'utilizzo di TLS è requisito imprescindibile per garantire la sicurezza del server poiché protegge lo scambio dei messaggi che comprendono anche l'invio delle password. Nella configurazione qui presentata il software matrix-synapse non utilizzerà direttamente TLS, ma sarà Apache ad utilizzarlo, passando le richieste a Matrix Synapse sull'indirizzo 127.0.0.1:8008. Il localhost viene considerato sicuro e quindi è accettabile dialogarci in chiaro.

Con Debian 10 Buster è sufficiente installare il pacchetto certbot ed eseguire il comando:

certbot certonly --text --webroot -w /var/www/html -d matrix.example.org

La procedura prevede di creare dei file in /var/www/html/.well-known/ e chiedere a Let's Encrypt di verificarli via http. Al termine dell'operazione i file da utilizzare sono:

  • /etc/letsencrypt/live/matrix.example.org/fullchain.pem
  • /etc/letsencrypt/live/matrix.example.org/privkey.pem

Attivare il server web con reverse proxy

Abbiamo preferito utilizzare il server web Apache per la sua versatilità, in rete tuttavia si trovano molte ricette per utilizzare il più compatto Nginx. Dopo aver installato il pacchetto apache2 è necessario attivare i moduli ssl e proxy_http:

apt-get install apache2
a2enmod ssl
a2enmod proxy_http
systemctl restart apache2

Apache starà in ascolto sulla porta standard HTTP effettuando il redirect automatico su HTTPS; verranno servite anche le richieste HTTPS sulla porta 8448/TCP. In ogni caso tutte le richieste saranno passate con ProxyPass a matrix-synapse verso l'URL http//127.0.0.1:8008.

Dopo aver aggiunto la direttiva Listen 8448 al file /etc/apache2/ports.conf, si effettua la configurazione di Apache nel file /etc/apache2/sites-available/matrix.example.org.conf:

<VirtualHost *:80>
    ServerName matrix.example.org
    SSLEngine off
    DocumentRoot /var/www/html
    ServerAdmin webmaster@example.org
    ErrorLog ${APACHE_LOG_DIR}/matrix.example.org/error.log
    CustomLog ${APACHE_LOG_DIR}/matrix.example.org/access.log combined
    # Redirect everything to https, except /.well-known/ directory.
    RedirectMatch permanent ^/((?!\.well-known).*)$ https://matrix.example.org/$1
</VirtualHost>
<VirtualHost *:443 *:8448>
    ServerName matrix.example.org
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/matrix.example.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/matrix.example.org/privkey.pem
    ServerAdmin webmaster@example.org
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/matrix.example.org/error.log
    CustomLog ${APACHE_LOG_DIR}/matrix.example.org/access.log combined
    # HTTP Matrix Synapse  
    ProxyPass / http://127.0.0.1:8008/ nocanon
    ProxyPassReverse / http://127.0.0.1:8008/
</VirtualHost>

L'eccezione al Redirect per la .well-known directory serve a far funzionare il rinnovo automatico dei certificati Let's Encrypt. La direttiva nocanon è indispensabile, senza di essa abbiamo riscontrato il seguente errore quando si è cercato di accettare la richiesta di messaggio diretto da parte di un utente registrato su matrix.org:

SynapseError: 401 - Invalid signature for server matrix.org with key ed25519:a_RXGa:
Unable to verify signature for matrix.org:
<class 'nacl.exceptions.BadSignatureError'> Signature was forged or corrupt

Con la configurazione vista sopra, chiamando l'URL http://matrix.example.org/, si viene rediretti prima verso il protocollo HTTPS e quindi al percorso https://matrix.example.org/_matrix/static/. A questo URL c'è semplicemente un messaggio che avvisa dell'homeserver Synapse in esecuzione e invita ad installare un client.

Alternativa: matrix-synapse senza reverse proxy

Se si volesse fare a meno del server web, si dovrebbe porre matrix-synapse in ascolto anche in HTTPS sulla porta 8448/TCP. I certificati SSL/TLS saranno ovviamente indicati nel file di configurazione /etc/matrix-synapse/homeserver.yaml:

# WARNING: Don't use TLS in matrix-synapse if port 8448 is used by the HTTP Reverse Proxy.
tls_certificate_path: "/etc/matrix-synapse/homeserver.tls.crt"
tls_private_key_path: "/etc/matrix-synapse/homeserver.tls.key"
tls_dh_params_path: "/etc/matrix-synapse/homeserver.tls.dh"
no_tls: False

I file homeserver.tls.crt e homeserver.tls.key sono quelli ottenuti da Let's Encrypt (rispettivamente fullchain.pem e privkey.pem). Vanno copiati per poter assegnare i permessi giusti: proprietario matrix-synapse e mode 644 e 600 rispettivamente. Ovviamente si deve provvedere a ripetere la copia ogni volta che il certificato viene rinnovato. Invece per generare il file homeserver.tls.dh si esegue:

openssl dhparam -out /etc/matrix-synapse/homeserver.tls.dh 2048

Creazione di un account

Avendo disabilitato l'auto-registrazione, si deve creare manualmente il primo account, essendo il primo esistente lo faremo di tipo amministratore. Useremo il comando register_new_matrix_user, che però richiede la seguente opzione nel file di configurazione:

registration_shared_secret: MySecret

Eseguendo il comando successivo sulla stessa macchina, non è necessario digitare tale password; questa verrà letta direttamente dal file yaml:

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008
New user localpart [root]: niccolo
Password:
Confirm password:
Make admin [no]: yes
Sending registration request...
Success!

Configurazione del DNS

Per far funzionare la federazione tra server Matrix è necessario dichiarare un record SRV nella zona DNS. Supponiamo che la zona DNS sia example.org, questa è la relativa riga di configurazione per Bind9:

_matrix._tcp  IN  SRV  0 10 8448 matrix.example.org.

Gli utenti del nostro nodo saranno conosciuti alla federazione con il nome @username:matrix.example.org.

Debug

Verificare quale versione del software è in esecuzione sul server:

curl https://matrix.example.org/_matrix/federation/v1/version

Abilitare le notifiche email

Nella app Element si prova a configurare il proprio indirizzo email da ImpostazioniGeneraliEmail e numeri di telefono. Quando si aggiunge una email - se le notifiche email sono disattivate sul server - si ottiene l'errore:

Adding an email to your account is disabled on this server

Queste sono le impostazioni in homeserver.yaml relative all'invio di mail:

email:
   enable_notifs: true
   smtp_host: "mail.example.org"
   smtp_port: 587
   smtp_user: "smtp-user"
   smtp_pass: "MySMTPSecret"
   require_transport_security: True
   notif_from: "Your Friendly %(app)s Home Server <noreply@example.org>"
   app_name: Matrix
   template_dir: res/templates
   notif_template_html: notif_mail.html
   notif_template_text: notif_mail.txt
   notif_for_new_users: True
   riot_base_url: "http://matrix.example.org/riot"

Con qusta direttiva si dichiara l'URL pubblico:

public_baseurl: https://matrix.example.org:8448/

Infine si deve copiare la directory dei template:

cp -pr /usr/lib/python3/dist-packages/synapse/res /var/lib/matrix-synapse/

Se ci si dimentica di qualche passaggio si ottengono eventualmente gli errori:

ERROR: Password reset emails are enabled on this homeserver due to a partial
'email' block. However, the following required keys are missing:
    public_baseurl

oppure:

ERROR: Configured template directory does not exist: /var/lib/matrix-synapse/res/templates

Fatto qusto è possibile registrare il proprio indirizzo email nella app. La procedura prevede i seguenti passaggi:

  1. Il server Matrix riceve la richiesta dal client.
  2. Il server invia una email di verifica all'indirizzo specificato.
  3. L'email di verifica contiene un link da visitare, che fa riferimento allo stesso server Matrix.
  4. Nella app è possibile adesso tappare il pulsante prosegui.
  5. Per ulteriore conferma è necessario immettere la propria password dell'account Matrix.

Test dal client web riot.im

Si visita la pagina https://riot.im/app/#/login

Other homeserver https://matrix.example.org
Username
Password

Installazione della app Element

Il client più utilizzato per accedere alla messaggistica Matrix è Element, esiste per piattaforma Android e iOS, ma esiste anche in versione desktop per Windows e Mac OS.

La versione Android, essendo un programma libero ed open source, è scaricabile sia dal Google Play che da repository alternativi come F-Droid. Fra le due versioni c'è una sostanziale differenza sia in termini di dimensione (circa 22 Mb per la versione Google Play, 50 Mb per la versione F-Droid), sia in termini di funzionalità; la versione Google Play infatti utilizza i servizi Google per la gestione delle notifiche, ottimizzando il traffico e la gestione della batteria a discapito della libertà: infatti è necessario avere un account Google attivo per utilizzarla.

Security key

Un account Matrix è costituito da un login e una password, ma c'è un altro elemento altrettanto importante: le chiavi di cifratura di tutte le chat effettuate. Tali chiavi sono memorizzate nella sessione del client (app Element sullo smartphone, oppure interfaccia web riot.im). Se la sessione viene chiusa o distrutta potremo accedere nuovamente al nostro account con login/password, ma non verranno decifrate tutte le chat passate, a meno che non abbiamo salvato la security key. Tale chiave verrà chiesta quando useremo il client per accedere nuovamente al nostro account.

Perdita della password

Cosa succede se si perde la password di un account su Matrix.org:

  • È possibile recuperare l'account solo se si è associato un indirizzo email all'account. Sarà possibile (ad esempio dall'interfaccia web https://riot.im/) chiedere il reset della password, verrà inviata una mail che contiene un link da seguire per confermare l'operazione.
  • Dopo aver cambiato la password tutte le chat passate saranno illeggibili, ogni messaggio verrà visualizzato come Unable to decrypt. Per i nostri interlocutori invece i messaggi saranno ancora leggibili.
  • Se abbiamo una vecchia sessione aperta (ad esempio la app Element in esecuzione su uno smartphone, oppure una pagina web aperta su riot.im) sarà possibile recuperare la chiave di decifrazione per le vecchie chat.
  • Se a suo tempo abbiamo salvato il codice di decifrazione, sarà possibile recuperare le vecchie chat.

Verifica identità

Element/Matrix: Crittografia end-to-end attiva In una chat di messaggi diretti, quando la crittografia end-to-end è attiva, compare il simbolo di uno scudo nero sopra l'icona dell'interlocutore. Questo garantisce che i messaggi sono cifrati appena escono dal nostro dispositivo e vengono decifrati solo sul dispositivo del nostro interlocutore. Neanche l'amministratore dell'homeserver può leggerne il contenuto. Questo tuttavia non garantisce l'identità dell'interlocutore; se vogliamo avere la certezza che l'interlocutore sia davvero chi dice di essere, dobbiamo scambiarci un codice di conferma su un canale diverso da Matrix.

Element/Matrix: Crittografia end-to-end attiva e identità verificata La via più semplice è lo scambio di un codice QR in presenza fisica. Per farlo è sufficiente che uno dei due interlocutori faccia tap sull'intestazione della chat, scelga il menu 2 persone, il nome dell'interlocutore e quindi SicurezzaVerifica. Viene avviata una procedura durante la quale uno dei due smartphone genera a video un codice QR e l'altro avvia la fotocamera per scansionare tale codice. Al termine della procedura l'icona dell'interlocutore avrà il simbolo di uno scudo verde.

Web References

doc/appunti/linux/sa/matrix.1611212229.txt.gz · Last modified: 2021/01/21 07:57 by niccolo