decentralized

1966 readers

1 users here now

This is a community for the discussion and news about the decentralized web, software, privacy, and related topics.

Rules: be a good human being

founded 4 years ago

MODERATORS

SirLotsaLocks@lemmy.ml

Am making a P2P messaging protocol and hope for protocol review (git.sr.ht)

submitted 2 years ago by Yujiri@lemmy.ml to c/decentralized@lemmy.ml

2 comments fedilink hide all child comments

cross-posted from: https://lemmy.ml/post/93192

It's not finished or anything, but I want potential vulnerabilities brought to my attention as soon as possible.

you are viewing a single comment's thread
view the rest of the comments

[–] wolf480pl@mstdn.io 0 points 2 years ago (1 children)

@Yujiri is this protocol meant to be used over plain TCP, or over TLS? is MITM part of the threat model?

[–] Yujiri@lemmy.ml 0 points 2 years ago

Oh, hi. First you should know this post is old and the protocol has been drastically reimagined since. It's now a federated thing, combining inspiration from email, SMS, and Signal.

To answer your question, though: TLS isn't currently meant to be involved as I don't want to have two separate crypto systems floating around (which require 2 different crypto libraries as dependencies) and feel that TLS is not suitable due to how many irrelevant aspects it contains (metadata and signatures on certificates, trust chains, etc). All messages are end-to-end encrypted and users are identified by public keys so there's no way for a MITM to actually compromise message content. It is possible to MITM someone's connection to a homeserver. Things the attacker could achieve with this:

Preventing your messages from being delivered (by inserting themself as the recipient's homeserver), and making you falsely think they have been delivered
Preventing you from receiving messages sent to you, by inserting themself as your homeserver, and downloading your messages and discarding them.
Learning the number of messages sent to you and when.

The reason I haven't bothered to try to prevent these is because I think the given that the attacker is able to MITM your connection makes them more or less inevitable. Consider: an attacker could also achieve #1 by just taking down the recipient's homeserver (eg. via DDOS) or your ISP, etc. (Caveat: the attacker wouldn't be able to fool you into thinking the messages were being delivered, but I don't consider that important.) They could do #2 and #3 by simply compromising your homeserver. In fact, they could probably achieve #3 by just being one of the routers between you and your homeserver and analyzing traffic statistics.

Really securing the connection between client and server would require some way of knowing what the server's key is supposed to be, such as certificate authorities or DNS records, neither of which are really secure systems. TOFU seems the most promising possibility. We might end up adding that to the protocol.