Hacker News Reader

Comment by angus-prune | Hacker News Reader

I feel like I'm missing something.

If they introduced blanket MitM, it would only take one person to verify fingerprints for it to become public. You mention that people who verify fingerprints would be excluded, but I've no idea how you'd achieve that. My understanding is that proper fingerprint confirmation has to, by definition, be conducted out of band.

With any FLOSS everyone is trusting that another geek somewhere is paying attention to a particular piece of software and will raise the alarm if there is something wrong. And I do mean everyone. I don't think its conceivable that even the most paranoid, technically proficient user could verify the integrity of their entire technology stack.

View on HN

No, not really. There are actually ways to go around that. One person who does verify a fingerprint will get a real fingerprint. Or maybe they'll just show you same numbers as to your buddy, because they control both server and client software and users have very very limited resources to control what code is shipped to them via appstores.

You see, this is all a question of trust. The only threat against which the e2ee is useful is non-trusted server admin. But then signal fans paradoxically don't trust Signal to have their unencrypted communications and simultaneously trust them to have means to get access to their messages.

So in practice a personal/corporate email / xmpp server without any e2ee gives you a better level of security than using third party service like Signal with e2ww, because in that case the attacker will have to somehow gain admin access to your server to learn anything about your communications, while in Signal's case, even if they don't compromise your encryption, they still have means to know who you are talking with, when, your IP addresses, etc.

(and don't even let me started on that crap where Signal supposedly has no ability to know who is sending you a message - it all can be logged on server side, and we're not trusting the service operator, right?)

Tldr: insisting on e2ee while fully trusting third party infrastructure is double-think at its best. If you want to be safe, use self-hosted servers. Which brings you to federation. :-D

> One person who does verify a fingerprint will get a real fingerprint. Or maybe they'll just show you same numbers as to your buddy, because they control both server and client software and users have very very limited resources to control what code is shipped to them via appstores.

The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it. If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.

Nobody claimed E2EE was the be-all and end-all of security; only that it's an improvement over having to trust a 3rd party. This is because everything else being equal, the less components you trust, the better security-wise. So given a network operator, if you can choose between trusting them or not, you'll be better off not trusting them. That's why E2EE is better than no E2EE.

Finally "use your own server" seems like the perfect solution if you're only talking to yourself. To take the email example, just because you trust gmx.de doesn't mean you want to trust mail.ru, but it seems that you're either suggesting that the trust propagates between servers in the same federated network (obviously not the case), or that you can just demand your recipients use the server you chose, ending up with a centralized silo within the federated network, which is itself a contradiction.

> The fingerprint is computed at key exchange, you can't change it after the fact without warnings about it.

Compromised apps can very much silence such warnings.

> If you assume the clients are compromised, E2EE or federation or other network properties won't help, so this discussion is meaningless.

Federation absolutely helps. If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced, especially when there are many competing apps. If you run the server yourself, the chance to be compromised becomes infinitely small.

> Compromised apps can very much silence such warnings.

Again, this is not a useful take since this equally applies to any other app, federated or not.

> If you get your service and your (preferably open-source) software from different sources, the chances that you'll be attacked via software backdoors is significantly reduced

No, you just need one of the trusted component to be compromised to lose your security guarantees. You're suggesting to increase your attack surface instead of reducing it.

> this equally applies to any other app, federated or not.

Wrong. If your client software and service come from different vendors, it is by far harder to attack your privacy via compromised apps - especially if there are multiple vendors of client software and reputable open source repositories like f-droid who build apps from sources.

> No, you just need one of the trusted component to be compromised to lose your security guarantees

While this looks to be true, in real world practice it is completely not so. It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app - especially if the attacker knows which account should be affected. And in a federated environment the attacker might not even know your account name.

Whether the protocol is federated or not (which is the topic of the article) doesn't say anything about the clients and how they're distributed. Even with respect to Signal, which is open-source, can be rebuilt from source and has several clients, including 3rd-party ones.

> It is far harder sneaking a backdoor into a F-droid app, with far bigger reputation risks, than doing it in Signal app

We'll have to agree to disagree.

Reply on news.ycombinator.com