Live data from Hacker News

I don't trust Signal

drewdevault.com

171–180 of 473 posts

Re: I don't trust Signal

#171
post #155

Earlier quoted context omitted.

Security wise, Apple iOS is superior in any possible aspect to Android. Forensics people never complain how hard it is do Android, never :)

> Security wise, Apple iOS is superior in any possible aspect to Android. One aspect where Android is superior is that more of it is open-source.

"Google Play Services is a proprietary background service and API package for Android devices from Google" [0] - I don't know a phone running pure AOSP without any proprietary code.

[0] en.wikipedia.org/wiki/Google_Play_Services

Re: I don't trust Signal

#172
post #88

Earlier quoted context omitted.

I would agree with you if only Signal would not ask for so many permissions on my phone.

Last time I had it installed it scanned my contacts a half dozen times while I slept. I removed it in the AM.

To be fair it does that to map you with the contacts who also are on Signal just like WhatsApp or Telegram does. Though you could also use Telegram just with user_names w/o phonebook permission but for signing up you need to use your actual phone number.

Re: I don't trust Signal

#174

Earlier quoted context omitted.

But in the linked post he does not explain, why he does not maintain a F-Droid repository for people who do not trust google, nor why the original Signal Client does not connect to Signal Forks, even if they use everything the same. Security reasons? Ordinary smartphones are full of rootkits anyways, so someone using a forked Signal version probably is better of anyway, as he knows a bit more what he is doing. So the…

> Moxie forbids you from distributing branded builds of the Signal app ... Having multiple branded builds to choose from would be a terrible thing and would easily allow fake apps to gain traction. > ... and if you rebrand he forbids you from using the official Open Whisper servers. This seems pretty fair to me. Not only could you abuse their resources, it would greatly hinder their ability to make changes and respon…

"Having multiple branded builds to choose from would be a terrible thing and would easily allow fake apps to gain traction"

In this particular case, not likely. People who are into more secure communication do not randomly click on anything. They know what they are doing, or get it installed from people they trust. And if they don't - their fault. Not Signals.

And Signal can continue to work and introduce breaking changes whenever they want. They simply only support the official build of Signal. Any person using anything different, cannot complain, if things stop working. (they will anyway, sure)

And the ressouce-abuse. Can this really be a thing? I don't know in detail how the protocol works, but what can I do with the servers, I can't do with Signal anyway? Sending (encrypted) data from A to B. I can allready abuse that today, if I want.

Re: I don't trust Signal

#175
The blog post states the following:

> [Moxie] makes arguments which don’t hold up, derails threads, leans on logical fallacies, and loops back around to long-debunked positions when he runs out of ideas.

Can anyone provide examples of threads where Moxie is acting like this? The blog post didn't give any.

Re: I don't trust Signal

#176
post #53

> Truly secure systems don’t require trust. This is a chat app so, by definition, security requires trusting at least one other person. Also, I think experience shows that secrets can often be least trusted to those who have some interest in/use for them, with the secret owner often being the least trustworthy of all. So I'd say that if you trust yourself you're already probably trusting one of the weakest links in w…

I like Linus' argument, if you don't work with a web of trust then you're doing it wrong. In the context of mobile secure messaging the web of trust includes: I'm trusting every hardware component on my phone, I'm trusting Apple, I'm trusting the iOS code, I'm trusting the TLS protocol, etc.

Re: I don't trust Signal

#177
post #170
post #168

Earlier quoted context omitted.

The article isn't about bad encryption though. It's not about a flaw in the signal protocol or something like that. It's stuff like Moxie doesn't like F-Droid. Which is not an invalid criticism but I'm not gonna stop recommending Signal over Facebook Messenger because of that. Regarding false sense of security...eh. I can't speak for endangered activists but everyday people write stupid things whether it's on SMS or…

> The article isn't about bad encryption though. It's not about a flaw in the signal protocol or something like that. It's stuff like Moxie doesn't like F-Droid. Which is not an invalid criticism but I'm not gonna stop recommending Signal over Facebook Messenger because of that. You have to look at the whole system, not just one algorithm that it uses - if any part of the system is secure then the whole is insecure.…

Isn't the whole point of Signal that it's e2e encrypted and therefore can't really read and share your messages? Whereas Facebook's system is centralized? So yeah you're safe from outside attacks but not internal ones?

I mean if you're asking me if I know for certain that Signal is better than Facebook, there's no way for me to know for sure.

But at some point there is a level of trust required and I trust a company like OWS more than I trust a company like FB. Call it blind faith, I dunno, but I also have to trust my operating system otherwise I wouldn't get anything done.

Edit: although I should add that while it may be labeled as blind faith it's also fueled by experience. OWS aren't the ones that periodically reset my privacy settings or tried to wage war against accounts not using real names etc etc.

Re: I don't trust Signal

#178
post #11

Is there a preference of Telegram over Signal or vice versa?

Telegram has a history of obvious backdoors, everyone should avoid telegram. http://habrahabr.ru/post/206900/ Some people may try to blame this on incompetence, but they still won't be able to explain how exactly someone might arrive at this implementation without malicious intent.

Would you stop posting this in every Telegram thread?

I personally explained to you why this is a complete nonsense as far as conspiracy theories go [1] as did several others. Give it a rest already.

https://news.ycombinator.com/item?id=17195956

Re: I don't trust Signal

#179
post #140
post #85

Earlier quoted context omitted.

And which operating system does the author expect people to use Matrix on? The one he personally wrote and reviews every commit to? Does he expect everyone to only chat on "trusted" open-source desktop operating systems and not their phones? The F-Droid argument is a really empty one. Packages are cryptographically signed? Are you verifying those signatures? In an article about "trust", can you explain how exactly yo…

> In an article about "trust", can you explain how exactly you trust F-Droid packages and not Google Play ones? It's easier for Google to manipulate a package on Google Play than on F-Droid. > Signal has introduced state-of-the-art encryption to millions of people in an accessible way. WhatsApp has done that to even more people, so what's the point of Signal?

> It's easier for Google to manipulate a package on Google Play than on F-Droid.

That's not how Android app signing works. It's a "trust on first use" model, so once you install an app, any update must be signed by the same key or the system will refuse to install it. That key is held by Signal, not Google, so Google cannot sign updates to apps.

> WhatsApp has done that to even more people, so what's the point of Signal?

You know who implemented the end-to-end encryption in WhatsApp? The people behind Signal. But compared to Signal, WhatsApp provides a lot more metadata to the server, and it's owned by Facebook, a company not commonly associated with guarding your privacy. Both have their pros and cons, and both have legitimate reasons to exist.

Re: I don't trust Signal

#180

But we have to trust that Moxie is running the server software he says he is. We have to trust that he isn’t writing down a list of people we’ve talked to, when, and how often. We have to trust not only that Moxie is trustworthy, but given that Open Whisper Systems is based in San Francisco we have to trust that he hasn’t received a national security letter, too (by the way, Signal doesn’t have a warrant canary). Mox…

I am happy to see I am not the only person in the world that feels like this about Signal. The interesting fact is that I "Ctrl+F" this page for Wire and I have seen nothing, even though this comment is about something that made me switch over Wire from Signal: to date, that's the unique instant messaging that has FOSS'ed both the server and the clients. (OK, the article also says about Matrix.) I admire Wire for a n…

There is a german guide to privacy I read that has some real issues with Wire, most that I agree with [0].

I will Google translate it for you (ironic):

> "10/06/2017: Wire.com operational Security

> Wire.com is referred to as a new star among crypto messengers. I briefly looked at the (experimental) Linux version of Wire.com and found some significant security flaws:

> Mannings Bug: Wire.com has good end-to-end encryption based on Axolotl. The chats are all but unencrypted (!) Logged on the hard disk of the computer. The logging can not be switched off.

> The unencrypted storage of encrypted communication is not a bug but an epic FAIL! > Access data: (Account name, password) to Wire.com account are also stored somewhere unencrypted on the hard drive. When starting the person does not have to authenticate in front of the screen but is automatically connected to all accounts.

> This is not a bug but a FAIL! Remote Code Execution: The Linux Wire Client contains a lot of Javascript code. Updates for the Javascript code will be downloaded and executed via HTTPS from the Amazon Cloud. After a superficial examination, the authenticity of the executed code is not additionally cryptographically verified (this is a guess, not checked in the code!). Security therefore depends solely on HTTPS encryption. The HTTPS encryption of the contacted wire servers app.wire.com, prod-assets.wire.com and prod-nginz-https.wire.com does NOT meet the BSI's requirements for secure HTTPS encryption. These servers are Amazon Cloud Server and Cloudfront Server (not your own infrastructure).

> DANE / TLSA or HPKP are NOT used to validate SSL certificates of HTTPS connections. In addition, no CAA record is defined in the DNS, which should actually be mandatory for HTTPS for a month. The security of the transport encryption between client and server thus does not correspond to the feasible state of the art.

> Potent attackers could attack with fake but valid SSL certificates as man-in-the-middle the communication to the wire servers, in combination with the remote code execution possibly also attack the end-to-end encryption (assumption!), and there are enough potent attackers who want to attack the encryption of crypto messengers. The domain wire.com is not signed DNSSEC. Instead of the privacy-friendly OCSP.Stapling, OCSP.Get is used and several CAs are contacted to verify SSL certificates via OCSP. OCSP.Get can be easily tricked, as M. Marlspike demonstrated in 2009. It contacts third party servers that are not under the control of the operators (maps.googleapis.com, images.unsplash.com) to download anything.

> Conclusion: The operational security of Wire.com is not (yet) suitable for security-critical applications after a small, superficial test. In particular, whistleblowers should learn from Manning's example and not use it.

> Disclaimer: this is NOT an audit but a short test of the Linux version."

[0] https://www.privacy-handbuch.de/diskussion.htm

Post reply on HN