Comment by Arathorn | Hacker News Reader

Comment by Arathorn | Hacker News Reader

Parent Full thread

We (the matrix team) addressed the implementation vulnerabilities discussed here back in September: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en....

The only pending work is switching to TOFU (trust on first use) and client-controlled room membership. Currently users get warned if a malicious device or user gets added to a room by a malicious server (assuming users in the room are verified). However, rather than warning, we could block it outright - but this is nontrivial as it means clients have to independently replicate the group membership semantics the server currently handles, which are complicated in a decentralised environment.

https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift membership to be controlled clientside, and https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the work ongoing to shift to TOFU.

Meanwhile, this work is blocked behind switching to matrix-rust-sdk-crypto across Element on Web, iOS and Android, so we only fix this in one (audited) place - and can also build on the newly audited vodozemac implementation of Matrix’s encryption: https://matrix.org/blog/2022/05/16/independent-public-audit-.... This work is going well though - I for one have been dogfooding ElementR (Element with rust-sdk-crypto) on iOS as my daily driver for the last week, and we should be releasing it shortly.

To paraphrase another comment on this; if I have to trust the server for Matrix E2EE to work, why don’t I just use Slack? The whole point of E2EE is so you don’t have to trust the server.

And a “warning” that says something like “your group chat has been compromised by someone with access to the server or it might just be bob bought a new phone” is laughable as a status quo.

The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever.

Then, if you've done that, and an unverified device is added to the conversation, the warning shows up and explicitly means "your group chat has been compromised" - just like a big red TLS warning on a webpage means "this certificate is bad". It does *NOT* mean that "it might just be bob bought a new phone"; if bob bought a new phone, he'll have verified it when he logged in, and so the warning doesn't show up.

Anyone who actually uses Matrix will be familiar with the fact that it's pretty rare to see a big red X on a user who you've verified, and when it happens, you go ping them to ask wtf is going on - much like you'd ping the webmaster of a site whose TLS certificate is bad. This is why the Matrix community is not up in arms about this "vulnerability" - it is literally following the intended design, right from the point that we announced verification back in https://element.io/blog/e2e-encryption-by-default-cross-sign....

Now, this design can absolutely be improved on - at the least, we could go back to freezing the room whenever there's an unverified device, forcing the users to decide how to flush out the old device. Or we could switch to TOFU, and block unverified devices by default. But we've chosen to prioritise migrating the clients onto a single E2EE codebase (matrix-rust-sdk-crypto) first, so we do that work in a single place, rather than in quadruplicate across matrix-{js,ios,android,rust}-sdk.

> The point is that if your threat model cares about interception, you have to verify the identity of users out of band - same as Signal or WhatsApp or whatever.

I’ve read your blog posts and this comment, congratulations it seems to have satisfied most people. Howerver it is NOT the same as Signal. Signal servers cannot just add a device to a group chat.

I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.

To me Matrix isn’t secure, the organizations responses to these disclosures has been poor and the “fixes” weak.

You are completely misinterpreting my quote, which makes me question whether you are acting in good faith.

Totally agreed that Signal servers cannot just add a device to a group chat.

What I saying was: in any system, you have to verify users for security in general. Having verified users in Matrix, you then get a massive red warning if an unverified device is added to their accounts. Given we have cross-signing (i.e. users are heavily encouraged to verify their own devices when they log in), you can be sure that such unverified devices are malicious and take appropriate action.

The obvious thing we could do is to go one step further (as we used to, until we backed it out in https://github.com/matrix-org/matrix-react-sdk/pull/3837) and stop messages from flowing until the unverified device has been dealt with. Even better would be to make group membership controlled by the clients, so the server can't add devices at all. And we're working on this, as part of shifting the implementations over to the audited matrix-rust-sdk-crypto implementation to avoid having to solve the problem in quadruplicate.

> I would challenge you to get one reputable cryptographer to back what you’re claiming about these vulnerabilities and your proposed fixes.

Hopefully someone will pop up here and confirm that I'm not talking shit :) Failing that, you'll have to wait for the next Least Authority audit - we have another independent public audit queued once this wave of work finishes to address the "To me Matrix isn't secure" polemicists. You can see the last one (on the crypto layer, rather than the group membership layer) at https://matrix.org/blog/2022/05/16/independent-public-audit-... fwiw.

It’s encouraging to hear that you’re getting an audit of the new approach.

Reading over the new design doc for authenticating membership events, and the Github comments, it feels like this is a case for some sort of model checking or automated theorem proving. Manually verifying that the new system does everything we want seems… tough.

Here I'll point out that Matrix had audits commissioned prior to this research as well. Audits are a good thing, but one reason the previous audits didn't hit on this stuff is that the scope of the audit was sharply limited.

Totally agreed. We didn’t have the $ to do more than libolm at first, and then we did vodozemac in May. That one was the first of 4 planned audits, the rest of which go up the rest of the stack (respectively matrix-rust-sdk-crypto, matrix-rust-sdk, and then end-to-end across the whole stack). It is very frustrating we couldn’t do the rest of the stack sooner - and this hopefully explains why we are consolidating on matrix-rust-sdk prior to getting it audited.

Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?

> Ironically, the drama over this paper is now putting funding for the other audits at risk, however - as who wants to fund a project with a bunch of loud infosec folks declaring it shit?

I'm not familiar with how the funding here works - can you describe the process by which audits would be abandoned as a result of internet commentary? Who is threatening to withhold funding for future audits? From my outsider's perspective, that would seem like _incredibly_ poor decision-making on behalf of the Matrix folks.

The process is:

* Audits cost $$$K

* The Matrix project doesn’t have pots of money sitting around to spend on audits. We get around $8K/month of donations on Patreon, which currently doesn’t even cover the running costs of matrix.org.

* Therefore, to get an audit done, we need to find a someone who is so excited about Matrix that they’ll fund it. For instance, the most recent audit was funded by Gematik, the German healthcare interoperability agency.

* However, the reason that folks like this get excited about Matrix is because they want a secure decentralised open communication platform. If the perception of Matrix shifts that its security is “killed dead” or other such hyperbole due to the infosec community reacting to the overclaims in the paper, then it obviously undermines that interest in Matrix. Who wants to use a protocol whose security is declared dead by cryptographers? And so who would want burn money funding audits?

This may sound dramatic, but unfortunately it’s really how it works. Just as academic papers rely on presenting the most dramatic interpretation to get attention and boost their visibility and help them get funding… similarly, open source projects get disproportionately harmed by dramatic overclaims.

It would behoove you to stop saying that the paper "overclaims" things. Maybe you believe I've "overclaimed" things, by saying that the paper killed your protocol as dead as TLS 1.0. I stand by that argument, but the paper's authors made no such claim. It's a dry, detailed, factual paper that just happens to rattle off a bunch of vulnerabilities both in your protocol and in Element's implementation of it.

Thank you for the clarification! Appreciate the candor here re: Element not being able to afford audits on its own. I get now why you might perceive commentary about security research as an existential threat.

For whatever it's worth, the specific thing you're doing with calling the discussion hyperbole and "overclaims" makes it harder for me to take you seriously.

Element is a client, matrix is a protocol

I don't really know where you get off on telling people you don't take them seriously

Can't Element (the company) fund audits?

Element doesn't have the $, thanks to footing the bill for most (90%+) of the core Matrix work on behalf of the rest of the Matrix ecosystem.

Element is probably already footing the bill for the main matrix.org server + they really need to improve their clients, and that is from a users perspective more important than a security audit.

What is the cost of a comprehensive audit?

A quick comment on this, we did address this in our paper:

"In environments where cross-signing and verification are enabled, adding a new unverified user adds a warning to the room to indicate that unverified devices are present. However, it is possible for a homeserver to add a verified user to rooms without changing the security properties of the room. This allows a colluding homeserver and verified user to eavesdrop on rooms not intended for them. In other words, the warning regarding unverified devices is independent to whether the device is intended to participate in the specific room. Finally we note that users may, of course, simply ignore warnings." https://nebuchadnezzar-megolm.github.io/static/paper.pdf

the paper and this design decision by Matrix teams has recently been discussed at length in an SCW podcast (paging Thomas H. Ptacek). One of my fav episodes yet. Very sobering unfortunately.

https://securitycryptographywhatever.buzzsprout.com/1822302/...

All the pointing-and-laughing derision on the podcast seemed pretty toxic, tbh. Rather than all the "oh look how stupid Matrix are" schtick, it might have been even more interesting and informative (and less obnoxious) to get the other viewpoint and understand why we don't consider server-controlled group membership to be catastrophic in practice... as per my explanations elsewhere on the thread.

Honestly, this whole thing shows the infosec community at its worst: optimising for sensationalism/drama/press-coverage over constructive criticism and research. And it's particularly grating when the target is a mission-driven non-profit FOSS project, rather than a bungling megacorp vendor or whatever. Meanwhile things like OpenSSL RCEs or even Signal RCEs like https://thehackerblog.com/i-too-like-to-live-dangerously-acc... fly past without the researchers doing the podcast circuit(!)

By all means, jump on an episode with us, and give us the other side.

We're offensive cryptography (in the "offense" vs "defense") people, and have a warm, effusive enthusiasm for offensive research results. It stings to hear enthusiasm about attack research that impacts your project, but that's not the intent, of course. You'd hear exactly the same tone if we were talking about some hypothetical system.

Meanwhile, I can't disagree more strongly with your last paragraph. This is a sensational result. It's the most impactful result ever generated against a secure messaging protocol. It deserves whatever attention it can get. To date, I think the Matrix project has been quite effective at diverting attention away from the results.

I think you'll find that even non-event OpenSSL vulnerabilities get multiple bites at the HN front page. Every serious OpenSSL vulnerability in the last 10 years has gotten vastly more attention than this research.

We do this podcast under our own names, with our own professional reputations attached, and we should all be able to at least agree that we've got a lot invested in those reputations. If we record an episode with the Matrix team giving their side and treat you unfairly, people will hear it, and that will reflect poorly on us. Apart from us just not being, like, monsters, our incentives are also aligned to give you a fair hearing.

Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.

> Let's do an episode where you explain why this isn't as big a deal as we made it out to be! We're game.

Sure, sounds like a plan. In order to actually present a balanced view and not end up with another one-sided episode like the last one, you might want to get the researchers involved again too.

And to be clear: my biggest issue with the podcast was the amount of (literal) laughing and derision and general "oh look how stupid they are" obnoxious attitude, rather than the claims of the paper. Our only point of contention with the paper is over whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.). From a purely theoretical perspective: yes, it's a bug that a server can add ghost devices at all. From a practical perspective, please show me the attack where a server or HTTPS MITM can add ghost devices to a verified user without the malicious user and room turning bright red like a TLS cert warning.

Anyway, once we've landed the TOFU and client-controlled-membership work (which is already overdue) I'd be very happy to come on the show to explain how the mitigations work, where the issues came from in the first place, and why we think the paper seriously overclaimed (which is a shame, given the actual implementation vulnerabilities were great research).

Thanks for the invite! :)

I'm absolutely rooting for you doing an episode together. please listen to some other episodes before dismissing the content because of format - they're fantastic.

> whether server-controlled group membership is as big a disaster as you claim it to be, given you have to verify users to avoid interception anyway, at which point malicious devices are clearly flagged so clients can take evasive action (e.g. big red warnings, or refuse to encrypt messages in that room, etc.).

I really would love to see this addressed: the UE of crypto. In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings unless you're intention is to cater to only those of us who still have a GPG FPR in their ~/.signature

It. Does. Not. Work.

"Web of Trust" was a great idea but failed to scale (when was the last time you received a gpg encrypted mail from anyone).

Signal served us well until SGX.fail (https://sgx.fail), and it's why something like Matrix deserves to succeed.

Systems get better under pressure (when questioned) so I really hope y'all get a chance to talk.

> In 2022 we should absolutely refrain from leaving the decision to the user w.r.t if it is safe or trustworthy. Users suck. Don't trust users to look at warnings

Yup, totally. Which is why we are addressing it. The current behaviour dates back to 2016, and reflects the transition from plaintext to e2ee matrix which happened between then and now - much as TLS browser warnings have evolved in the same timeframe, and eventually being replaced by HSTS and friends. It doesn’t mean that the previous behaviour is catastrophic though - just as browser warning semantics doesn’t kill TLS.

Hit us up! You can email me at the address in my profile, and David and Deirdre will work with y'all to figure out a schedule.

Will do. Just want to land at least the tofu work first, as fun as it’d be to sit there saying “coming soon” on loop.

Reply on news.ycombinator.com