Back

@waeiski the elephant in the room there, is that #Signal servers are said to be mostly on Amazon AWS.

Maybe they are thinking of an alternative like #Deltachat (with a posteo.net email address, or other such auto-encrypted email address not hosted on US soil)? This alternative exists right now, it's just that posteo.net addresses are not free to rent. Merely inexpensive. It's cross-platform: is said to be stable, even on #MacOS and #iOS or #iPadOS

@sbb @waeiski dang, is #Signal really using #AWS ?

@tortie @sbb @waeiski Yup :/ @Mer__edith Any chance of diversifying away from AWS? Main reason I brought this up is for anti-Amazon reasons, not privacy issues.

@chiraag @tortie @sbb @waeiski @Mer__edith This is not "the elephant in the room" and neither is deltachat a reasonable alternative. The metadata that delta leaves is *significant* and can be tied to an individual. That's why it is crucial to use a "trusted" mail provider, because delta doesn't use any of the advancements in cryptography of the last decade.

The data traces Signal leaves on AWS is not personal data, the metadata is minimal and they make efforts to reduce it further. AWS is still a problem, but one of Availability (what if Bezos cancels his contract with them?).

Please do not compare them based on where they store the data, if the amount and kind of data stored is very different.

@ljrk @chiraag @tortie @waeiski @Mer__edith I wish that the #EU would clarify its stance regarding #Signal: *is the AWS hosting problematic for them or not*? Let's assume *not OK* for a minute.

As to a Signal alternative, I *wish* I could recommend #XMPP over #Deltachat today. *AFAIK*, in XMPP, #OMEMO does perfect forward secrecy/double-ratcheting - but alas, the #iOS and #MacOS clients aren't the greatest at present. That lack of all common OS' having feature parity (very reliable notifications, Reactions, etc.) makes me hesitate in recommending XMPP for *everyone* today (but it's great for geeks).

Whereas Deltachat at least has usability parity for features across each OS it supports (which I feel users would highly expect *first*, before demanding a more modern encryption). Yes, autocrypt has no perfect forward secrecy, etc. and other metadata-related criticisms. But Deltachat is simple enough to learn, *allows servers to realistically be used in the desired country*, and works on all the common platforms. It's a decent choice for *today*, as a well-rounded choice (where tradeoffs must be made somewhere). And once the XMPP clients get better (in MacOS/iOS), I'll recommend XMPP as a goto *then*.

@sbb @ljrk @chiraag @tortie @waeiski @Mer__edith Can somebody please explain, which "other metadata-related criticisms" is related to delta chat?

@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Think of Delta Chat is PGP-encrypted mails, because that's the core of the protocol. Meaning: The server ultimately knows all senders/recipients, when messages where sent, etc. It also is in the perfect position to carry out sophisticated MitM attacks.

@ljrk @sbb @chiraag @tortie @waeiski @Mer__edith Ok but this is also true for most messengers and even worse for centralized messengers like signal because you can not change to trusted servers in signal

And Delta Chat forces user verification (at least if you use a chatmail account) so I see no specific MitM vulnerability?

@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith No, that's simply wrong. That data is *not* available to Signal and thus it's not worse because the server doesn't know such data in the first place.

MitM is possible because you have servers that relay messages. End-User verification is neat, but only prevents impersonation, not all MitM attacks.

@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Because they don't have that data. That's not how signal chats work, the server is mostly a rendezvous server, with the actual message sender and recipient not available to the server.

This is key and different to Delta. Where you can use a passive MitM to get a lot of meta data – without breaking the encryption. Feds could literally get a copy of the encrypted messages without you noticing. While encrypted, this is terrible enough already, because recovering a static key is often very realistically possible for them. And since delta doesn't use forward secrecy, they can just store all those message and hit you over the head years later – and decrypt everything. It's fucked, absolutely dumb and irresponsible to use this for activist purposes. It's a fun toy project but has no space in infosec.

@ljrk @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith

You very confidently write things that are not and/or only partially true.
- Signal's server sees the recipient of every message.
- Signal's server does not see the sender of messages if sealed senders is used. However, sealed senders can't be used on the first message to a user. Also the server can always request the client to resend a message without sealed sender without a warning to or a confirmation from the user.

@ljrk @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
If desired, it would be trivial for Signal's server / AWS to record:
- Every sender/recipient pair for messages that don't use sealed sender
- Disable sealed sender selectively for some messages (e.g. based on recipient, sender's IP address or just randomly distributed)

If we assume AWS to be malicious, they could already know at this point a) who ever chatted with whom on Signal and b) messaging frequency and timings of targeted chats.

@ljrk @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
Signal also uploads the phone numbers in the contact books of a user's phone. Yes that's optional, but a very large number of users has it enabled. And yes, Signal makes an attempt to be privacy-friendly here by using Intel SGX, which means *they* can't access it, but Intel (and thereby likely the US gov) can.
This feature even affects non-Signal users and users that disable it, as they likely still show up on contact books of others.

@pixelschubsi @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Yes, an actively compromised Signal server does see message routes – however that's the same for XMPP. I was sloppy in describing the difference, but I honestly grew tired after such load of bullshit here.

A Signal server that's popped at one point in time does not have routing history and sealed sender then prevents future chats getting compromised. AFAIK clients would notice if the server doesn't allow sealed sender suddenly.

It's still suboptimal how Signal is positioned w.r.t. geo-political threats – but the named alternatives are so much worse in all these aspects, it makes me cry.

IIRC Signal uses bloom filters for the phone matching thing but I may be mistaken there.

But at worst govs know phone numbers you have (which is not enough for anything) or who you wrote with once (neither) while stopping you to be able to covertly continue messaging (attack against Availability). The latter thing is IMHO the worst of them, and Signal In-Availability is the main threat I'm seeing.