Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I won't recommend Signal anymore

sandervenema.ch

Post reply on HN
Print view View original

271–280 of 350 posts

Re: Why I won't recommend Signal anymore

#271

Post by hannob »

upofadown wrote: post #249
hannob wrote: post #203

Earlier quoted context omitted.

I think Conversations is probably getting a lot right, but you also mention its biggest flaw: > do multiple types of encryption including OTR and OMEMO Oh and it can also do something else: no encryption at all. That's the problem with XMPP: The user is faced with three different encryption modes, none of them is the default. There shouldn't be multiple types of optional encryption. There should be one that works and…

In practice you always get TLS. That's really all you need if you trust the server. Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of…

TLS on the s2s side is unauthenticated. Therefore TLS only protects you in a situation where both users are on the same server and trust it.

Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.

Re: Why I won't recommend Signal anymore

#272

Post by md_ »

angry_octet wrote: post #204
mst wrote: post #115

Earlier quoted context omitted.

Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/etc.

Although the masking effect may be useful, my immediate thought was how much extra code and buffer overflows had been added to the client. Android doesn't have any sandbox mechanism like pnacl to contain such code.

In addition to Moxie's comment about using Java, you're more broadly confused, I think.

Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was.

Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.

Re: Why I won't recommend Signal anymore

#273

Post by Drdrdrq »

bitmapbrother wrote: post #227
clumsysmurf wrote: post #8

Unfortunately, Google has made it (almost) impossible to wake up the phone via some external event without using its proprietary GCM. Even though GCM is not part of AOSP, it has unique status on the platform that can't easily be replicated (without recompiling the kernel, etc like the article mentions). Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the…

>Unfortunately, Google has made it (almost) impossible to wake up the phone via some external event without using its proprietary GCM No, fortunately Google has made it impossible for apps to abuse waking up the phone.

No. Apps can abuse waking up the phone all they want (and as much as user lets them), as long as they do it via Google's servers. What they can't do is bypass GCM/FCM. Nothing to do with UX.

Re: Why I won't recommend Signal anymore

#274

Post by exo762 »

mirimir wrote: post #264
moxie wrote: post #251

Earlier quoted context omitted.

I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people wi…

Thanks for the clarifications. > First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names). This is very good. > However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena] Good, so Open Whisper…

> Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?

I'll try to answer to the best of my knowledge (I'm not associated with project, I'm just a happy customer).

Does your ISP know that you are communicating with Signal servers? Yes, IP addresses.

Does it know to whom you are sending messages? No.

Does Google know you are using Signal? Yes.

Does it know whom of your contacts use Signal? Yes, because they have a full list of your contacts and they know if someone has installed Signal.

Does Google know you've sent a message? No.

Does Google know that you are receiving a message? Sometimes, because Signal servers ping your device via GCM with "wake up".

Does Google knows who from your contact list send this message? No, unless you have only one contact who uses Signal.

Can Google infer from pings who is communicating with whom? Yes, although pings are needed only if app has disconnected from server, and this severely limits usefulness of this technique.

Where else may any metadata coming from usage of Signal be? Nowhere.

As for Google having your contact list... Take a look into Flock.

Re: Why I won't recommend Signal anymore

#276

Post by md_ »

Drdrdrq wrote: post #266
tptacek wrote: post #151

Earlier quoted context omitted.

GCM has practically nothing to do with the security/privacy of Signal, but it is the #1 "concern" that people who don't understand cryptographic messaging security feel they must relate about Signal.

Couldn't attacker (NSA) infer times of phonecalls/messages from GCM? This might not seem like much, but it is another piece of metadata...

What's the threat? An attacker who can observe only traffic on the wire (e.g. an ISP) probably gains nothing from observing GCM, since a) it's probably hard to distinguish different types of GCM messages and b) the attacker can just observe traffic to the Signal servers directly.

An attacker who cannot generally passively intercept (but not decrpyt) traffic on the wire but can passively intercept traffic to/from the GCM servers would be foiled by not using GCM, but that's a very narrow case.

Re: Why I won't recommend Signal anymore

#277

Post by md_ »

nextos wrote: post #166
tptacek wrote: post #162

Earlier quoted context omitted.

That's one of several things that are reasonable not to love about Signal. Criticism intended to urge Open Whisper Systems into changing their Signal policies are reasonable. A statement that someone would recommend less secure messaging solutions to investigative journalists is another --- something I find much harder to be supportive of.

Nobody is saying Signal has less secure cryptography than others. But being able to run it in CopperheadOS without loading microg would make the whole setup much more secure. And one cannot dissociate both things.

What confuses me about the post is that the author does not make it clear if he recommends that journalists run CopperheadOS. It sounds like he does not recommend this, but rather opposes Signal's dependency on Play on general principals.

But if his journalists are using Android or iOS anyway, there's no practical advantage in Signal not depending on GCM or the Play Store, and some real disadvantages (like less secure updates). So the whole complaint seems like rather contrived to me.

(I would contest the claim that running a massive, not-practically-auditable open source OS is actually any more secure than running iOS or Android+Play Services, but whatever.)

Re: Why I won't recommend Signal anymore

#278

Post by jhasse »

exo762 wrote: post #274
mirimir wrote: post #264

Earlier quoted context omitted.

Thanks for the clarifications. > First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names). This is very good. > However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena] Good, so Open Whisper…

> Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages? I'll try to answer to the best of my knowledge (I'm not associated with project, I'm just a happy customer). Does your ISP know that you are communicating with Signal servers? Yes, IP addresses. Does it know to whom you are sending messages? No. Does Google know you are using Signal? Yes. Does it know whom of…

Does Google know you are using Signal?

Does it know whom of your contacts use Signal?

Does Google know you've sent a message?

Does Google know that you are receiving a message?

Does Google knows who from your contact list send this message?

Can Google infer from pings who is communicating with whom?

Yes to all of those, because they have root on your phone.

Re: Why I won't recommend Signal anymore

#279

Post by jhasse »

jaboutboul wrote: post #199
Kliment wrote: post #158

Earlier quoted context omitted.

My main concern with GCM is that it's unavailable on fully open OS builds, so requiring it compromises the security of the device as a whole, rather than Signal in particular.

Use iOS

Parent is concerned about one part of their OS not being open-source. iOS is closed-source.

Re: Why I won't recommend Signal anymore

#280

Post by catdog »

giancarlostoro wrote: post #226
majewsky wrote: post #223

Earlier quoted context omitted.

I have a virtual server (1 CPU + 1 GiB RAM) running nginx, murmur and Prosody. free(1) reports 80 MiB used memory, thereof 10 MiB for Prosody. (I just have one active account, though: myself.) So unless you're planning on hosting hundreds or thousands of users, you should be fine IMO.

I had not even 3 users... I was running a Java one, looks like Prosody is worth it's salt. Does it support E2E and other features that Conversations supports? :) Edit: I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.

You probably used Openfire, known to be a memory hog and a bit unstable. Simply go for prosody and you should be fine (ejabberd should also be OK). Some newer XEPs which you may want to have with Conversations are not supported OOTB in prosody (yet) but there are plugins distributed separately [1][2].

[1] https://modules.prosody.im/ [2] https://prosody.im/doc/installing_modules

Post reply on HN