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

There is no WhatsApp 'backdoor'

whispersystems.org

Post reply on HN
Print view View original

341–350 of 437 posts

Re: There is no WhatsApp 'backdoor'

#341

Post by mtreis86 »

usernam wrote: post #338
sschueller wrote: post #337

Earlier quoted context omitted.

Isn't Signal in the same boat? They are a US company and they control what version of the app is in the play/apple store. They could be force to push a version of a flaw and no one could verify it. The source looks good but the app that has been distributed is not.

I was actually perplexed, after reading about signal, that I couldn't just download an APK. Are play services required for signal? If so, can I even install signal on a cyanogenmod phone? Can you do so by rebuilding it yourself? Does the build match the shipped binary on the play store? To me, Signal does look exactly in the same boat as whatsapp. The fact that WhisperSystems didn't cooperate harder to ship Signal in…

Used to be, called LibreSignal. They ran into legal issues.

https://github.com/LibreSignal/LibreSignal

There is a bounty for modifying the signal app source to drop play services.

https://www.bountysource.com/issues/35722527-create-proper-p...

Re: There is no WhatsApp 'backdoor'

#342

Post by lucideer »

mtreis86 wrote: post #341
usernam wrote: post #338

Earlier quoted context omitted.

I was actually perplexed, after reading about signal, that I couldn't just download an APK. Are play services required for signal? If so, can I even install signal on a cyanogenmod phone? Can you do so by rebuilding it yourself? Does the build match the shipped binary on the play store? To me, Signal does look exactly in the same boat as whatsapp. The fact that WhisperSystems didn't cooperate harder to ship Signal in…

Used to be, called LibreSignal. They ran into legal issues. https://github.com/LibreSignal/LibreSignal There is a bounty for modifying the signal app source to drop play services. https://www.bountysource.com/issues/35722527-create-proper-p...

Just to clarify on mtreis76's bountysource link, that work has already been completed and submitted by 8bitkid, and we're just waiting for it to be merged into Signal. Discussion on this here: https://github.com/WhisperSystems/Signal-Android/pull/5962

Re: There is no WhatsApp 'backdoor'

#344

Post by hrxn »

olegkikin wrote: post #192

It actually doesn't matter. They are talking about comprimising the servers. The government has the power to force a backdoor (remember Lavabit?). All Whatsapp has to do is update their client, and all the beautiful encryption schemes are ruined. If you need a truly secure communication system, it has to be open source and self-hosted. You still have to trust the hardware though.

Lock yourself in the basement, throw away the keys. It's the only way to be safe.

> You still have to trust the hardware though.

Yes, exactly. And, realistically, how would this work? For a start, everyone running his own lil' chip foundry in the garden shed?

This is all BS. Paranoid BS, and fake news Guardian is stoking the flames. Good job..

Re: There is no WhatsApp 'backdoor'

#345

Post by IanCal »

moxie wrote: post #207
rndgermandude wrote: post #170

Earlier quoted context omitted.

This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. PS: I just chec…

> This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop. You've just d…

Is there at least a record of what keys were used on both sides, so that I could verify later whether or not this has taken place?

> You've just described a "man in the middle" attack. It is endemic to any public key cryptosystem, including Signal and PGP, not just WhatsApp. The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense.

I think it's still completely valid to say that WA should not claim to be unable to snoop. They can, and appear to be able to do so undetected with the default settings. Does the setup at least ask users if they want this feature on or off?

Re: There is no WhatsApp 'backdoor'

#346

Post by gurrone »

moxie wrote: post #237
rndgermandude wrote: post #220

Earlier quoted context omitted.

> The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense. That defense, which happens to be the only defense, is turned off by default in WhatsApp. You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the co…

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened... One thing we've learned over the years is that secur…

Having started originally with Threema before I gave in to WhatsApp I kind of like the trust levels they established in the UI. Might be an improvement for the WhatsApp UI to downgrade the trust level visually in case of unexpected key changes.

Beside of that, and thinking through this comment by moxie, I fear he is right. I've a bunch of dead keys listed in my Threema contact list. All from people which are in general quite tech savvy but still were too lazy to transfer their keys on phone changes. And I already had to rescan (the QR code) quite a bunch of people when I meet them maybe once a year. Thats for my modest 20 something Threema contacts. Now think about the not very tech savvy average whatsapp user with his 150+ contacts. Maybe about a third of them will change their phone or MSISDN throughout a year. If you see 50 alerts per year in your chats that something changed, how long will you care to verify those changes that they're valid?

I don't like those defaults choosen by WhatsApp and once I knew about it I changed it. But at the scale of WhatsApp I understand the decision they made. You might also want to add the common argument that in the real world close to nobody will give a shit about the encryption. Since Snowden a few percent more care but it's still a small minority. So to bring at least some security to the majority that do not care is still a win. Everyone else has to make informed decisions about their own configuration.

Re: There is no WhatsApp 'backdoor'

#347

Post by mos_basik »

ycmbntrthrwaway wrote: post #306
mos_basik wrote: post #97

Earlier quoted context omitted.

Caveat: I have never used WhatsApp and do not know anything about its interface or options (default or otherwise). >>[The choice to make these notifications "blocking" (i.e. to require manual verification) would] leak information to the server, etc., etc. >Why should this option exist at all? The option does not exist, and should not exist. That's the author's point there. You agree with him and with WhatsApp on that…

> The option does not exist, and should not exist. I also think the option should not exist, but according to The Guardian article [0], the option exists: "In WhatsApp’s implementation of the Signal protocol, we have a “Show Security Notifications” setting (option under Settings > Account > Security) that notifies you when a contact’s security code has changed." [0] https://www.theguardian.com/technology/2017/jan/13/…

The option The Guardian is describing there is something like this:

    When my partner's key changes:

    [ ] Show me a notification (y/n)
What I was talking about was an option like this:

    When my partner's key changes:

    [ ] Wait for my manual confirmation before delivering any messages from my
        partner that are dated after the key change (y/n)
To me it's up for debate whether or not the existence of the first option or the fact that it's disabled by default are good ideas, in terms of the behavior of the app matching consumer expectations of security. It'd be safer for it to be permanently enabled, but that's neither here nor there.

But the second option would be fundamentally broken and leak information to the server about how conscientious a user is about security, which is why the author, whatsapp, and everyone in this sub-thread agrees it's a bad idea. Someone else gave an concise example elsewhere in the thread: https://news.ycombinator.com/item?id=13397118

edit

N.B.: Requiring manual verification all the time, from everyone, would not leak any information and would be the most secure. Allowing users to choose whether or not they want to manually verify is the leaky bit.

Re: There is no WhatsApp 'backdoor'

#348

Post by tptacek »

eeZah7Ux wrote: post #335
tptacek wrote: post #166

Earlier quoted context omitted.

I'm sorry, but if you look upthread, the comment I responded to not only didn't say that verifying open source was easier , but actually made the extreme claim that there was in principle no way to verify closed source software at all. Meanwhile, addressing your (different) argument directly: sure, reading C code is easier than reading assembly code, and reading Python is easier than reading C. The easier it is to re…

> less well-known programs that are much harder to reverse have been productively > It's just not capital-H Hard to do it in closed-source software, so this open vs. closed debate about backdoors is usually a red herring. No, you are oversimplifying the problem a lot. In an Open Source project it is possible to create transparency in the development process by every commit public and allowing 3rd parties to mirror th…

Nope. Professional security people have been using binary diffing tools to solve this problem since the early 2000s.

Re: There is no WhatsApp 'backdoor'

#349

Post by mos_basik »

FabHK wrote: post #128
mos_basik wrote: post #97

Earlier quoted context omitted.

Caveat: I have never used WhatsApp and do not know anything about its interface or options (default or otherwise). >>[The choice to make these notifications "blocking" (i.e. to require manual verification) would] leak information to the server, etc., etc. >Why should this option exist at all? The option does not exist, and should not exist. That's the author's point there. You agree with him and with WhatsApp on that…

Difference is that the WhatsApp client re-encrypts the message with the new key from the server and re-sends it without user intervention ("non-blocking"), so even if you cared, you can't prevent it. With the alternative, people that don't care could tick "verified" with or without verifying, but you could also click "cancel" (with or without verifying).

What difference does it make?

                                ALICE
                        When would you 
                        like to meet?
    BOB
    Tomorrow, 19:00, by the
    north tennis courts.
                                ALICE
                         Sounds good.

      !!! BOB's key has changed !!!

    BOB
    Actually, could we meet
    at my place?  I'm going
    to be super busy tomorrow.
If Alice and Bob are doing something that needs to remain secure, Alice would be a fool to trust Bob's messages after the key change without manually verifying the new key with Bob. How does withholding messages help, aside from telling the server which people have enabled the setting and which people have not? [edit: I just realized you were talking specifically about the case where manual verification is enforced for all users; disregard the last phrase.]

Admittedly one angle I can kind of agree with is that layman users may not understand the implications of a key change and the importance of out-of-band verification, and blocking messages until verification would be a way of signaling the significance of the key change. But... counterpoint to that is that users interested in security are probably already dead in the water in that regard if all they have is a layman's knowledge of how crypto works.

Re: There is no WhatsApp 'backdoor'

#350

Post by tptacek »

lomnakkus wrote: post #282
tptacek wrote: post #202

Earlier quoted context omitted.

I'm in a cab typing on my phone but good Google searches are "llvm lifter" and "symbolic execution" or "SMT".

AFAICT that's (at best) research level stuff. I'd love to be proven (heh) wrong, though. I think what lisper was after was actual practical applications, e.g. something along the lines of the CompCert C compiler[1]. [1] Which I'll note was written and verified in Coq a high-level proof-oriented language.

I don't know what "(at best) research level stuff" means. Here's a well-regarded LLVM lifter by a very well-regarded vuln research team that's open source:

https://blog.trailofbits.com/2014/08/07/mcsema-is-officially...

There are a bunch of other lifters, not all of them to LLVM.

Already, with the idea of IR lifting, we're at a point where we're no longer talking about reading assembly but rather a higher-level language. But this leaves out tooling that can analyze IR (or, for that matter, assembly control flow blocks).

Someone upthread stridently declared that analyzing one version of a binary in isolation was hard enough, but that the work of looking at every version was "staggering", "capital-h Hard". But that problem is in some ways easier than basic reverse engineering, which is why security product companies and malware research teams have teams of people using BinDiff-like tools to do it. "BinDiff" is a deceptive name; "Bin" refers to compiled binaries, because the tools work based on graph comparisons of program CFGs.

Part of the problem I have talking about this stuff is that this isn't really my area of expertise --- not in the sense that I can't reverse a binary or use a BinDiffing tool, because most software security people can, myself included, but in the sense that I'm describing the state of the art as of, like, 6 years ago. I'm sure the tooling I'm describing is embarrassing compared to what our field has now.

Open vs. closed source is an orthogonal concern to verifiability.

Post reply on HN