Questione privacy e sicurezza in Matrix: client, server, room, federazioni, e policy

Category: Infrastruttura Tags: documentazione, dubbi Created: 2026-10-03T17:56:38Z Posts: 5

Post 1 by @KatolaZ — 2026-10-03T17:56:38Z

In questo post vorrei esaminare la questione sicurezza e privacy in matrix, per spiegare il significato di ogni singola scelta, e per dare a tutti la possibilita’ di contribuire alla discussione sulle policy che possiamo/vogliamo/dobbiamo implementare nei nostri canali Matrix

Premessa: come funziona matrix

Homeserver e utenti

Allora, brevissimamente. Matrix e’ un protocollo di messaggistica client-server federato. L’elemento essenziale di matrix e’ l’ homeserver. Un esempio di homeserver e’ “matrix.org” o “matrix.cioll.app”.

Un homeserver e’ un server che consente a piu’ utenti (client) di accedere al sistema di messaggistica matrix. Un utente (client) e’ univocamente identificato da un handle del tipo @katolaz:matrix.cioll.app, dove @katolaz e’ il nome dell’utente, e matrix.cioll.app e’ il nome del suo homeserver

Un utente e’ associato in maniera univoca ed indissolubile ad un solo homeserver. La relazione tra un utente e un homeserver in matrix e’ la stessa che c’e’ tra una mailbox e il corrispondente server di posta.

Un utente e’ identificato da una (serie di ) coppia(e) di chiavi. Per mantenere accesso alla sua identita’ se tutti i suoi dispositivi sono disconnessi/scomparsi, un utente puo’ decidere di mantenere un keystore SUL SUO HOMESERVER. Questi keystore sono crittati e in teoria accessibili solo dall’utente, con una recovery key.

Come un utente comunica con un altro utente matrix

Tutte le comunicazioni tra utenti in matrix sono mediate dai loro corrispondenti homeserver. Questo significa che se @katolaz:matrix.cioll.app vuole mandare un messaggio a @nightolo:matrix.cioll.app, allora il messaggio verra’ di @KatolaZ viene mandato all’homeserver di @katolaz (matrix.cioll.app). L’homeserver si accorge che il messaggio e’ destinato a @nightolo:matrix.cioll.app, che e’ un utente dello stesso homserver, e gli recapita il messaggio. Se il destinatario appartiene ad un altro homeserver, allora il server matrix di @katolaz mandera’ il messaggio all’homeserver di @nightolo . La seconda modalita’ di trasmissione e’ possibile solo se i due homeserver sono FEDERATI, ossia accettano comunicazioni ciascuno dall’altro homeserver.

Le comunicazioni dirette tra due utenti matrix sono sempre e2ee (End-to-End Encrypted), nonostante passino sempre dai rispetivi homeserver.

Le Room

Le room in matrix sono delle chat multiutente. I messaggi che vengono mandati da un utente ad una room sono crittati con una chiave di sessione della room alla quale (in teoria) hanno accesso solo gli utenti che si trovano nella room al momento in cui il messaggio viene inviato. Pero’ ciascun utente comunica direttamente SEMPRE E SOLO CON IL SUO HOMESERVER, quindi i messaggi che un utente manda su una room, vengono spediti al suo homeserver, il quale li inoltra a tutti gli homeserver di tutti gli utenti che stanno nella room. Questo significa che se una room ha unicamente utenti di un solo homeserver, i messaggi di quella room non escono mai dall’homeserver. (Questo sara’ importante dopo).

Possibili problemi di sicurezza/privacy

Matrix consiste di una serie di protocolli basati su crittografia forte che garantiscono un buon livello di sicurezza e privacy delle comunicazioni. Ciononostante, esistono comunque delle vulnerabilita’ (quantomeno teoriche) dovute al modo in cui matrix gestisce alcune cose, e al fatto che ad oggi esiste un unico attore (matrix.org) che e’ lo sviluppatore unico del server piu’ usato (synapse) e delle maggior parte dei client.

Ecco alcuni degli attacchi (potenziali) che possono minare la sicurezza e la privacy delle comunicazioni dentro matrix:

A1 - Server keystore tampering: La possibilita’ che il server mantenga un keystore crittato con l’identita’ matrix di ogni client, consente ad un client di ripristinare la sua identita’ nel caso in cui rimanga fuori da tutti i suoi device[*]. Pero’, se un solo attore sviluppa sia client che server, almeno in teoria client e server potrebbero mettersi d’accordo per aprire il keystore. A quel punto, tutte le comunicazioni passate e future di quell’utente diventano leggibili dul server.
A2 - User injection: Esiste la possibilita’ almeno in teoria che un server possa iniettare falsi user “silenti” in una room, che sono in grado di leggere i contenuti della room ma rimangono invisibili agli altri utenti della room (i dettagli di questo attacco sono un po’ complicati da spiegare). In questo caso, un server malevolo puo’ accedere a tutte le comunicazioni di una room, a partire dal momento in cui il suo user fittizio ha joinato la room. Questo significa che le comunicazioni della room da quel momento in poi sono tutte in chiaro sul server.
A3 - Data retention for post-quantum decryption: Il server ha la possibilita’ di mantenere/storare una quantita’ illimitata di messaggi che transitano verso igli user di cui e’ homeserver. Questi messaggi sono tutti crittati con chiavi alle quali il server non ha accesso, ma almeno in teoria sarebbe possibile per un server malevolo decrittare tutto in uno scenario post-quantum, ossia se diventasse possibile risalire alla chiave privata di un utente a partire dalla sua chiave pubblica e da del cyphertext disponibile, usando algoritmi quantistici.
A4 - Malicious user: questo attacco non ha nulla a che vedere con matrix in particolare, ma tenerlo in considerazione serve per vagliare le policy che esporremo in seguito. Si tratta del classico caso della “talpa”: un qualunque utente che partecipa ad una room potrebbe, in generale, dare accesso a tutto il contenuto della room a terzi.

Come mitigare i possibili problemi di sicurezza

Discutiamo in seguito alcune contromisure, scenari e policy che possono mitigare gli attacchi che abbiamo elencato al punto precedente.

Server matrix su “ferro a casa” DI PERSONA FIDATA.

Questa contromisura garantisce che gli attacchi A1, A2, e A3 siano impossibili/improbabili. Se il server e’ gestito su ferro a casa da persona fidata, su una macchina su cui gira soltanto ed esclusivamente matrix (e non su un VPS, o su una macchina con 30 VM di altri servizi, o in un container), tutti gli utenti che hanno quel server come homeserver non sono soggetti agli attacchi A1, A2, A3.

Room che contengono solo utenti di un unico server fidato (ferro a casa)

In teoria un utente che ha come homeserver un server su ferro a casa di persona fidata e’ comunque esposto ali attacchi A2 ed A3 se c’e’ almeno un utente nella stessa room che ha un homeserver diverso. Cio’ e’ dovuto al fatto che i messaggi che vanno ad una room vengono inoltrati a tutti gli homeserver di tutti gli user che sono nella room. L’unico modo per garantire che le discussioni di una room siano sempre sicure e’ imporre che tutti gli utenti che appartegano ad una room siano utenti di homeserve fidati su ferro a casa.

Room che contengono utenti di diversi server non necessariamente fidati

Gli utenti di server “ferro a casa” che appartengono ad una room del genere sono immuni all’attacco A1 (keystore tampering), ma soggetti ugualmente agli attacchi A2 e A3, da parte dei server degli utenti della stessa room che non sono fidati e potrebbero mettere in atto A2 ed A3 all’insaputa degli altri utenti della room.

Perche’ tutto cio’ ci deve interessare?

Perche’ dobbiamo capire cosa significa ognuna delle scelte che facciamo, e dobbiamo valutare quali policy mettere in piedi per gestire il nostro utilizzo di matrix in maniera sicura. Ripcapitolando:

alcuni di noi vorrebbero un account su un server-ferro-a-casa fidato, per essere almeno sempre immuni da A1
un server-ferro-a-casa puo’ limitare al minimo il logging di informazioni sugli utenti, e puo’ limitare anche la retention dello storico delle chat, limitando la possibilita’; di disclosure di informazioni nel caso di key leak/tampering.
abbiamo comunque bisogno/voglia di avere delle room a cui possano partecipare anche utenti di altri server. Questo e’ possibile solo tramite federazione del server-ferro-a-casa con altri server. In tal caso, tali room devono essere considerat insicure, perche’ soggette ad A2 ed A3. Un esempio di una room del genee potrebbe essere una cosa tipo Piazza Virtuale, ma dovremmo considerarla TOTALMENTE INSICURA in linea di principio.
abbiamo comunque bisogno di spazi privati , che non siano soggetti ad A1, A2, A3. Le uniche room che soddisfano questo requisito sono quelle rooom che contengono solo ed esclusivamente utenti il cui homeserver e’ un server fidato (ferro-a-casa di persona fidata). Una room di questo tipo sarebbe una cosa tipo Freaknet Core, o una room degli admin dei nostri servizi.
Potremmo anche decidere di fornire un account su uno dei nostri server-ferro-a-casa a terzi piu’ o meno vicini a Freaknet. L’avere un account su un nostro server non implica necessariamente che si abbia accesso a tutte le room.
Dobbiamo decidere quali room vogliamo e le corrispondenti policy di accesso ed utilizzo a queste room. Per esempio, potremmo decidere che una roba tipo PiazzaVirtuale sia accessibile piu’ o meno ac chiunque sia vicino a Freaknet, che RadioFreak sia accessibile solo da alcuni server nostri e/o di amici stretti (Vash?), che la room Freaknet imponga che tutti gli utenti stiano sullo stesso server (matrix.cioll.app), e che alla room FreaknetCore appartengano soltanto alcuni dei membri della room Freaknet, con le stesse restrizioni e credenziali aggiuntive per evitare l’accatto A4.

Discutiamo ste cose alla prossima assemblea, ma facciamolo alla luce di tutto quello che c’e’ scritto sopra. Se ho dimenticato qualcosa, aggiungete. Se ci sono errori, corregeteli.

HND

KatolaZ

Una postilla riguardo matrix.org

C’e’ un rischio serio connesso alla centralizzazione di account su matrix.org. Questi saranno gli attori principali della transizione verso la “sovranita’ digitale” europea. Hanno gia’ contratti molto grossi in essere, ad esempio con alcune PA in Germania, alle quali fornisco servizi di messaggistica e VC. L’atteggiamento di matrix.org, oltre la questione di facciata della federazione eccetera, e’ sempre stato quello di accentrare tutto sui loro server, sui loro client, e sui loro domini. Il fatto che i clienti “ufficiali” distribuiti da matrix.org NON supportino account multipli, nonostante cio’ non sia per nulla un problema (vedi SchildiChat Next), e’ quantomeno sospetto. Pensate ad uno scenario, che si potrebbe verificare entro 3-4 anni, in cui le PA europee decidono di convergere su una unica piattaforma digitale, e che questa piattaforma diventi matrix.org, o gestita dalla stessa matrix.org. Pensate alla possibilita’ (non tanto remota, perche’ e’ gia’ successo in Italia) di dover per forza avere un account su matrix.org per interagire con qualunqe PA, e che a quel punto il vostro acount matrix.org debba essere verificato e supportato da un docmento di identita’. A quel punto, se tutti gli europer sono in qualche modo costretti ad avere un account su server gestiti da matrix.org, gli attacchi A1, A2 e A3 che abbiamo discusso sopra diventano davvero preoccupanti, Specie se la maggior parte delle persone no avra’ un modo semplice per gestire account multipli sullo stesso dispositivo (alla fine tutti useranno solo il loro account matrix.org…).

Un’altra questione che riguarda matrix.org e’ quella del client web. E’ possibilissimo per loro “pushare” una nuova versione di client web che faccia “altro” (per esempio, sbloccare il keystore sul server), prima che ce ne accorgiamo. Nesuno guarda al changelog su github prima di cliccare su “Si’, aggiorna Element Web”. Una volta che il keystore e’compromesso, tutte le comunicazioni effettuate con quella identita’ digitale sono potenzialmente in chiaro sul server. Scenario non molto futuristico: le la polizia postale vuole monitorare un account, chiede a matrix.org di iniettare uno specifico client web a quell’account, solo per un tempo limitato (quello che basta ad aprire il keystore), e poi fare sparire traccia di tutto. Se matrix.org diventa l’attore principale dell’operazione di “sovranita’ digitale europea” questo scenario e’ drammatico.