Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

131–140 of 437 posts

Re: There is no WhatsApp 'backdoor'

#131
post #86

Earlier quoted context omitted.

It kinda is - you could add it to the description. App stores seem to be getting progressively more hostile to this kind of thing though - you can't just download an APK / iOS app, you have to do it through a device. This lets the stores do "app slimming" (and per-country / per-carrier customized apks) to remove resources you don't need (like binaries that don't match your architecture), which would change the checks…

It's been a while (a couple of years) since I last tried this, but I remember it being reasonably straightforward to get APKs of apps that were on the Google marketplace. Not through official user interfaces, of course. I can't remember if I ended up using some Chrome extension or a third-party app that needed root. Not a particularly useful comment sorry, just "it was possible two years ago if you jumped through som…

You can probably still get the one that'll install on your device(s), but if there's customization for e.g. carrier X in country Y (or app slimming) you're unlikely to know or be able to find it from the infinite "download APKs free now!" sites.

And the last time I looked, all the apk-downloaders required your device ID, because Google's API does (for customization reasons) - it's much more of a "you can do this if you emulate a device" than "you can download it". I'm also not sure if the ID works unless you have gplay installed, which you may not have if you're being careful/paranoid enough about security to manually validate apps.

Re: There is no WhatsApp 'backdoor'

#132
post #124
post #78

Earlier quoted context omitted.

There's "no way in principle"? How is this whole story not evidence to the contrary? The person who found this didn't use WhatsApp source code. Why do you feel that there's no way to verify closed-source software?

You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities.

> no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities

I'd say that's hard for open source software to do as well.

Re: There is no WhatsApp 'backdoor'

#133

We can learn one important thing here - it is not possible to trust closed source software. Enough said, next issue please.

If your goal is to get the greatest number of people onto the greatest and most secure, private, free software, then pure ideology won't help.

What do you think Iran/the NSA/any TLA is more upset about, WhatsApp using the Signal protocol, or Matrix and Riot?

Re: There is no WhatsApp 'backdoor'

#134
post #28
post #18

At the end of the day, it comes down to trusting WhatsApp. Even without a backdoor in their protocol, they can easily do all kinds of things. For instance, it could instruct specific clients to encrypt and send each message twice: one for the recipient, and one for the WhatsApp server. As long as this was off for 99.9% of users, it's unlikely that security researchers would ever detect this.

I mean, they're probably disassembling the app, so they'd definitely notice _that_, but there are some truly subtle problems that pop up in security, so your general point about trust seems reasonable enough (certainly for any closed-source remote-updating system).

Also it would be possible to put in subtle backdoors, which would be hard to see when it's disassembled and could even allow plausible deniability.

Re: There is no WhatsApp 'backdoor'

#135
post #60

Earlier quoted context omitted.

Open source software can be verified.

Source code can be verified. Binaries distributed via app stores may or may not have behavior different from the published code.

Reproducible builds will fix that, soon.

Re: There is no WhatsApp 'backdoor'

#136
post #74
post #22

Earlier quoted context omitted.

He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.

The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competen…

[deleted]

Re: There is no WhatsApp 'backdoor'

#137
post #90
post #74

Earlier quoted context omitted.

The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competen…

I agree, perhaps a further version of the signal protocol could implement a definitive solution that better addresses this kind of scenario the way HSTS did for ssl certs. And combined with a friendly UI solution (like the new padlock | Secure string in chrome) would lead to easier detection of possible eavesdroppers by the lay person.

This isn't a vulnerability in the signal protocol. More a vulnerability in a particular UX decision that WhatsApp made (consciously, even.)

Re: There is no WhatsApp 'backdoor'

#138
post #74
post #22

Earlier quoted context omitted.

He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.

The "green padlock" was not considered enough because users would not be able to differentiate it from a big lock symbol within the page. Thus we got HSTS. (There was a time when browsers would color the entire URL bar yellow to indicate https, but that went out of favor many years ago.) Moxie deserves respect for the web vulnerabilities he discovered and raised awareness about years ago, and for his general competen…

>just trusts that "I heard WhatsApp is secure, so I'm good to go", then so much is sacrificed that there wasn't any point in the exercise to begin with. Except that real solid systems, with direct user control over key continuity, and fully open-source, are undermined by the confusion with these "lay person" super-convenient closed-source systems.

I totally disagree with this.

Security isn't some absolute thing, which you either have or don't have. It's a series of threats, and counters, and usability tradeoffs you have to make so people still use your service.

You can always criticise someone selling a front-door lock - "what if the bad guy smashes the window"? But that doesn't mean front door locks are bad, or that we should all move into houses without windows.

I think tech folk treating security as a binary all-or-nothing thing, without thinking about the usability tradeoffs, are a big part of the problem, and why so much of what we have is so insecure. We have these "real solid systems, with direct user control over key continuity, and fully open-source" you mention which almost no one uses.

This makes them useless. Complaining that people should know better is also useless. Shipping software which dramatically increases security against a wide range of threats, on the other hand, because 1B people actually use it, is a positive contribution. Trying to blame that same software for the lack of adoption of "real solid systems" is lame. We've had the solid systems for years, but their lack of usability always sunk them.

Does WhatsApp encryption handle every threat? Of course not. There are always going to be unhandled threats. People could still come to your house and root your phone, or hit you with a wrench until you unlock it, for example.

But there's an apparently big threat (revealed in the Snowden leaks) of governments clandestinely, passively, mass-monitoring traffic on the wire, perhaps without the cooperation of the tech companies involved, which has compromised the privacy of vast numbers of entirely innocent people. WhatsApp's encryption seems to counter this.

Moxie et al's contribution thus deserves respect, in so far as it potentially protects a billion people from that class of threat.

It's possible that, due to the closed source nature of WhatsApp, they are actually snarfing everything. That would be big news, deserving of a mass outcry, or a leak. I'm hoping the potential commercial ramifications of them getting caught widely releasing a deliberately compromised client keeps them honest.

Its a risk, but security is always about risks and tradeoffs, not absolutes; and they have built a system that's actually usable enough that it has 1B users.

Re: There is no WhatsApp 'backdoor'

#140
post #124
post #78

Earlier quoted context omitted.

There's "no way in principle"? How is this whole story not evidence to the contrary? The person who found this didn't use WhatsApp source code. Why do you feel that there's no way to verify closed-source software?

You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities.

That's identically true of open-source software. To put it in the theoretical terms you're probably most comfortable with: the programming language used to represent a computer program has nothing fundamentally to do with whether it can be verified. Obviously some languages are easier to verify programs in than others, but the gap between assembly and C in ordinary compiled programs is surprisingly small.

Open vs. closed-source software is a concern orthogonal to verifiability.

I know this is a tough thing for people to get their heads around since it challenges a major open source orthodoxy. I like open source too. But the people who ratified it were not experts in this field, and this particular benefit of open source is overstated.

Post reply on HN