
There is no WhatsApp 'backdoor' - stablemap
https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/
======
jMyles
Color me still-unconvinced.

This retort does not address the fundamental point made in the Guardian piece:

> “[Some] might say that this vulnerability could only be abused to snoop on
> ‘single’ targeted messages, not entire conversations. This is not true if
> you consider that the WhatsApp server can just forward messages without
> sending the ‘message was received by recipient’ notification (or the double
> tick), which users might not notice. Using the retransmission vulnerability,
> the WhatsApp server can then later get a transcript of the whole
> conversation, not just a single message.”

~~~
rndgermandude
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 check on my phone if those notifications were turned on. There were
not. And I'd never turn those off myself, which leads me to conclude that the
rekeying notifications are off by default (in their android app)

~~~
moxie
> _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 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.

> _PS: I just check on my phone if those notifications were turned on. There
> were not. And I 'd never turn those off myself, which leads me to conclude
> that the rekeying notifications are off by default (in their android app)_

Key change notifications are off by default in WhatsApp. That's probably going
to be a fundamental limit of any application that serves billions of people
from many different demographics all over the world.

Even if they were on by default, a fact of life is that the majority of users
will probably not verify keys. That is our reality. Given that reality, the
most important thing is to design your product so that the server has no
knowledge of who has verified keys or who has enabled a setting to see key
change notifications. That way the server has no knowledge of who it can MITM
without getting caught. I've been impressed with the level of care that
WhatsApp has given to that requirement.

I think we should all remain open to ideas about how we can improve this UX
within the limits a mass market product has to operate within, but that's very
different from labeling this a "backdoor."

~~~
eternalban
> That's probably going to be a fundamental limit of any application that
> serves billions of people from many different demographics all over the
> world.

Moxie, some of us are of the opinion that [that] (implied) goal is certainly
noble but ill-considered.

Modern state surveillance has 2 general unstated goals:

1) Create an atmosphere of fear to affect self-censorship. Some states (such
as China) announce this as a matter of state policy. Others (such as US) drop
hints. UK is somewhere in between.

2) Identify emerging memes, clusters, and thought leaders. This information is
then used to counter, disrupt, and discredit/isolate (respectively).

(And yes, the stated public goals are to prevent terrorism, child pornography,
and crimes.)

From the political angle -- activist angle, if you will -- the goal of
"serving billions of people from many different demographics all over the
world" is minimally misguided, and counter productive, and maximally a hazard.

~~~
abecedarius
I don't understand. How is it misguided, and who is it a hazard to? Are you
saying the unstated goals of state surveillance are good ones which conflict
with popular use of crypto, and therefore popular use of crypto is bad?

~~~
likeclockwork
I THINK the commenter was saying that "serving billions of people from many
different demographics all over the world" is inviting all of those different
people together so you can betray them all at once.

------
psranga
I take this blog post as confirmation that:

1) _ANY_ one message can be intercepted even if the sender exhibits ideal
levels of alertness [Whatsapp server drops message to recipient; sends a rekey
request with a fake key; message is intercepted since fake key was generated
by server. Sender will see a warning if they turned on that setting (default
is to show no warning), but it's too late].

2) Only Whatsapp has this vuln, not Signal app.

3) Depending on sloppiness of sender, more extensive interception is possible.
[E.g., server not supplying delivery reports + sender doesn't have warning for
key changes + sender sloppy about noticing lack of double check mark => full
transcript can be generated]

~~~
dangero
Best summary I've seen. There are two significant facts here that surprised
me: 1\. The double checkmark has security implications. How would a typical
user know that? 2\. Even if you are completely vigilant, follow best
practices, etc, Whatsapp messages can be intercepted. They claim this is a
"wontfix" UX choice. I'm skeptical why the non-default feature cannot even
provide the protection that almost everyone assumed it would.

~~~
Vinnl
> How would a typical user know that?

I think that's basically the main problem: there is no way to get a typical
user to understand security implications of anything without having that user
give up before reaching that point...

------
YeGoblynQueenne
I think all this is by-the-by. The gist of The Guardian's article was that
WhatsApp has full control of when, if and how your messages are encrypted, and
if you're a dissident working against an oppressive regime and you use
WhatsApp to collaborate with your allies, your ass is grass, because there
isn't anything physically preventing security agencies from getting hold of
your communications.

That such security agencies have the power to force WhatsApp (or anyone) to
comply with their demands is without doubt. A really secure system for
activists would be one that makes it impossible even for the provider to read
your messages, under any circumstances. WhatsApp is not just not that, it is
also ridiculously easy for them to read your messages, if they so choose and
you use it at your own risk.

~~~
sschueller
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.

~~~
usernam
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 F-Droid is also a
major let-down.

Is any other app sharing the same protocol?

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

[https://github.com/LibreSignal/LibreSignal](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...](https://www.bountysource.com/issues/35722527-create-proper-pull-
request-to-add-libresignal-s-websocket-support-to-ows-signal)

~~~
snowpanda
They can't use the name LibreSignal because it has the word Signal in it?

Wow, even Microsoft didn't behave that juvenile about LibreOffice.

~~~
metaobject
Yeah, they just sued some high school kid because of the domain name he chose:

[https://en.m.wikipedia.org/wiki/Microsoft_vs._MikeRoweSoft](https://en.m.wikipedia.org/wiki/Microsoft_vs._MikeRoweSoft)

~~~
fapjacks
I don't know about Canadian trademark law, but at least in the States, if you
don't put effort into defending your trademark, you lose it. Completely
different country, I know, but perhaps there's something similar in their law.

------
kentonv
I love this post for the in-depth explanation of the UX challenges around e2e
encryption and why they made the decisions they did. It's educational.

I think Moxie highlights a very good point that is commonly underrated among
"security Dunning-Krugers": Opening yourself to the possibility of an attack
is often OK if the attack is easily detectable, and if the identity of the
attacker would be obvious upon detection. Yes, Facebook _could_ intercept and
decrypt a message without your advance knowledge. However, you would be able
to detect it after the fact. And if you detected an attack, the attacker could
be no one other than Facebook. You could then expose them and ruin their
reputation. Given this, it's unlikely that Facebook would risk carrying out
such an attack in the first place.

Security is not binary, it's risk management. The goal is to minimize the risk
of an attack, not to rule it out entirely (hint: you can't). I think WhatsApp
has made the right choices here.

~~~
yellowapple
In most cases, I'd much rather disallow Facebook from MITMing my messages than
try to "ruin their reputation" (hint: I won't, because Facebook already does
far worse things on a regular basis without so much as an eye-bat from the
world).

In other words: I care about the confidentiality of my messages far more than
the promise of some sort of dubious ability to shame Facebook for simply
fulfilling its business model. Sure, there are some cases where allowing
security to be exploited in one area protects the security of another, but
those are called "honeypots", and I sure as hell hope my private
communications are not a part of that.

Transparency is a dependency of trust. WhatsApp is not transparent; therefore,
it is not trustworthy. Simple as that.

------
sebleon
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.

~~~
na85
Trusting WhatsApp == trusting Facebook

I can't think of a company I trust less than Facebook.

~~~
imranq
What about...Walmart, Glencore, Phillip Morris, Blackwater, Palantir...

~~~
ljk
> _Walmart_

I can use cash at Walmart

~~~
evgen
And be sure to smile at the cameras watching you in the store, and the ones in
the parking lot that recorded you driving in.

~~~
kordless
It's shared physical space. I'm OK if they video me. I'm OK if they share that
video with law enforcement if there is a reason of substance to do so and as
long as they make it publicly known they asked for it within a reasonable
timeframe, say 45 days. I'm NOT OK with broad sweeping requests and would only
allow them if circumstances required it and the request for the data was
disclosed within 90 days.

------
tyrust
>The WhatsApp clients have been carefully designed so that they will not re-
encrypt messages that have already been delivered. Once the sending client
displays a "double check mark," it can no longer be asked to re-send that
message. This prevents anyone who compromises the server from being able to
selectively target previously delivered messages for re-encryption.

Can this be verified? Can this be verified to be the case 100% of the time? Is
there anything stopping the client from lying to a user [0] with this
interface, saying one thing (i.e. "this will not be resent") and doing another
(i.e. resending)?

[0] - Or being triggered to lie to a particular user at a particular time.

~~~
UncleMeat
If your threat model includes using a malicious app to send messages then you
lose anyway. Nothing can ever be done to send messages securely using whatsapp
if the client is neither trusted nor verified. This is true for basically
_all_ software that you use.

~~~
hackuser
Open source software can be verified.

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

~~~
jMyles
Certainly it's possible to remedy this situation simply by having the app
author sign a checksum of binaries in the app store. Why this is not currently
an option (to my knowledge) is a mystery to me.

~~~
Groxx
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 checksum. Which is useful,
but inconvenient for this goal.

Something like fdroid may be supportive of this, which would be cool. But I
wouldn't expect the mainstream ones (or Apple) to ever embrace it - it'd be a
bad user experience / wasted UI space in the vast majority of cases.

~~~
mos_basik
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 some hoops."

~~~
Groxx
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.

------
olegkikin
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.

~~~
Grollicus
To expand on this argument a bit, if you think the Government/Whatsapp are
specifically out to get you (eg. willing to mount an active attack against you
specifically), then WhatsApp is propably the wrong messenger for you.

If on the other hand you want a reasonably secure Messenger that you can use
to chat privately with everybody and their Grandma then maybe you should not
expect that it does super complex security thingys that 99% of its users just
don't care about and don't want to be bothered with..

------
kingnight
This main flagrant or off-topic, but something that nags at me when thinking
about truly secure messaging apps from the App Store:

Even with perfect e2e encryption protocol added, what's preventing WhatsApp
developers (FB) from adding in a feature of the app:

if local.user is "TargetUser007" { takeDeviceSnap();
sendDeviceSnapshotToFBOverSameEncryption(); }

Wouldn't this not be ever verifiable unless you ARE that specific user and
it's too late?

~~~
maxerickson
You'd also have to make sure they were the only user that received that
binary.

Otherwise you'd have to hope that no one reverse engineered the binary and
noticed the oddly specific comparison there.

~~~
kingnight
Are reverse engineering techniques currently greater than known ability to
obfuscate compiled iOS code?

~~~
MichaelGG
And it'd have to work for other platforms, too. Android is Java right? Which
is even easier to RE.

~~~
besselheim
Android apps can also contain native code. Indeed, WhatsApp includes such
libraries, to help with Curve25519 encryption, video encoding, voice over IP,
and other functionality.

~~~
MichaelGG
But it should be straightforward enough to see if text messages or UI elements
(suppress key change notification) are being change depending on the output of
those libraries.

------
ycmbntrthrwaway
> That would leak information to the server about _who has enabled safety
> number change notifications and who hasn 't_, effectively telling the server
> who it could MITM transparently and who it couldn't; something that WhatsApp
> considered very carefully.

I am not convinced. Why should this option exist at all? Even worse, it is
disabled by default. Just enable notifications for everyone and demand
verification. If you don't want to verify, just ticking "veryfied" without
actual verification is not that bad, it is just a trust-on-first-use principle
in action. Actually it is how SSH works and nobody complains about SSH being
backdoored.

~~~
cypherpunks01
If we're talking about key change notifications, isn't SSH the thing that
throws the following error when a key changes?

    
    
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
      Someone could be eavesdropping on you right now (man-in-the-middle attack)!
      It is also possible that a host key has just been changed.
      The fingerprint for the RSA key sent by the remote host is
      51:82:00:1c:7e:6f:ac:ac:de:f1:53:08:1c:7d:55:68.
      Please contact your system administrator.
      Add correct host key in /Users/user/.ssh/known_hosts to get rid of this message.
      Offending RSA key in /Users/user/.ssh/known_hosts:12
      RSA host key for 8.8.8.8 has changed and you have requested strict checking.
      Host key verification failed.

~~~
makomk
Yeah, SSH is at the complete opposite end of the scale in how it handles
unexpected key changes - it won't even let you connect unless you manually
edit known_hosts, whereas WhatsApp automatically uses the new key without any
possible way for the user to stop it from doing so until it's too late.

------
mhandley
Moxie claimed: > "The choice to make these notifications "blocking" would in
some ways make things worse. That would leak information to the server about
who has enabled safety number change notifications and who hasn't, effectively
telling the server who it could MITM transparently and who it couldn't;
something that WhatsApp considered very carefully."

Surely if WhatsApp cared about the server not being able to detect this, they
could just get the client to "retransmit" an encrypted blank message in place
of the original under these circumstances. Then the server wouldn't be able to
tell who has enabled blocking mode and who hasn't.

------
aaronbrager
WhatsApp should make three hanged:

1\. handle new keys the same way Chrome handles expired SSL certs: a big
warning with the option to continue anyway if you want

2\. Don't automatically resend a message with a new key (require the user to
manually resend, like when iMessage falls back on MMS)

3\. enable the key change notifications and make disabling them an "advanced"
setting

WhatsApp is making the right choice by designing for ease of use, I think they
just landed a little too far away from a secure implementation.

------
hackcasual
tl;dr to me seems: Since users can change devices, they'll need to reissue key
material, this needs to be supported. WhatsApp reports key changing
optionally, but doesn't tell the server that happened.

If WhatsApp tries to backdoor a channel and one of the users has key change
notification, they'll find out about it, and WhatsApp has no idea whether the
warning was shown.

~~~
jMyles
> If WhatsApp tries to backdoor a channel and one of the users has key change
> notification, they'll find out about it

The problem is that the might not find about out retransmissions. You are
trusting that the "double-tick" means that the message won't be resent, but
presumably WhatsApp can indeed retransmit those messages with the new key
under pressure from a state actor.

They need to specifically address this point; it's the only thing worth
talking about. The rest is just a discussion of implementation of key
exchanges generally.

~~~
Deregibus
That would require the client to be compromised though right? My understanding
is that the client is making the decision whether to retransmit with the new
key.

Now it's fair to question whether you can trust the client, but if you can't
then there's no limit to what they could do.

------
_jp__
Of course there is a backdoor. Why not? Under what law whatsapp and
whispersystems live? The one with secret courts and secret court orders?. How
to trust someone under this umbrella?

We need to spread technology companies. Everything but a bunch of things comes
from this law.

And what starts in another country, magicaly gets bought or dismissed. Take
Symbian as an example...

------
agd
'Given the size and scope of WhatsApp's user base, we feel that their choice
to display a non-blocking notification is appropriate. It provides transparent
and cryptographically guaranteed confidence in the privacy of a user's
communication, along with a simple user experience. The choice to make these
notifications "blocking" would in some ways make things worse. That would leak
information to the server about who has enabled safety number change
notifications and who hasn't, effectively telling the server who it could MITM
transparently and who it couldn't; something that WhatsApp considered very
carefully.'

Why not have every client show up as having safety number change notifications
on and just choose whether to display them client side depending on user
settings? i.e. if you have them off, no message will display and the message
will automatically be resent using the new key?

~~~
eridius
You quoted the answer to that already. If these change notices are "blocking",
then the sending device won't re-send the message until the user has verified
it. If the user hasn't enabled the notification, then the sending device will
re-send immediately. This makes it trivial for the server to figure out who's
actually enabled the notifications and who hasn't, which means the server can
be confident about when it's actually safe to MITM.

~~~
agd
You could send a dummy message for those with blocking turned on and screen it
out at the receiving client.

------
throw7
What is the user supposed to do when they get notified of a "safety number
changed" message? How do they verify they've not just been MITM? Honest
question... I don't use whatsapp or signal at all.

~~~
subliminalpanda
I would simply ask if they got a new phone or re-installed WhatsApp.

A few would inquisitively ask "Yes, how did you know?", then I would explain
them to them the notification I got.

~~~
pbalau
This can be triggered by the other side changing phones/devices. How do you
explain this to the stupids?

------
joeblau
There seems to be a pretty clear war going on between engineers and
journalists lately.

\- Chris Latter [1] vs Business Insider [2]

\- Elon Musk vs (Bunch of outlets)

\- Moxie vs The Guardian

I feel like journalists want to write a compelling story and engineers are on
the other side like "No, those aren't facts!" I don't follow a lot of media
outlets but it seems like journalists either lack the skills or don't care
about doing any technical due diligence.

[1] -
[https://twitter.com/clattner_llvm/status/819974025371787264](https://twitter.com/clattner_llvm/status/819974025371787264)

[2] - [http://www.businessinsider.com/how-apples-culture-of-
secrecy...](http://www.businessinsider.com/how-apples-culture-of-secrecy-
wears-down-its-top-developers-2017-1)

~~~
hackuser
I don't know what happened here, but ...

Let's avoid our own bias of automatically believing the engineers are in the
right; they are fallible people, no more or less honest or prone to error than
journalists.

Every news story that breaks, involving any person or industry, gets the same
response: It's false, they didn't ask us, etc. etc. Therefore, that response
is not an indication that something is wrong (or right); the response tells us
nothing in itself.

~~~
joeblau
You're right. Everyone is fallible and I'm all for mistakes being made — We
are all human. I also agree that the immediate snap response tells us nothing.

Based on the BI story, I know a few people that have actually already
uninstalled WhatApp for fear of a backdoor. What I wish is that there was a
better way for these two entities to communicate rather than finger pointing
and name calling so that we as consumers of both media and technology can read
a better more comprehensive narrative.

~~~
kordless
Name calling results in reassigning fear. People are afraid of the unknown and
so try to box it up in something digestible they can fear less. We tend to
blame others because it's easy and cheap to do so. If you are wrong, that
means I'm right and so then I wasn't wrong about it and don't have to think
about it anymore. And you are wrong, so why would I think about it again?

I think it's interesting the entities are not two, but many and one at the
same time. Elon Musk is an individual and he is also part of the press
process. My rationale is that the press includes everyone in the press,
including the people writing the stories and the people _in_ the stories.

We know Musk. He doesn't know us.

~~~
hackuser
> We know Musk

I know this isn't your point, but we don't know Musk; we know his
(intentionally, carefully curated) public image

~~~
kordless
Yes, I agree. That part of him is his image in the public. It is both him and
us at the same time, if you think about it from one perspective.

------
Eager
Oh give me a break

7.7 billion people in this planet are not part of ISIS.

Nice business model though.

Even if WhatsApp or Telegram or Signal are not compromised, you realky should
assume the kernel or baseband are.

When I was a kid, I did an experiment cracking Apple] [ software.

Turns out forget the disk encryption, just hook up the NMI interrupt and you
are golden... snapshot whenever you want.

Seriously, security is a joke. Nothing is safe. Get over it.

------
_Codemonkeyism
Call me paranoid, but the thing which is strange to me is that Whisper talks
about this defending Facebook/WhatsApp.

This makes me highly suspicion my usage of Signal :-(

~~~
makomk
Facebook's payments to use the Signal protocol pay the bills. Same reason why
Moxie was fine with Google disabling E2E by default so they could use chat for
ad targeting, after attacking other software for doing this, and with them
tying enabling it to inconvenient behaviour like disabling the chat log that
discourages all but the most paranoid from using it.

------
ucy
The real "Whatsapp Backdoor" is that, by default, the app stores a backup of
all your messages on "teh cloud". On android, that's google.

So google can play "eve", and every run of the mill script kiddie that can get
your google credentials may "restore" your messages. How convenient.

And that's the default settings. So, even if you turn it off, "mallory" can
steal the credentials of your contact and snoop into your conversation that
way.

------
theveloped
As with all end-to-end encryption it stops at the "end". It is this
unencrypted state, in which humans consume data, that can't be defended by
crypto.

Therefore the only way to be completely safe, is to make sure both you and
your conversation partner don't decrypt their message until it's on an offline
device only you have access to.

But end-to-end encryption where the interface (mobile app/phone) is controlled
by the parties you want to protect your data from is not possible. WhatsApp
could send freaking screenshots back of the unencrypted data if they wanted.
For nearly all other threat models whatsApp's encryption is a wonderful add-
on.

------
nullc
It's remarkably hard to tell if a key has changed with a peer in signal. It
gives you some small faded text between messages which is easily scrolled off
by the other party making a lot of comments.

Once its off your screen, there is no way to tell that you've never
authenticated the current key. No mark, not even burred in a menu.

So perhaps I should not surprised to see the authors of the worst public key
management security that I've ever actually used defending even worse public
key management security.

------
quickben
I don't user whatsapp, but a general question to these that do:

Can the server change keys twice?

Change once to server keys, ask for the entire history retransmission.

Change again to revert to original receipient keys.

Will the receipient be prompted in that case?

~~~
brainfire
"The WhatsApp clients have been carefully designed so that they will not re-
encrypt messages that have already been delivered. Once the sending client
displays a "double check mark," it can no longer be asked to re-send that
message. This prevents anyone who compromises the server from being able to
selectively target previously delivered messages for re-encryption."

~~~
quickben
Ah, thanks

------
pasta
Maybe I don't get exactly what this means, but isn't it true that if see a
message that someone's signature changed and the other person sees this also
and we both choose to ignore this message the man in the middle can read all
our new conversations?

Ofcourse if then one of us checks the signature later and sees it is not
correct this would be very harmfull for whatsapp.

But this indeed doesn't sound like a backdoor. It's just the way it works.
Which seems good enough.

------
dx034
I don't get the complains here. Whatsapp is used by over a billion people and
offers end2end encryption for them. A system that mainly targets people with
little tech experience can never be kept 100% secure. If they make it harder
to switch phones, people would stop using whatsapp.

The only vulnerability seems to be that they could prevent delivery messages.
I'm sure that most people would notice if they suddenly son't see the 2 ticks,
even if the other person answered. And if you want your conversation to be
secret, that's a major red flag, now that this is known.

And if I get a phone change notification even though the other person didn't
change their phones I'd also be confused at least. When I last changed my
phone, a lot of people noticed because of the notification and asked me. And
those were not tech savvy people, they were just wondering why I got a new
phone.

Spying on conversations (especially by govt agencies) is only effective if the
target doesn't know about it. It seems that Whatsapp has no way of enforcing
that without the user noticing.

------
newsat13
Yawn. Next what, whatsapp is not going to use monetizing to advertise? Why
don't we just all admit that all our data is being plundered by corporations
to make money and just leave it at that? Seriously, nobody cares about their
data being used by corporations for profit. Just be honest about it.. and you
will see that people continue to use whatsapp or signal or whatever the
current fad is.

------
disiplus
> The choice to make these notifications "blocking" would in some ways make
> things worse. That would leak information to the server about who has
> enabled safety number change notifications and who hasn't, effectively
> telling the server who it could MITM transparently and who it couldn't;
> something that WhatsApp considered very carefully.

could not this be saved only localy ?

~~~
ekiru
If resending undelivered messages to new keys waited for confirmation of the
new key when safety number change notifications are enabled, then users
without those notifications enabled would continue to immediately resend
undelivered messages to new keys while users with the notifications enabled
would not resend until the user manually OKed the change. The WhatsApp servers
know (or can know) whether users have outstanding undelivered messages and can
observe whether users resend them immediately after a key change. As a result,
if resends after key changes waited for user confirmation with security
notifications enabled, whenever a user changed keys, WhatsApp would be able to
tell whether any of their contacts who had undelivered messages to that user
had the notifications enabled by observing whether those contacts immediately
resent the messages or not.

~~~
disiplus
thats then a timing attack, but the client could replace the mesaage with a
placeholder and send that immidietly, and the real message after the user
approves. this way server could not know.

~~~
ekiru
I think that could mostly work. The placeholder message would have to be of
identical length to the original and the resent message would have to use
later sequence numbers/message ids (or whatever is used to identify individual
messages) so the server couldn't tell that the placeholders were placeholders.

One issue is that it would mean that, in the case of an active attack where
the server substituted a key they knew in place of a legitimate new key from
the user, the server would be able to decrypt the possibly-placeholder resent
message and determine whether the user had notifications on. If the user
didn't, they'd know that they were safe to continue to attack the user (this
attack is more risky than the passive one on the blocking resend without
placeholder messages protocol, of course). So, this does improve the security
of the protocol for users with security notifications enabled, at the cost of
making users without those notifications less safe. I'm not sure how the
tradeoff should be balanced here (just as I'm unsure if the UX tradeoff of
having the option of not receiving security notifications is worth it...).

~~~
disiplus
to find out if the user has notification on would be the same as doing the
attack, and to find that for all users is the same as mitm all users.

im not sure how is the security of those who dont have notifications on worse
in this case then what they have now.

if i want to i should be able to say if somebody changes the key i want to
first verify the key before i send the message to that person.

lets say you organise a big protest vs some regime. i know who you are and i
know that you comunicate with the number xyz. i redirect that number to my. in
the meantime you send me a list of names that are in our group and adresses. i
reconect with a xyz number and get the list and everything. even if youbget
the notification its to late.

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

~~~
UncleMeat
It isn't possible, in most cases, to trust open source software either. Have
you verified that the binaries on your phone were indeed built from the source
you can read on github or wherever?

~~~
omginternets
Which fully open-source phone platform do you have in mind? I'm not aware of
any.

On desktop and servers, however, it certainly is possible (and not-too-
impractical) to verify binary blobs against known PGP signatures. See Debian's
reproducible builds, for instance.

------
lwyr
Why is moxie doing PR for WhatsApp?

~~~
mos_basik
>Even though we are the creators of the encryption protocol supposedly
"backdoored" by WhatsApp, we were not asked for comment.

It's only a small step from criticism of WhatsApp crypto to criticism of
Signal crypto. Why wouldn't moxie be interested?

~~~
RatherFunky
because here it clearly says that signal had dealt with this problem
[https://tobi.rocks/2016/04/whats-app-retransmission-
vulnerab...](https://tobi.rocks/2016/04/whats-app-retransmission-
vulnerability/) So it is solely whatsapp's fault

------
ryan_j_naughton
Wouldn't a better defense be to not re-transmit messages encrypted with the
new key unless the originating user clicks a button authorizing it AFTER they
have been informed that the receiving user has a new key??

------
FabHK
Response by the finder of the vulnerability:

As Eike Kühl pretty well describes, this functionality only increases
usability in a rare corner case: When you dump your phone in the ocean and you
need a month to get a new one. Then everyone who has sent you a message during
this period will not need to press an additional "OK" button.

[https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a-
su...](https://tobi.rocks/2017/01/what-is-facebook-going-to-do-a-suggestion/)

------
Sami_Lehtinen
Telegram made different choice. Secret chats do get broken, if ephemeral key
renewal fails. Queued messages won't get encrypted with new key automatically.
Of course at times this is annoying.

------
throay123124
I have been contemplating deleting my facebook for 6 months. I finally pulled
the trigger just now. I don't trust the company at all. Too many smokes and
mirrors in what they do.

------
rebuilder
So full-on paranoia mode on: What would you do if you wanted to compare safety
numbers? I'm guessing most people would call and read out the code.

How far are we from targeted interception of calls, with replacement of key
phrases? Voice synthesis seems to be there more or less, if I understood
Adobe's recent demo correctly, but real-time parsing of conversations to
determine where to intervene is probably not close yet.

~~~
makomk
This kind of phrase replacement in calls was on the NSA's priority list years
ago, according to the Snowden leaks.

------
xg15
So if the security of Whatsapp's keys hinges so much on the key change
notifications, why turn them off by default? Why allow them to be turned off
at all?

No one (today) would get the idea to make https warnings optional even though
that audience is even broader than Whatsapp's. (Possibly even _because_ that
audience is so broad)

------
pepijndevos
> We believe that WhatsApp remains a great choice for users concerned with the
> privacy of their message _content_.

What about meta-data? Even Signal uses Google's push service to send your
messages, and WhatsApp is even known to collect meta-data. (IIRC they changed
their EULA recently)

------
t0b
response: [https://tobi.rocks/2017/01/there-is-a-whatsapp-
backdoor/](https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/)

------
kemonocode
If I worked for WhatsApp (Or conversely, if WhatsApp used an implementation of
something I've made, thus making it hugely popular in the process) I'd
certainly say there's no backdoor indeed.

Conflicts of interest.

------
ljk
seems like the original thread has fallen off the front page
[https://news.ycombinator.com/item?id=13389935](https://news.ycombinator.com/item?id=13389935)

------
wslh
Probably it is not a backdoor but still insecure. End to end encryption is not
what they offer but they make you think you are safe. They should clearly
state that in a big splash message.

------
ryeguy_24
Did Hacker News delete the original Guardian WhatsApp article post?

------
zspitzer
What about [https://web.whatsapp.com](https://web.whatsapp.com)? It grants
full access to the entire message archive on your phone

~~~
zaken
Only once you scan the barcode, which contains an encryption key to use for
your phone to securely ship /its/ keys to the browser. Only encrypted messages
are transmitted between phone and browser

------
RRRA
Terrible UX combined with unsane default, at best...

------
maglavaitss
A vulnerability you know of and choose to ignore IS a backdoor. All the rest
is fancy talk.

------
baybal2
They are trying to say that an intentionally placed backdoor is not a
backdoor? ha ha

------
leecarraher
thanks

------
carlos808
The Guardian slipped up again, expect more BS from their incompetent
journalists.

