|
|
Subscribe / Log in / New account

France enters the Matrix

February 11, 2019

This article was contributed by Tom Yates


FOSDEM

Matrix is an open platform for secure, decentralized, realtime communication. Matthew Hodgson, the Matrix project leader, came to FOSDEM to describe Matrix and report on its progress. Attendees learned that it was within days of having a 1.0 release and found out how it got there. He also shed some light on what happened when the French reached out to them to see if Matrix could meet the internal messaging requirements of an entire national government.

From a client's viewpoint, Matrix is a thin set of HTTP APIs for publish-subscribe (pub/sub) data synchronization; from a server's viewpoint, it's a rich set of HTTP APIs for data replication and identity services. On top of these APIs, application servers can provide any service that benefits from running on Matrix. Principally, that has meant interoperable chat, but Hodgson noted that any kind of JSON data could be passed, including voice over IP (VoIP), virtual or augmented reality communications, and IoT messaging. That said, Matrix is independent of the transport used; although current Matrix-hosted services are built around HTTP and JSON, more exotic transports and data formats can be used and, at least in the laboratory, have been.

Because Matrix is inherently decentralized, no single server "owns" the conversations; all traffic is replicated across all of the involved servers. If you are using your server to talk to someone on, say, a gouv.fr server, and your server goes down, then because their server also has the whole conversation history, when your server comes back up, it will resync so that the conversation can continue. This is because the "first-class citizen" in Matrix is not the message, but the conversation history of the room. That history is stored in a big data structure that is replicated across a number of participants; in that respect, said Hodgson, Matrix is more like Git than XMPP, SIP, IRC, or many other traditional communication protocols.

[Matthew Hodgson]

Matrix is also end-to-end encrypted. Because your data is replicated across all participating servers, said Hodgson, if it's not end-to-end encrypted, it's a privacy train wreck. The attack envelope enlarges each time a new participant enters a conversation and gets a big chunk of conversation history synchronized to their server. In particular, admitting a new participant to your conversation should not mean disclosing the conversation history to whoever administers their server; end-to-end encryption removes that possibility.

Matrix was started back in May 2014. By Hodgson's admission, the first alpha release in September 2014 was put together far too quickly, in a process where "everybody threw lots of Python at the wall, to see what would stick". In 2015, federation became usable, Postgres was added as an internal database engine alongside SQLite, and IRC bridging was added. Later that year the project released Vector as its flagship client, which meant also releasing the first version of the client-server API.

In 2016, much hard work was done on scaling, the Vector client was rebranded as Riot (which it remains today), and end-to-end encryption was added. This latter feature turned out to be difficult in a decentralized world: if you have a stable decentralized chat room, and someone's server goes offline for a few hours, during which time a couple more devices are added to the server, then when the server comes back into federation, should those new devices be in the conversation or not? To Hodgson, this is as much a philosophical question as it is a technical one, but it had to be answered before end-to-end encryption could be implemented.

In 2017, the project added a lot of shiny user-interface whizziness: widgets, stickers, and the like, then in 2018 tried to stabilize all this by feature-freezing and pushing hard towards version 1.0. This push has included the necessary step of setting up a foundation to act as a neutral guardian of the standard. That will allow others to build on it knowing that it's stable and won't be changed at a moment's notice to suit Hodgson and the Matrix developers. Creating that stable base to hand off to the foundation meant nailing down all the protocol APIs, which has not been without pain. Some of them, particularly the federation API, have needed significant changes to correct design errors in the original specifications.

Rolling these changes out has been harder than it should have been because the Matrix developers didn't include protocol versioning in everything from the outset. Hodgson pleaded with the audience, should any of us ever build a protocol, to "make damn sure you can ratchet the version of everything from the outset, otherwise you just paint yourself into a corner. One day you discover a bug in your federation API, and then, before you can fix it, you have to retrofit a whole versioning system".

The move to 1.0 has also meant a complete rethink of certificate management. Back in 2014 the Matrix project decided to abjure traditional certificate authorities; instead, self-signed certificates would be used. To democratize decisions about who to trust, notary servers would be implemented to build a consensus about the trustability of a given TLS certificate. It was, in Hodgson's words, a disaster. While the developers were trying to fix it, Let's Encrypt came along, which made the process of getting properly-signed certificates trivial, so the self-signing experiment has been abandoned. The 0.99 version of the home server code is ACME-capable and can get a certificate directly from Let's Encrypt; the 1.0 version removes support for self-signed certificates.

At 2am on the day of Hodgson's talk, February 2, the server-server API was released at version 0.1. All five core APIs are now stable, he said, which is a necessary precondition for a 1.0 release. Two of them (the client-server and identity APIs) still need final tweaks, but apparently these are expected to have landed by the time this article is published, signaling Matrix's official exit from beta.

Matrix has already been pretty successful. Hodgson presented two graphs (active users, publicly-visible servers) both with pleasing-looking exponential curves on them. The matrix.org server has about half of the seven million globally visible accounts, so it was interesting that Hodgson announced the long-term intention to turn that server off. Apparently, once it becomes common for other organizations to offer a federated Matrix server, there will be no need for a "default" server for new users to land on. It's clear that Hodgson really does regard Matrix as a fully federated system, rather than something centralized, or centralized-plus-hangers-on.

The French connection

In early 2018, DINSIC, which Hodgson described as the "French Ministry of Digital", reached out to one of the developers working on the Riot client for Android to ask if they might get a copy for their own purposes. On investigation, it turned out that what the ministry wanted was end-to-end encrypted, decentralized communication across the entire French government, running on systems that France could provision and control. The agency thought that Matrix might be an excellent platform for providing this.

One might, said Hodgson, question why a government wanted a decentralized system. It turns out that governments, at least in France, only look centralized; in real life they're made up of ministries, departments, sub-departments, schools, hospitals, universities, and so forth. Each of these organizations will have its own operational requirements, security model and policies, and so on; a federated solution allows server operation to be decentralized to an extent that makes the most sense for server operation and for the user community. In France, the user community turns out to be about 5.5 million users — that is, about 9% of the population of the country. In addition, although this was to be a standalone deployment, DINSIC wanted the ability to federate publicly, to be able to connect to other governments, suppliers, contractors, etc., using their shiny new system but without all those external people needing accounts on it.

Because of the federated nature of what was being sought, end-to-end encryption was a requirement, which Matrix was in a position to provide. But DINSIC also wanted enterprise-grade anti-virus (AV) support, so that the ability to share documents, images, and other data through the system didn't present an exciting new infection vector. As Hodgson pointed out, AV is pretty much entirely incompatible with end-to-end encryption: if you've built a system that prevents anyone except sender and receiver from knowing what's in a file, how's a third party going to intercept it en route to scan it for known-harmful content?

In the end, this required adding the ability for files to be exfiltrated from Matrix to an arbitrary external scanning service. This service is provided with the URL for a piece of encrypted content, plus the encryption keys for that content — not for the message in which the content appears, or for the room in which the message appears — encrypted specifically for the content-scanning service. The scanning service then retrieves the content, decrypts and scans it, and proxies the result back into Matrix. Having acquired this ability, Matrix scans content both on upload and download, for extra security; the code to do all this will be making its way back into mainstream Matrix in the near future.

Having committed to using Matrix, DINSIC started work in May 2018 on Tchap, its fork of the Riot client. The current state of the work can be found on GitHub; user trials started in June. The French National Cybersecurity Agency has audited the system, as has an external body. As of January 2019, it's being rolled out across all French ministries, which involves a great deal of Ansible code. Hodgson gave a quick demo of Tchap, noting that at the moment he feels that Tchap is probably more usable than the mainstream Riot client, not least because DINSIC has had a professional user-experience (UX) agency working hard on it.

It's no secret that FOSDEM suffers from having a fixed selection of rooms, of fixed sizes, which often don't correspond to the demand for the activities in those rooms. This year, the queue for entry to the JavaScript devroom, for example, was so enormous that the door itself was quite invisible for most of the weekend. On the flip side, the huge Janson auditorium that is used for the keynotes often has to host talks given to audiences that, though they'd fill most other rooms, look a little lost in that vast cavern. Hodgson gave his talk to a Janson auditorium with virtually no free seats — the largest audience I have ever seen in there for a non-keynote talk.

Clearly, there is some interest in the project. Some of this will be curiosity about the French connection, but much will be because Matrix is a fully-working professional system that can be used productively right now. If you're in one of those organizations that uses Slack for nearly everything, there is no good reason not to start looking at a migration to Matrix, because if the migration is successful, you can bring your messaging data back in-house. Free software is about the user having control, and Matrix honors that promise.

For anyone who'd like to see the whole talk, the video can be found here.

[We would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Brussels for FOSDEM.]

Index entries for this article
GuestArticlesYates, Tom
ConferenceFOSDEM/2019


to post comments

France enters the Matrix

Posted Feb 11, 2019 20:04 UTC (Mon) by philipstorry (subscriber, #45926) [Link] (8 responses)

I like the solution to AV requirements. Enterprises have very different priorities to the ones that security and privacy folks have - and I can't say that any side is absolutely right.
That solution seems like an elegant and reasonable way of doing it.

France enters the Matrix

Posted Feb 12, 2019 15:20 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (7 responses)

That's pretty much a direct port of the AV mechanisms smtp servers and web proxies use (in fact I'd be really surprised, if the AV function was not performed by systems initially designed for use with http(s) proxies).

Replace "Matrix" with proxy or "middlebox" and you'd have the usual people complaining it is an architectural mistake and scanning should be done by endpoints.

France enters the Matrix

Posted Feb 12, 2019 16:06 UTC (Tue) by Arathorn (guest, #101018) [Link] (4 responses)

Yes, the AV scanner is backed by ICAP, which is the standard built for scanning contents in web proxies etc.

However, the novelty here is that unlike HTTP or SMTP, the scanning is done in a manner that works in an E2E-encrypted-by-default network. I guess the equivalent for email would be:

* Have your MTA strip off attachments and store them in IMAP or some other content repository
* Refuse to let MUAs access those attachments other than by proxying them through an AV scanner
* If the attachment is PGP encrypted, then the MUA has to hand the scanner the encrypted keys to that particular attachment so that the scanner can do its job.
* The scanner runs entirely operationally isolated from the MTA.

As far as I know, nobody has ever built such a system for email, probably because E2E encryption is far from commonplace on email, and doesn't lend itself to scanning specific attachments (given PGP acts on the whole envelope, rather than each attachment being separately encrypted).

It's worth noting that whilst we're going to spec the API for doing this dance (i.e. formalise the stuff in https://github.com/matrix-org/matrix-content-scanner#api and add it to the matrix spec), this API will of course categorically *not* be compsulsory. It's just providing a hook for content scanning for those users (e.g. France) for whom it's a requirement, such that Matrix clients can perform such scanning in a consistent way.

It's an interesting debate as to whether this should be a network service in the first place, or performed clientside - for France, they have so many different AV services and requirements in play that limiting themselves only to clientside scanning is a no-starter.

France enters the Matrix

Posted Feb 13, 2019 13:18 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

And to avoid singling out Chromium devs

https://news.slashdot.org/story/19/02/04/1430259/mozilla-...

Browsers will fight to the death to protect website interests (advertising flows), but do not care about protecting user interests, and define mechanisms that let users deploy whatever protection engine they choose. And we all know the Internet is such a safe place and websites can be trusted not to push any malware user-side.

France enters the Matrix

Posted Feb 23, 2019 17:07 UTC (Sat) by notriddle (subscriber, #130608) [Link]

How is that comparable? It only affected Avast products, not all intercepting HTTPS proxies, and, based on what I'm reading in https://bugzilla.mozilla.org/show_bug.cgi?id=1523701, it's an actual bug, not an antifeature like the Chrome proposal. This isn't Firefox removing the ability to add your own root cert, this is Firefox bumping sqlite, causing a mismatch between its version and Avast's version that led to a corrupted cert database.

France enters the Matrix

Posted Feb 15, 2019 14:47 UTC (Fri) by gebi (guest, #59940) [Link] (1 responses)

> * If the attachment is PGP encrypted, then the MUA has to hand the scanner the encrypted keys to that particular attachment so that the scanner can do its job.

It would be awesome if it would support to give out just the ephemeral keys for this particular attachment and not just sending the keys of the user.

France enters the Matrix

Posted Feb 15, 2019 19:39 UTC (Fri) by rahvin (guest, #16953) [Link]

Isn't that exactly what's described in the article? Matrix gives the AV scanner the decryption key for that single attachment only, not for the session, not for the conversation and not for the user.

France enters the Matrix

Posted Feb 12, 2019 16:22 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (1 responses)

> That's pretty much a direct port of the AV mechanisms smtp servers and web proxies use .... Replace "Matrix" with proxy or "middlebox" and you'd have the usual people complaining it is an architectural mistake and scanning should be done by endpoints.

The problem with middleboxes has nothing to do with the way they communicate with AV services. Why not reuse that interface?

The main problem with MitM proxies—even when done "properly", with a private CA root certificate installed on the endpoints—is that it defeats all the security measures built in to the clients by replacing the original server's credentials with fake credentials generated by the proxy. The MitM proxy is also in a position to tamper with the content, not just passively observe the traffic and block content that triggers the filter. This could be done better if the client and the proxy worked together (share ephemeral decryption keys with a trusted and authenticated proxy but still require end-to-end encryption and authentication) but so far no one has implemented that.

The Matrix system does not suffer from these flaws since it only shares the files themselves with the scanning service. The service can't impersonate arbitrary clients or modify file content, and it can't see anything other than the files to be scanned.

France enters the Matrix

Posted Feb 12, 2019 19:18 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

Middleboxes work that way due to client design choices.

It would have been trivial to add a signature layer to https (much easier than the changes in http/2 or 3) to make sure content could not be tampered with, just blocked if the scanning detected evil things.

It would also have been trivial to separate cleanly the certificate used by the middlebox, from the certificate of the original website (after all as soon as you relay signatures, you can check securely those signatures have been generated by the private key of the original website, you do not need the same cert on the middlebox).

But, none of it can happen without client cooperation, and browser people hate anything that can filter what cloud giants intend to feed to users. So they've been quietly making sure the only setup they support is impersonating websites via certificate hijacking, while complaining publicly middleboxes are terminally broken.

Lately they've started interfering with filtering extensions that run within the browser
https://bugs.chromium.org/p/chromium/issues/detail?id=896...

France enters the Matrix

Posted Feb 11, 2019 20:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

How do they deal with message retention mandated by laws? Do they add a logging bot to each conversation?

France enters the Matrix

Posted Feb 11, 2019 20:55 UTC (Mon) by Arathorn (guest, #101018) [Link]

Matrix is effectively a conversation archive in its own right, so no bot is needed to store the messages themselves. In terms of handling freedom-of-information requests for E2E messages: this is an open question currently, given it would of course undermine the E2E encryption. IANAL, but perhaps one solution could be to legally obligate the user to surrender their keys in the face of a FOIA req? Or perhaps if the user archives their history (e.g. for search purposes) somewhere on a trusted device (e.g. a desktop client), this could be be used to service FOIA reqs. But afaik there isn't a conclusion yet on how to address this, and I haven't been involved any discussions about it. (Context: I gave the talk in the article)

France enters the Matrix

Posted Feb 12, 2019 10:06 UTC (Tue) by corsac (subscriber, #49696) [Link] (1 responses)

Can you point us to the laws you're referring to? I heard about such laws for the US, but I'm unsure about France.

France enters the Matrix

Posted Feb 12, 2019 10:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

https://en.wikipedia.org/wiki/Freedom_of_information_laws... ?

Commercial companies often also have to retain communications to comply with various legal requirements. Slack (that was mentioned in TFA) has support for it.

France enters the Matrix

Posted Feb 11, 2019 21:00 UTC (Mon) by Arathorn (guest, #101018) [Link]

Tom: many thanks for the comprehensive write-up! :)

In case anyone reading this feels interested in checking out Matrix, please be sure to check out https://riot.im/develop rather than https://riot.im/app. https://riot.im/develop is the next generation of the flagship Riot matrix client which I demoed during the talk - we're planning on releasing it as Riot 1.0 on Thurs Feb 14, so it's nearly ready to go, and hopefully gives a much better idea of the direction things are headed than the old app.

France enters the Matrix

Posted Feb 14, 2019 14:47 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] (2 responses)

How (if at all) would Matrix relate to Mastadon?

I have thought of moving away from the Usual Social Media toward something freer, but haven't made the leap yet.

France enters the Matrix

Posted Feb 15, 2019 22:17 UTC (Fri) by Arathorn (guest, #101018) [Link] (1 responses)

Mastodon is a particular client for the ActivityPub protocol. Matrix is a protocol in its own right. Mastodon gives you a twitter-like interface; most Matrix clients give you a Slack- or Discord-like interface. You could bridge between them though :)

France enters the Matrix

Posted Feb 16, 2019 15:10 UTC (Sat) by smitty_one_each (subscriber, #28989) [Link]

That was pretty much what I wanted to know. Thanks!

France enters the Matrix

Posted Feb 21, 2019 3:38 UTC (Thu) by donbarry (guest, #10485) [Link] (1 responses)

Is anyone else increasingly uncomfortable with the "we'll solve the certificate problem by deferring to centralized registrars that surely keep their keys private from state actors."

I mean, this is potentially not a risk if there is a recognizable way of communicating low-bandwidth fingerprints of the next encryption level, like ZRTP verification on voice. But note how WebRTC has done the same thing? And efforts to solve the problem are talked about and then, somehow, nothing ever happens with the standards.

It's enough to drive one paranoid.

France enters the Matrix

Posted Feb 22, 2019 23:10 UTC (Fri) by Arathorn (guest, #101018) [Link]

Well, the last half of the talk in the OP is discussing how we've implemented ZRTP-style verification for E2E, so that even if the servers can't be trusted, you still have trust through to the end parties you're talking to. So yes, we'd prefer not to be moving to conventional CAs, it's probably for the greater good right now (as fun as it'd be to be burning time reinventing CAs rather than building Matrix).

Some quick questions

Posted Feb 21, 2019 8:56 UTC (Thu) by callegar (guest, #16148) [Link] (3 responses)

- Does the matrix allow users to migrate from one homeserver to another? The problem with decentralized services is that often you cannot know well all the decentralized service providers to immediately make the best choice among them. Furthermore, their lasting through time may not be guaranteed.

- Does the matrix allow you to search users globally? I really think that one of the reasons for the success of things like skype or facebook is the fact that you can rapidly build your own network of people to communicate with by searching them (with them only accepting being searched). Without global searches, someone must first tell you how to find him/her.

- Do you need to configure the connection to a turn server in order to be able to use it from natted connections or is nat traversal autoconfigured (as it is in skype, whatsapp, etc)? For instance, one of the issues with ring/jami is that (at least in my experience) it cannot be used reliably on machines that are moving around like laptops/mobile phones as way to often you get an internet connection from which the application stops working.

Some quick questions

Posted Feb 22, 2019 22:08 UTC (Fri) by wiml (guest, #130596) [Link] (1 responses)

1: My understanding is that, no, a user account is tied to a homeserver, much like an email address is tied to an email provider; there are plans to make it possible to move or share user ids at some point in the future.

Rooms, on the other hand, are IRC-like in that they aren't associated with any specific server but exist on all servers which have a participant.

2: That's handled by "identity providers" which are sort of outside the core Matrix protocol, and provide a mapping from third-party identifiers (email addresses, phone numbers, personal names, or other identifiers) to matrix user IDs. I don't know what the state of play is for those, really. They exist and have client integration but I think the system is still more of a usability hack than a polished design.

Some quick questions

Posted Feb 22, 2019 23:15 UTC (Fri) by Arathorn (guest, #101018) [Link]

just to clarify on answer 2: identity servers simply map 3PIDs (e.g. email addresses) to MXIDs. They do not provide a directory service; homeservers provide this instead. The only exception is if the identity server implementation gutwrenchs into the rest of the protocol to override directory lookup APIs which would otherwise be provided by the homeserver.

Some quick questions

Posted Feb 22, 2019 23:13 UTC (Fri) by Arathorn (guest, #101018) [Link]

These are excellent questions.

1. Migration is currently a matter of using a script or other tool to invite your new account to all the rooms your old account was in, and then (optionally) parting the old account. It's a bit like migrating between IMAP servers, and generally cumbersome and suboptimal. We're trying to replace it by decentralising user IDs, so that user accounts can span multiple servers, at which point we get migration for free. This is https://github.com/matrix-org/matrix-doc/issues/1228.

2. There isn't a global user directory. Directories are instead done per homeserver, and search all users you share with a room with (or are present in public rooms existent on that server). In practice tends to work relatively well, though, as on a busy homeserver, many of the users you want to find will already be hanging out in public rooms (a bit like on IRC).

3. You have to run a TURN server, but we provide easy instructions for how to do so, and most of the docker or ansible setups automate this: https://github.com/matrix-org/synapse/blob/master/docs/tu.... We don't have the same problems that Jami has due to the thinclient nature. Even when we go fully P2P this shouldn't be a problem, given TURN & ICE is pretty straightforward (mainly due to pre-Matrix us being a VoIP stack shop...)


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds