Ogni volta che contesto gli esperti in cialtroprivacy e dico di stare alla larga da Signal e Matrix le persone pensano che io ce l’abbia particolarmente con queste due piattaforme per qualsivoglia motivo personale. Beh, no. Ce l’ho con queste due piattaforme per ragioni precise, ovvero che si pubblicizzano come alternative quando sono itentiche a quei gafam che a parole vogliono contrastare.
Sputtanare Signal come alternativa ai GAFAM e’ cosi’ semplice che non dovrei nemmeno mettermici , ma a quanto pare le persone non sono in grado di andare sul sito di una piattaforma e farsi un’ idea (ma sono esperti di privacy online e di “alternative etiche” sia chiaro):
Allora, questa e’ l’architettura a blocchi del sistema che dovrebbe proteggervi dai GAFAM e non cedere loro dati:
Apparentemente basterebbe guardare gli attori coinvolti per capire che questa piattaforma vi potra’ difendere da tutti tranne che dai GAFAM. Ma il problema non e’ davvero quello. Il problema non e’ negli attori in alto ((Twilio, Apple, Google, Amazon S3), ma in quello che vedo sotto.
“Postgres, Redis”. Ok. Passi per redis che puo’ auto-rimuovere i dati dopo qualche tempo. Non mi piace, ma lo tollero. Ma Postgres?
Voi direte: e perche’ ce l’hai con postgres? Anche senza voler sputtanare un prodotto obsoleto che sembra disegnato negli anni ’70 da un ex programmatore di IBM in acido, il problema e’ semplice: “che ci fa un database persistente dentro un prodotto di instant messaging”?
Lo so che se non fai l’architetto di sistemi non ti rendi conto che le architetture “parlano” e “parlano” dell’uso che farai della piattaforma, cosi’ faro’ un esempio.
Immaginate di prendere in mano il vostro cellulare e di voler chiamare vostra nonna. Allora andate nella rubrica, cliccate su “nonna” e il cellulare vi dice “per telefonare, per favore avviate la registrazione della voce”.
E voi dite “no, io non voglio registrare la telefonata, anzi. voglio solo parlare con mia nonna”. E il cellulare: “impossibile chiamare se non si registra la telefonata”.
Ora, non ci vuole molto a capire che un cellulare che ha bisogno di registrare la telefonata e la conversazione vi stia spiando: per parlare con qualcuno servono due cose. Voi, qualcuno e una linea audio. Non serve alcuna registrazione della telefonata, e un cellulare che la richieda o imponga e’ CHIARAMENTE fatto per spiarvi.
Adesso passiamo ad un signal server. Un sistema di chat, o come si dice oggi di IM, non e’ altro che un multiplexer. Puo’ girare la chiamata ad una sola persona o ad un gruppo, ma lavora qui e adesso. Magari e’ accettabile che tenga per qualche tempo una coda, ma nulla di piu’.
Ma li’ c’e’ un intero database con permanenza. Che salva dati. Cose. Cosa? Boh, perche’ Signal server e’ stato oscurato per circa un anno:
e poi rimesso online:
Manuel Vonau
Quindi anche come opensource scarsegga abbastanza in trasparenza.
Andiamo a Matrix. Per stabilire cosa ci sia che non va in matrix dobbiamo fare circa la stessa cosa: andare a vedere se non ci sia un database. Perche’ se c’e’ un database, abbiamo CHIARAMENTE di fronte ad un server nato per spiare le conversazioni.
Il database c’e’? Puo’ essere sqlite o Postgres, e se volete un attimo sapere cosa fa , potete fare questa ricerca:
Perche’ Perche’ un qualcosa che fa da multiplexer deve salvare stati? Passi autenticare gli utenti, ma tutto il resto? Se anche vogliamo che un cavolo di IM server abbia persistenza temporanea o tenga delle code per qualche tempo, un memcached o un redis sono piu’ che sufficienti.
Ma qui stiamo eludendo la VERA questione: perche’ dobbiamo disegnare da zero un sistema di IM? Esiste gia’ tutto quel che serve per farne uno disegnando delle interfacce ad un qualsiasi sistema di code: RabbitMQ, NATS/GNATS, Kafka, Pulsar, Macrometa. MQTT…. ce ne sono a iosa. Non avete alcun bisogno di scrivere sistemi che facciano coda, che facciano dispatch. Tutto quello che dovete fare e’ scrivere le interfacce e lasciare che i client facciano il proprio lavoro.
Perche’ se parliamo di criptazione E2E, il lavoro lo fa il client. Ok, volete verificare l’identita’? Vi serve un keyserver, ma sarebbe meglio se fosse il client ad avere una rubrica. In ogni caso, al peggio avete bisogno di un NATS e di un keyserver, e di qualche migliaio di SLOC. Il client non deve fare altro che criptare con la chiave pubblica del destinatario e poi firmare con la propria chiave privata il messagio,
Volete le rooms con E2E? Avete due scelte:
- se chiunque puo’ entrare nella room, E2E e’ ridicolo. L’attaccante non fara’ altro che fare Join e registrera’ tutto. Quando avete controllato che i socket siano SSL, la crittazione e’ piu’ che sufficiente: chiunque puo’ entrare e ascoltare. Il resto e’ una vaccata da cialtrocriptari.
- se la stanza e’ accedibile solo da alcuni, allora l’accesso e’ gestito da un amministratore, umano o meno. Il client non deve fare altro che criptare con la chiave pubblica dell’amministratore e firmare con la propria chiave. Il bot amministratore non fa altro che verificare la firma, decrittare, e ridistribuire il messaggio a tutti dopo averlo criptato con la LORO chiave pubblica, e averlo firmato con la propria chiave privata.
le implementazioni che vedo in giro di room , invece, sono semplicemente delle backdoor, e spesso mascherate male.
La storia “ma non dobbiamo anche fare le telefonate e le videoconferenze” e’ ridicola. Entrambe le cose non sono necessarie: avete in mano un telefono, ricordate? Fa gia’ le telefonate e anche le videocall. Fa gia’ parte del protocollo LTE. E potete gia’ criptarle. L’infrastruttura esiste gia’.
La verita’ , cioe’, e che dopo la nascita di sistemi come RabbitMQ, NATS/GNATS, Kafka, Pulsar, Macrometa. MQTT, non abbiamo bisogno di scrivere altri “server di IM”. Al massimo dobbiamo scrivere i bot che mantengono le stanze, e poi usare un keyserver per le chiavi pubbliche, e scrivere dei buoni client. Punto. Se vogliamo che si federino dobbiamo scrivere un robottino (ed una coda) che si occupi di mandare i messaggi per un altro server e un’interfaccia TCP/SSL.
Non abbiamo davvero bisogno di nient’altro. Non serve reinventare la ruota. I sistemi di code (clusterizzabili, scalabili, pub/sub oppure no) esistono gia’. E sono SICURI perche’ sono TESTATI. E tutti consentono di scrivere plugin di fronte alle interfacce. Ci servono solo i client e al massimo un keyserver.
Il solo fatto che qualcuno si scriva da solo un nuovo server di IM e’ sospetto perche’ abbiamo gia’ sistemi di code di messaggi maturi e TESTATI anche sul profilo sicurezza. Se poi ci mettono dentro un database persistente, il sospetto e’ confermato: spyware.
Certo, mi direte che con la crittazione E2E la vostra preziosa creatura non puo’ salvare i messaggi, ma solo i metadati. Potrei raccontarvi di quella moglie che, leggendo i metadati, ha scoperto che il marito dava uno squillo alla ex ogni volta che usciva per andare a calcetto, ma siccome non ci sentite, vi faccio un disegnino:
Ecco, questo e’ quello che penso di Signal, Matrix e tutti quelli come loro:
- dopo la nascita di sistemi come RabbitMQ, NATS/GNATS, Kafka, Pulsar, Macrometa. MQTT, ed altri, scrivere un sistema di IM proprio, o proprietario, e’ un atto sospetto in se’.
- la crittazione E2E non puo’ che essere a carico del client. Non deve e non puo’ richiedere complessita’ implementativa al server
- non serve trattenere credenziali dell’utente, quando basta una chiave pubblica per verificare le firme.
- se poi c’e’ un database persistente, siamo SICURAMENTE di fronte ad uno spyware.
Ed e’ proprio qui il punto.
Sono tutti spyware, in cui vi state tuffando col falso senso di sicurezza che vi viene dagli “esperti di privacy” che ve li consigliano.
