[HN Gopher] E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sd...
___________________________________________________________________
E2EE vulnerabilities in matrix-js-sdk, matrix-ios-sdk and matrix-
android-sdk2
Author : delroth
Score : 42 points
Date : 2022-09-28 15:59 UTC (7 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| martinralbrecht wrote:
| Write-up of the vulnerabilities and attacks by research team who
| reported them: https://nebuchadnezzar-megolm.github.io/
| jimmygrapes wrote:
| One of my biggest pain points in setting up an unfederated
| homeserver for my friend group was trying to figure out how to
| not have so much access as the server admin. I am nowhere near an
| expert at cybersecurity or cryptography or sysadmin things, but I
| had a strong sense of "I shouldn't be allowed to do this" - for
| example, when users had difficulty verifying their sessions, I
| was able to simply click a link in Element to "manually verify"
| the user on behalf of the entire encrypted group. This was
| several years ago and the verification flow seems to have
| improved since then, but that gave me some misgivings.
| omegacharlie wrote:
| Certainly glad these vulnerabilities were disclosed and patched
| without exploitation by malicious entities.
|
| However. Does anyone else feel uneasy about Matrix end-to-end
| encryption and how some people justify its provenance by
| asserting it is the same encryption as Signal despite the
| homebrew implementation by Matrix having obvious differences to
| attempt to accommodate multi-device support among other features?
| jimlongton wrote:
| lmm wrote:
| > However. Does anyone else feel uneasy about Matrix end-to-end
| encryption and how some people justify its provenance by
| asserting it is the same encryption as Signal despite the
| homebrew implementation by Matrix having obvious differences to
| attempt to accommodate multi-device support among other
| features?
|
| Signal's implementation (assuming it's what they say it is) is
| equally "homebrew"; it was derived from OTR but it's not the
| same protocol, and things like the server-assisted initial key
| exchange are both bolted-on and often omitted from security
| analysis in a way that I find very dubious.
|
| (Frankly the only crypto protocols mature enough that I really
| trust them are PGP, TLS, and maybe SSH, but I don't think any
| of them are suitable for a use case where you want to avoid
| non-repudiable signatures)
| Syonyk wrote:
| > _In summary, we found that Matrix and its flagship client
| Element as deployed provided neither authentication nor
| confidentiality against homeservers that actively attack the
| protocol, i.e. its end-to-end encryption fell short of the
| security guarantees expected from it._
|
| While... frustrating to see that these vulnerabilities exist, I'm
| happy to see that at least the bulk of them require a malicious
| homeserver.
|
| And Matrix makes it easy(ish... if you're a sysadmin type...) to
| _run your own homeserver._
|
| I've generally assumed in the past couple years of running Matrix
| that if someone else controlled my homeserver, they could
| _probably_ do something malicious, which is why I run my own, on
| hardware I control. Perfect? No, but it 's a sure bit better than
| running on some major tech company's chat infrastructure.
|
| The main problem is I don't know of anything better, short of
| just giving up and going back to IRC - which, even with znc,
| isn't nearly as nice as Matrix/Element/etc, though it's far
| lighter to run at all ends. And IRC is mostly just plaintext
| (yes, there are some plugins that help, no, they don't really
| work reliably in my experience with them).
|
| I'm open to being convinced otherwise, but even with this bit of
| a charlie foxtrot going on, I still think Matrix is probably the
| least-awful of modern chat options, if you can run your own
| homeserver.
| palata wrote:
| If you run your own homeserver and talk to people on
| homeservers you trust, that's fine. Now chances are that you
| talk to people who are not on your server, right?
|
| I like Matrix a lot, but the way I use IRC: for public rooms.
| For private discussions, I use Signal Messenger, which seems to
| get e2ee right, and does clever stuff to reduce their access to
| metadata (pretty sure matrix homeservers have to know in which
| rooms I am to fetch my messages, right?)
| Syonyk wrote:
| My server is federated and seems to work that way, but...
| mostly, I talk to people on the server, or via my bridges.
|
| As far as Signal goes, my main concern there is just how
| centralized it is. I would assume "anyone with the interest
| and ability" is monitoring messages going to and from Signal,
| which would be at least somewhat easier than monitoring stuff
| to all the random homeservers out there.
|
| ... fundamentally, I'm not sure the internet is trustworthy
| at all, anymore. :(
| omegacharlie wrote:
| Is Synapse not infamous for its memory consumption and losing
| sync with other homeserver(s)?
| IceWreck wrote:
| Well dendrite is beta software. Ive been running it for
| almost two years now and its close to synapse in
| functionality now while being super lightweight compared to
| it.
|
| And then there is Conduit which is written in Rust
| neiljohnson wrote:
| Synapse has come a long way in the past few years both in
| terms of reliability and resource usage.
|
| The following give some details:
|
| * https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-
| sca...
|
| * https://twitter.com/matrixdotorg/status/1434912387933560837
|
| What's more the Synapse team recently announced support for
| Rust meaning that various performance critical sub-components
| can be ported over from Python.
|
| * https://matrix.org/blog/2022/09/09/this-week-in-
| matrix-2022-...
|
| As mentioned elsewhere Dendrite (Go) and Conduit (Rust) are
| both entirely useable albeit beta implementations.
| Syonyk wrote:
| It's far heavier than I'd prefer, yes.
|
| However, I've got my own box colo'd, so I can give plenty of
| resources to the VM it runs in, and it seems to hold up just
| fine in operation.
|
| Realistically, the bulk of my traffic is to other users on
| the same homeserver, so I'm less likely to notice
| sync/federation issues. A few people do talk across different
| servers, though, and would bug me if something was broken. It
| seems to be fine, just very CPU and RAM heavy for what a chat
| server ought to be using in my view of things.
|
| I won't claim it's perfect, but it does provide for a robust
| and modern-ish chat service that's not reliant on the good
| will and data monetization of major tech companies.
| jeroenhd wrote:
| Quite bad vulnerabilities in some cases, but the fact none of
| these bugs were on the protocol level is a good look for the
| ecosystem as a whole.
___________________________________________________________________
(page generated 2022-09-28 23:02 UTC)