Hacker News Reader

Comment by ddevault | Hacker News Reader

"non-federated" and "secure" in the same sentence is a joke. Signal's other problem is Google Play Services which has absolutely no place in a supposedly secure system.

View on HN

Federation concerns availability, not security. "unplug the ethernet and write plaintext to /dev/null" is extraordinarily secure and 100% decentralized, though badly unavailable.

It can also affect security depending on what jurisdiction the servers fall under. Federation means that while it may be illegal to run the service in, say, China, it can be run elsewhere without those concerns. This is becoming more apparent with the widespread use of National Security Letters.

Sorry, am I missing something? It's my understanding that Signal is ETE encrypted. All an NSL would get you is ciphertext and metadata.

The scenario I'm imagining is that Google and OWS receive NSLs requiring them to push a modified APK that could do nefarious things.

This is a common misconception: NSLs are a legal tool that can be used to extract certain types of information (such as subscriber information and maybe a little bit of transactional information) that a service provider already has stored on their servers [0]. However, they cannot be used to force a service provider to write and deploy code.

[0] NSLs are not magic - https://www.youtube.com/watch?v=YN_qVqgRlx4&t=20m16s

He mentions "technical assistance orders" but doesn't really elaborate any more on them. I'm having a difficult time finding any information on these orders, does anyone else have information on the capability of these orders?

Replying to my own comment, as I found some more information in a Black Hat talk regarding technical assistance orders:

https://youtu.be/PX2RjJAfTYg?t=770

I was wondering about the extent of NSLs in that regard. Thanks for clarifying.

Google can't push a new Signal APK, it's signed by OWS, not google.

3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary).

I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.

> I guess a NSL might compel OWS to push a binary specifically for a targetted user.

To my (admittedly fairly limited) knowledge, that's something the courts have yet to rule on. They can definitely ask to you give them any data they store about their users (and force you to keep quiet about it), but whether they could force you to develop a backdoor (and ship it to someone) remains to be seen. That's basically what the FBI vs. Apple case was about, which the FBI sadly pulled before courts got to rule on it.

So Android checks the APK is signed by the same publisher on update? What about for new users? Nothing stops Google from just changing which package is on Play Store, right? Where does signature validation come in, and how would a user tell?

> When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the existing version. The system allows the update if the certificates match. If you sign the new version with a different certificate, you must assign a different package name to the app—in this case, the user installs the new version as a completely new app.

https://developer.android.com/studio/publish/app-signing.htm...

If you want to install an update that was signed with a different private key, the app would need to be uninstalled first, which would also delete any sensitive data in private app storage.

This is enforced at the platform framework level, from what I loosely remember of scanning the AOSP source code.

Yes, Google could hijack packages sent to first-time downloaders. That's usually the downside with trust on first use. If the initial download isn't trustworthy, the whole verification scheme falls apart. It would be better off if Android had the APK equivalent of Certificate Transparency. That, and if Google Play made all developer-uploaded APK builds available to users, for awareness.

Can I just chime in again and say, if your threat model includes an adversary who could compromise the Google Play Store deployment process, then you should be comfortable with validating the SHA hash on your APK binaries.

Android is pretty open about letting you sideload and run binaries, which you can do easily as a non-rooted end user. You can personally GitHub pull & compile the Signal app and you're good to go (w/r/t compromised software download).

Google/Apple could also receive a NLS ordering them to write and install a keylogger on your specific device in their next OS update. There's really not much you can do about that.

If Signal was federated anyone could write a signal client to openBSD or Alpine Linux.

This does somewhat break Signal's security model..

Why? Google doesn't know who you are chatting with, or even the size of the messages you are sending. Google just sends a "wake up signal and check for messages". That's it.

Keep reading the thread.

Your argument on this thread is incoherent. You begin by suggesting that GCM is problematic because it's a component of a larger platform library that gives Google control of Android phones. When it's pointed out that GCM push can be supported without that platform library, your argument shifts: it's the messages themselves that are dangerous. When it's pointed out to you that the messages are empty, you invent a scenario in which GCM push messages enable a kind of traffic analysis that on-the-wire traffic analysis can't already accomplish.

Were this my argument, rather than pointing me to a thread where my points were continually and reliably refuted, I'd take this opportunity to instead restate my argument clearly.

I think you're misinterpreting my arguments because it suits your preconceptions if that were the case. GCM is not just client code. I clarified when someone said the client could be replaced.

Same issue, and here's Moxie himself on it:

https://news.ycombinator.com/item?id=13054940#13056554

I have read this; I don't generally comment on issues I'm not informed on.

Moxie is simply wrong on many of these points, and has been for a while and has had this repeatedly pointed out with no change in opinion. I would rehash this here but you'd be better off simply reading the linked thread and looking at other rebuttals. In particular I remember a 500+ comment GitHub thread on the Play Services issue where Moxie was repeatedly dismissive and rude to those who take issue with the glaring security problems in Signal.

"The glaring security problems in Signal"?

Signal's use of GCM has also been beaten to death: it's a platform issue that has no impact on security (but does make it harder to deploy Signal on nonstandard Android platforms).

That is not true. It's (1) a remotely exploitable rootkit and (2) a tracking system that's (3) operated by a multi-billion dollar company whose entire business model is invading your privacy.

Google Play Services is not the standard Android platform. AOSP is the standard Android platform.

You're conflating GCM and the wider Google Play Services that is installed on most Android devices. As someone who actually uses AOSP without Google, it weakens your argument when you conflate the two.

GCM depends on Play Services, so I'm really not.

GCM is merely one minor component. The existence of the microg project proves that you can implement one without the other.

MicroG does not implement GCM.

MicroG does implement the GCM client! I've been getting push notifications through that thing for several months.

No, it implements one half of it.

Signal still has to be linked with a proprietary binary, which contains lots of tracking code.

Through Google, yes, but you can't bring along your own push notification delivery service.

Your argument has become circular, because the what Signal uses push notifications for isn't security-relevant: the messages are empty and used only as a wakeup.

They still contain information, though. They say when you're talking on Signal. Matched with someone else's messages at about the right frequency to indicate a conversation, they give a pretty decent idea of who you're talking to.

They give the same information that TCP/IP traffic analysis does.

Perhaps, but we can at least start to explore solutions to that if we can work on the server too.

You're ping-ponging all over the place. Which is it? "Glaring security problems", or impediments to fully exploring the solutions space?

Reply on news.ycombinator.com