There is no WhatsApp 'backdoor'
whispersystems.org
whispersystems.org
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.”
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)
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."
I think it's fair to say that you are the world thought leader on these matters right now.
One thing that the rest of us are wondering right now is:
> I've been impressed with the level of care that WhatsApp has given to that requirement.
To what degree do you really know that? Is there a place where we can read about your interactions with Facebook, the level of access they've given you, and the degree to which they have allowed your recommendations to shape the contours of their implementation?
Nothing less than the strength of dissent lies in the balance of questions like these.
> 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."
I agree that the jump to scary terminology is dangerous.
However, at the end of the day, I think that many of us have been trying to make a simple point that shows that there is a sort of crossing of that line:
WhatsApp claimed that they were simply unable to intercept communications, and now we find out that, without any user interaction or approval, messages which haven't received the "double check" are re-transmitted when a new key is generated.
In some highly specific but easy-to-imagine scenarios (eg, a journalist on the ground in Tahrir Square using WhatsApp to report on conditions, receiving no replies), WhatsApp is hugely vulnerable in a way that most of us didn't think it was.
So look: nobody here is trying to diminish your tireless work and your accomplishments in bringing freedom into the information age.
But there are nuances here that are important, and fleshing them out is a big part of what this community is about.
The entire point of the crypto community is to maintain as little trust as possible unless you can be highly certain about things.
The media reaction to "OMG WHATSAPP IS FOR SURE NOT SAFE" is a HUGE over reaction. But in an industry where audits and open source are huge factors in trust... WhatsApp doesn't do a whole lot. Phrased better, the article could have done a great job of explaining how to secure yourself and enable the messages, rather than just fear mongering.
Lets be honest. Facebook doesn't have a great privacy record. Theyre an advertising and data harvesting company. I basically trust them 0. But I trust Moxie a lot (its possible that he's been bought out by facebook/egyptian government for billions of dollars, but Im just gonna keep trusting him).
Honestly, Moxie saying that WhatsApp has a decent implementation of Signal does a lot more for my concerns than Facebook saying the exact same thing (though I too would love to know more about how much Moxie knows about whatsapp). I don't use whatsapp, but Im less prone to go "oh yeah, you def dont want to use that, its a facebook product!" like i would for skype/MS.
Its reassuring to know that if someone tried this, I could be notified of it, which means it seems like no one would really try this unless it was SUPER worth it (I dont think facebook is going to try to MITM and expose themselves so they can hear about my weekend drinking plans). So for common folk, I think it would be pretty safe. And if you are talking about things that require crazy opsec, definitely turn notifications on and verify those numbers.
The only problem would then be that they can MITM one message, even if they'd be caught that way. I doubt they'd do that for less than world-changing messages, but still that's the only problem if you enabled the notifications and checked the numbers.
What does trust have to do with this? The trade-off has been clearly explained. As it stands, WhatsApp is great for protecting sexts and low value conversations if you're not famous (99.99% of everyone), but if you're snowden, or hillary, there is no protection - contrary to what has been advertised.
That's the world we're in now. I respectfully disagree with Moxie's point about key verification. I think the point you raise about easy-to-imagine-scenarios would've been laughed away years ago, but is not only realistic, but also distinctly possible now.
Whatsapp told the original reporter that they had no plans to fix the issue. The question is that in light of mass spying by the intelligence services, what else will Whatsapp not fix?
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 security warnings should not be displayed to consumers under "normal" (eg. non-critical) circumstances, otherwise it creates a condition of "warning fatigue."
TLS certificate errors are not something that should happen under normal circumstances. When a TLS certificate fails to validate, something is really wrong. As we've gotten better about ensuring those conditions, browsers have made it harder and harder to get past the warnings, because they're not warnings anymore -- they're error conditions.
Key changes in a messenger are totally different. They happen under normal conditions, so putting them in people's faces by default has the potential to do more harm than good. If we can make them workable, systems like CONIKS or Key Transparency might be in our collective future, but if you don't like systems that are fundamentally "advisory" (don't tell you until after the fact), you're not going to like those new systems at all either.
For now, I think a fact of life is that most people will not verify keys whether the warnings are there or not, so I think what's most important is that the server can't tell who is and who isn't.
I'd love to hear other ideas about how to improve the UX of interactions like this, but I think they have to include a basis in the assumption that we can't fundamentally change human behavior and that we can't just teach everyone in the world to be like us.
Warning about unusual account activity seem to be very common these days, so why not using them here.
The way the warnings are presented as part of the chat history (a very good idea) also means they could be used after-the-fact to figure out when an account was overtaken, even if the warning was initially ignore. I figure even non-technical users would like to know that, after one of their contacts tells them their account was hacked.
Additionally, why is an ignored warning worse than a warning that is suppressed to begin with? That seems to me like a landlord that decides not to install smoke alarms because "the tenants could get used to the sound" - when most of the tenants are not even aware of the concept of "fire".
Finally, I don't find the "it's important the server doesn't know" argument not convincing. If you conclude that the vast majority of people doesn't have the warnings enabled and the costs of hitting someone with warnings is low, that would make snooping still a very low-risk activity.
Summing up, I think the very least consequence Facebook should take from this is to make the warnings in-by-default instead of off-by-default.
Warning fatigue, "most" users not knowing how to do it or doing it wrong etc, are indeed hard problems to solve. There are indeed no easy answers to this, or else somebody would have come up with something already. But just because it's not easy does not mean you're entitled to just lie about the security properties of your system to your users.
>WhatsApp's end-to-end encryption ensures only you and the person you're communicating with can read what is sent, and nobody in between, not even WhatsApp. [...] All of this happens automatically: no need to turn on settings or set up special secret chats to secure your messages.
https://www.whatsapp.com/faq/en/general/28030015
Given that the only defense against a WhatApp MITM is turned off by default, the "not even WhatApp"/"automatically: no need to turn on settings" part is just not true.
The funny thing is a VM I setup from my same laptop tried to make an https:// connection and the browser outright refused, without any possible workaround until I imported the Forcepoint CA cert.
Security people must love us users so bad. Love you, too! xox
(Note: the same network team imaged the laptop in the first place, and it's against my contract to re-image it. Hence the Forcepoint CA cert's presence in my browser's root chain. I prefer to call this LAN-In-The-Middle.)
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.
This doesn't have to be the case. If you stop coupling a key to a device and instead couple a key to a person (generating a key deterministically from a password for example), they can be changed far more rarely.
I like to verify keys of my main professional contacts on WhatsApp, but it's hard to remember who you verified keys with, and then whether the key was changed since last time you verified it.
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.
Would you mind elaborating on your chain of reasoning a little bit further?
I'm not sure what exactly is the reason for that, is it UX? like if someone get a new phone and creates a new key pair their friends will get scared because of the warnings?
> 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.
Another fact of life are bad password choices, which is why gmail don't let you use "love", "sex" and "secret" as a password :)
Browsers, for instance, throw warnings when something is wrong with a cert. Even when 99% of the time it's some domain name issue or expiration date, I think it's a nice default. By letting Facebook rekey anytime you (fig) are making them kind of a CA. I don't think there is a good reason for that, specially not when Whatsapp claims that even they can't read your messages... it feels dishonest to me. But then again this is just a messaging app downloaded from Google Play running on Android, my expectations aren't too high...
The problem with key notifications being off is for those users who really want to be secure, and downloaded Whatsapp because they wanted E2E, but didn't know they had to go into settings and turn it on.
The problem with key notifications on-by-default is that regular users see warnings they don't understand and get warning-fatigue.
So how about making a default-on notification that is understandable for all users? Like:
::: It seems like Alice switched to a new phone (i)
where Bob can click the (i) for more info, or just ignore the notification. If Bob was security-conscious, he'd perk up at that message, while the majority would just go "meh" or congratulate them on their new phone.
I would also pop up when someone reinstalled the app.
Would be rather annoying but it should be on as default and the first time it pop up give clear information.
Whatsapp is set to notify you when a key changes, this could be due to a change of phone or reinstalling the app. If you do not wish to receive these notifications click here.
Which would allow users who want it to keep and those that don't to turn it off after the first change.
> 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?
I suppose there must ultimately be some level of trust in WhatsApp that the client is doing what it says it is? Unless we're willing to sniff every piece of network traffic from it.
What exactly do you think is the worst thing that could happen if you "catch" them doing this?
Now what do you think is the worst thing that could happen if they receive a subpoena or NSL or whatever that tells them to do this regardless of whether the user finds out or not (because the government wants the message contents that badly)?
Which do you think will prevail?
[I'm not the OP, but my 0.02]: Hopefully there would be an outcry, initially started by technically sophisticated communities like this, and credible articles in the Guardian, eventually causing significant user anger, and letting competitors gain against them. People running social networks care about mass user anger.
Hopefully that possibility keeps them honest.
Hopefully people don't cry wolf too many times, like today - slowly poisoning the watchdog!
> Now what do you think is the worst thing that could happen if they receive a subpoena or NSL or whatever that tells them to do this regardless of whether the user finds out or not (because the government wants the message contents that badly)?
This has got to primarily be a defense against ongoing mass surveillance. If the government can compel them (via NSL or force or whatever) to change the service so that it just spies on a few targeted individuals, wouldn't it be easier to push these individual a malicious client update, rather than MITM the encryption and hope they have notifications off?
Does anyone know how to build a massively adopted network that resists targeted NSLs? I'm grateful we appear to have one that is resistant to pervasive monitoring.
If you get a new phone without having lost the old one, it would be good to have a feature where Signal on the new phone shows its public key as a QR code, you scan it with Signal on the old phone and Signal on the old phone generates a protocol message to contacts indicating legitimate key roll-over without "key changed but you don't know why" UX.
Then release your product in a manner that let's people improve the UX and correctly label what is and isn't a backdoor.
The server having knowledge of who it can MITM without getting caught is irrelevant if nearly 100% of users verify keys.
I want a better reality.
Wouldn't Coniks provide a more robust defense?
If everyone has enabled by default this setting, the server can't detect who has enabled it on purpose(because everyone has enabled it), or not?
If you're operating under the assumption that users aren't going to check their peers' key fingerprints, then you could just give compromised keys from the beginning -- no rekeying necessary. There's no way to protect against that scenario. That's not a fault of WhatsApp.
> The only question it might be reasonable to ask is whether these safety number change notifications should be "blocking" or "non-blocking." In other words, when a contact's key changes, should WhatsApp require the user to manually verify the new key before continuing, or should WhatsApp display an advisory notification and continue without blocking the user.
You seem to be arguing that they should be blocking. While I agree that's definitely the best choice from a security perspective, I kinda doubt most users would appreciate having to manually re-verify keys every time someone reinstalls WhatsApp or changes their phone. In this case, WhatsApp decided to prioritize usability over security. You and I are of course free to criticize that choice, but it's hardly a "backdoor".
I'd add to the author's statement above and say another question we might reasonably ask is whether the notification should be on or off by default. While my gut reaction to that "On, obviously!", upon giving it a bit more thought I think it's actually understandable why WhatsApp chose off instead.
They're not designing WhatsApp merely for security conscious people, but for the masses. The average user is unlikely to understand or care enough about this warning to manually re-verify keys every time they see it, especially when the vast majority of the time it's just going to turn out to be the result of something mundane, like one of their friends getting a new phone. Honestly, I could go either way on this one.
The auto-resending of unread messages is another issue next to the potential of MITM due to no or unclear notifications about key changes
Users could verify if they have been MITMed by verifying the Security Number (just tap on a contact, view contact details -> Encryption). This assumes the WhatsApp app doesn't just display the old safety number.
The question is: how many users will actually check the Security Number, and recheck all the security numbers now that they were made aware of having to turn on the notification.
What WhatsApp is doing here is like using a self signed certificate to do TLS (your own fault if you did not check the cert yourself using whatever out-of-bands method available) and on top of that the TLS client later by default will not tell you when that self-signed cert changes (and you therefore need to recheck it) and for added bonus routing all traffic through them.
Assuming you have the notification on (Which anyone who cares about security could and should turn on), once you see a warning, you could just delete all messages that don't have the double checkmark (if any) and not send new ones.
The double checkmark stuff the blog talks about just means you cannot retroactively rekey already sent (old) messages. WhatApp inserting itself as a MITM can however read (and double checkmark) and new messages after they did the MITM rekeying
No, as it stands, they are automatically (without user intervention) re-encrypted and re-sent.
They claimed that once a message has been delivered (double check mark),.
> The only notification might be that rekeying warning
The rekeying warning is a fundamental part of WhatsApp's security. If it's disabled, there are many possible attacks, not just this one. The blog entry explains it pretty well.
And the "fundamental part" is disabled by default...
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.
(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 competence at cryptography. But in recent years he's shown himself to be willing to make catastrophic sacrifices to make security applications popular and viable for the "lay person".
If the "lay person" ignores the non-obtrusive key changes, and difference between single and multiple checkmarks (and the timing of them, whether single changed to double after a key change), and 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.
This isn't wrong, but it's unfair to bring it up without the most obvious counter-argument.
PGP provides absolutely zero security to the average person, because average people don't use it. HTTPS provides lots of security to the average person, whether or not they know what the green lock means, because lots of people use it. Adoption is a feature.
Of course both of these things are true. Security sacrifices for the sake of adoption suck. But let's not paint a picture of Signal as "desperate for popularity", as though that was a selfish and not security-minded goal. Be fair.
I believe we got Signal end-to-end encryption in all of these messengers just barely, even as "compromised" as you may think it is. Google and Facebook (Messenger) didn't even enable it by default because they thought it was "too much" encryption.
So if it was even more difficult to use, it may have never been adopted by these services.
At the same time, I don't think we should allow all sorts of modifications to the protocol and to how this encryption system works just to cover a few niche use cases that would slightly increase those users' convenience.
Sending undelivered messages when the recipient is switching SIM cards instead of just telling the sender that those messages can't be sent then is one of those niche use cases and compromises that shouldn't happen, especially if enabling such features could be turned into defacto "legal intercept".
I guess Moxie is saying here that this wouldn't be a defacto legal intercept, but I'm not so sure that's true, and the researcher that found the bug doesn't seem to agree either. I think, unlike others here, it's very likely that people wouldn't notice that the messages don't have a double check mark anymore.
I call those "completely reasonable compromises".
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.
Should we be surprised?
If I am not mistaken the crytography here is compliments of djb. (Best "UX" designer ever, IMHO.)
The Signal author's contribution is only a protocol and some "UX". His programming language of choice was Java.
In other words, the messages are secure only when there is a double checkmark, not just a single checkmark. How am I supposed to know that?!? I am not even sure what do the checkmarks mean.
Frankly, that's not a "backdoor", that's just a poorly thought out GUI (in my opinion), that might eventually lead to backdoors with an evil server.
But when you think about it, the double check is a read confirmation so if we are in an end-to-end encrypted scenario, and the message content was read, it means the recipient's device was able to decrypt it successfully.
This tells you that the recipient is still using the same set of keys that your device thought it had and used to encrypt the message.
I guess the point here is: Can there be a backdoor in whatsapp? Of course!
Is there a backdoor on Whatsapp as described on the guardian article? No.
Can the UX be improved to alert the smaller percentage of users that rely heavily on the encryption features when their communication is not being actively protected without disturbing the UX of the rest of the users? Probably yes,
Hell yes! Imagine jusr changing background color and the banner "somebody spies on you." Now it's something like some checkmark somewhere looks a bit different or whatever.. I'm still not sure what when...
I happen to trust Moxie's principles, but not as much as I distrust the relationship-with-government imperatives implied by FB's vast business interests.
Why do you feel that there's no way to verify closed-source software?
There is theoretically a way to verify WhatsApp even though it's closed source, but it's practically impossible. It's hard enough to verify software even when the source is open, you built it yourself and the whole platform and toolchain is trusted. A bunch of the potential NSA crypto backdoors were totally in the open.
The app could just be lying about resending old messages or even not encrypting them or any number of things much more subtle.
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.
I'd say that's hard for open source software to do as well.
I need a way to verify that binary I am installing is the same as the binary that has been thoroughly vetted by security researches. In the modern mobile app ecosystem, on a major OS, running a major app, I can't carefully pick and choose which binary version to install. I get whatever the OS company's server pushes to me, and I can't downgrade to a known good version.
Isn't that the very definition of security through obscurity?
https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/
Edit to add: It's also on HN (empty so far):
For instance if you're on some list for message interception, they can give you MITMed keys when you first login. Or they can insert some subtle signal that tells the app on your specific phone to ignore key changes and avoid showing notification in some way you would struggle to check (closed source and obfuscated code) etc etc. They could even show you the right key if you attempt verification but use a compromised one for communication. This particular vuln. would be a ridiculously crude way to intercept messages.
In any closed source system where key distribution and message distribution are centralized, there is no way to protect against the service provider - and anyone who co-opts the service provider (eg. with a court order). The objective of the encryption is to protect against other actors snooping on you
Yes, there would be a trace in the binary. Potentially detectable by maybe one person in a million. Is that supposed to keep WhatsApp from including malicious features? I do not think so.
What happens is: 1. researcher finds a malicious part in WhatsApp binary 2. WhatsApp declares it a bug and fixes with a new binary 3. we are back at square one
So it only works once against a string of messages with no replies. That's not a conversation.
* when the client is compromised, you're screwed anyways, so let's assume the client behaves as expected.
* now, with "proper" e2e, and Alice and Bob verifying key fingerprints, their messages can't be read even if the server gets compromised.
* as it stands now with WhatsApp, AFAI understand, the server could be compromised to take Alice's message, send it on to Bob, but withhold the "delivery receipt". It could also pass back Bob's answers, and so Alice could have what appears to be a normal conversation - except that Alice only sees single ticks, instead of double blue ticks.
* then, the server could send the "hey ho, new key" message, and Alice's client would re-encrypt and re-send all messages that it thinks haven't been delivered yet, the ones with a single tick. After that, it would display the "key changed" msg to Alice (if she had set that option).
No, it can't do this, because Bob's answers contain the "delivery receipt".
Hence, the attack doesn't work on conversations.
EDIT to reply: messages are sequential and "delivery receipts" are messages, so it would be visible if the attacker dropped some but not all messages. AFAICT.
I've not seen any specific claims about the mechanism for the delivery receipt - can you link me to this?
It's not even clear to me that the delivery receipt is signed.
(Greetings from HS F13 :)
https://tobi.rocks/2016/04/whats-app-retransmission-vulnerab...
And, presuming you are seeing reply-messages from your peer and having a back-and-forth conversation, I don't think it's actually possible for those reply-messages to not implicitly also be ACKs of your own sent messages—the Axolotl ratchet underlying the protocol ensures that (I think. Crypto people chime in?)
So, yeah, you can probably get a retransmitted transcript of one person talking into a void without seeing any delivery ticks in response. You can't really get a conversation.
If there are cases (like this) where a single-message compromise is a big deal, and WhatsApp cares about these cases, then the simplest solution would be for WhatsApp to add a preference in the client to switch on—as the article describes—a "blocking mode" for re-key notifications, where retransmissions aren't allowed by default.
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]
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...
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.
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.
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?
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...
Wow, even Microsoft didn't behave that juvenile about LibreOffice.
The project is also kind of a mess. Check out their privacy policy, Wire maintains a server side copy of your entire contact list, all the groups that you're in, the plaintext metadata for your groups (membership, plaintext group title, plaintext group avatar).
Check out some of the code. They have broken voice encryption, and leak enough data to reconstruct the audio of your calls. They leak tons of plaintext directly back to themselves, like searches, and rolled their own messaging crypto.
They have been caught lying about what kind of encryption they provide[1], they lied about being open source for years, they lied about being based in switzerland. From what I can tell, the only people promoting Wire are usually on Wire's marketing team.
1: http://www.pcworld.com/article/2855745/new-communications-ap...
GitHub message about fallback to WebSocket you are referring to is here: [1]. So you can remove all Google services from your phone and install APK, it will still work, but now Wire server pings your phone whenever it wants. TLDR on the thread is that APK is not uploaded to F-Droid due to dependency (not really) on Google services.
[0] https://developer.android.com/training/monitoring-device-sta...
[1] https://github.com/wireapp/wire-android/issues/5#issuecommen...
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.
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.
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.
Especially as ESL are usually kept secret within the company, this would be too risky, developers would ultimately find such a backdoor (especially since it generates a lot of server traffic).
I can't think of a company I trust less than Facebook.
I can use cash at Walmart
Never heard of Glencore or Phillip Morris.
As for Blackwater and Palantir, my impression from the media is they do exactly what they say. It's not like Palantir lies about harvesting data to give to government. I trust that they actually do do that.
None of those companies have posted fake news and altered the news algo with the express intent of manipulating users' mental states for reasons that basically boil down to "for the lols" and "let's see if we can make money from this".
The amount of passion in your comment and this gap in knowledge don't go well with each other. I encourage you to at least read about Philip Morris (or watch John Oliver's episode about them at least).
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.
And hardware too.
But how often is that really done? And to be honest, it can be quite hard to spot critical bugs or backdoors, just look at http://www.underhanded-c.org/
I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
The argument here is that open source code can be verified where closed source is explicitly non-verifiable by nature.
> but that the binary was built from this code
Doesn't code signing address this? If not could you explain (for my own learning)?
https://en.wikipedia.org/wiki/Code_signing
> that your operating system and every layer below it is also trustworthy.
Yep, this is the last major piece for true security in my mind. Although there is some movement in the open hardware space as well as USB mounted OSs (http://gizmodo.com/try-the-super-secure-usb-drive-os-that-ed...).
> I stand by my claim that using software written by a malicious developer is game over in the vast majority of contexts.
Sure...perfectly accurate...but in the context you are implying that WhatsApp is malicious. To which I think "hackuser" was interpreting as "closed source is malicious" and therefore offering open source (and by implication Signal) as an alternative.
Might just be a miscommunication moment :-)
This is not a belief that people who actually do software security audits hold. Verifying binary only software is table stakes to a security audit of a third party application as you cannot trust the source provided.
Having source is a bonus for security audits not a requirement.
No.
OpenWhisper system otherwise GPLv3 auditable libraries are closed source for usage by WhatsApp and Facebook Messenger. Either OpenWhisper systems has elected not to enforce their copyright (in which case you could make a BSD/MIT/Apache fork of their software), OR they have consented to Facebook allowing them to circumvent the license.
Eitherway. The code in WhatsApp is off limits for anyone not working with Facebook so well never know. Closed source crypto is bad. We only have WhatsApp's word the Facebook libraries have no modifications.
As far as I can tell this 'backdoor' is only relevant for the scenario where WhatsApp is not actively malicious, but gets taken over by a malicious entity, which wants to target someone who's disabled updates.
Has anyone performed such an audit?
https://play.google.com/store/apps/details?id=com.googlecode...
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.
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..
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?
Otherwise you'd have to hope that no one reverse engineered the binary and noticed the oddly specific comparison there.
Right?
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.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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.The issue here is that:
1) the vast majority of users have those MITM notifications off by default (because WhatsApp decided it's best that way)
2) WhatsApp generates its own keys in some scenarios, like when people switch their SIM cards, so the "trust on first use" that worked on the original SIM is gone out of the window now, and the users won't even know it because the notification is off by default.
Actually now that I think about it, this is why WhatsApp must have let the notifications off by default, because they knew they would generate their own keys this way, which would generate a lot of those notifications all the time.
>>[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.
All you disagree on is implementation:
Author: "[Non-blocking defaults] provide transparent and cryptographically guaranteed confidence in the privacy of a user's communication, along with a simple user experience."
You: "Enable notifications for everyone and demand verification; if you don't want to verify, just tick "verified" without actually verifying."
How are these two substantially different? They look the same to me in terms of security and WhatsApp's implementation doesn't make you click anything.
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).
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.
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.
ALICE: Here they are: 12345678. [tick mark]
[Eve on the compromised server to Alice]: Hey ho, new key, please send again.
ALICE [with new MITM key, and no way to block this]: Here they are: 12345678.
!!! By the way, Bob's key has changed. !!!
BOTH: Ooops.
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/whatsapp-...
When my partner's key changes:
[ ] Show me a notification (y/n)
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)
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.
Moxie correctly assumes that confirmation option (require manual confirmation to resend if key changes) should either be enabled for everyone or disabled for everyone, as its state can be determined passively by the server. But it depends on the notification option. His conclusion is that confirmation option should be disabled for everyone because if it is enabled, it is possible to leak notification option state. But it is wrong. More secure solution exists: enable notification option for everyone, and then enable confirmation option for everyone.
I was complaining about why notification should be an option. Even worse, disabled by default.
Wire [0] just shows "resend" button near message when it is not delivered and always shows notifications about key changes if you have verified devices. You can still ignore verification option if you want and get no notifications.
Signal blocks with a message when key changes.
Both solutions are secure, Wire's is more convenient, Signal is less error-prone. WhatsApp solution is simply insecure.
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.
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.
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.
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.
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.
"WhatsApp server has no knowledge of whether users have enabled the change notifications, or whether users have verified safety numbers."
If it's off by default, then the answer is likely to be near zero, as it often is with default options. This isn't an argument about the security of the app (which I have no background to know), more of a comment on relying on non-default behavior.
Even if you enable the key change notification, it is "non-blocking" in WhatsApp as outlined by the blog post: when you get the key change notification, the WhatsApp client will automatically without user intervention resend undelivered messages (unlike Signal, btw, from what I understand).
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...
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?
edit: nvm, if this is man in the middle then that doesn't matter because you still exchange with each other and its not a hijack. Sorry, I made a mistake.
A few would inquisitively ask "Yes, how did you know?", then I would explain them to them the notification I got.
- 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
[2] - http://www.businessinsider.com/how-apples-culture-of-secrecy...
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.
As people perhaps, but there's a big difference in how prone to error someone is when speaking within their area of expertise than when speaking outside of that area.
The problem with most journalists is that they're required to write on many different subjects, write for an audience whose only exposure to the subject will be a few thousand word article, and write all of this on a deadline that is sometimes just a few hours or days. You can't really understand a subject under those constraints, and it's inevitable that misconceptions will creep in.
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.
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.
I know this isn't your point, but we don't know Musk; we know his (intentionally, carefully curated) public image
I guess it's possible that the journalist completely fabricated the story, but I think it's a lot more likely that either someone at Apple overstated their relationship with Lattner to vent their own frustrations, or Lattner is trying not to burn bridges. At worst it's an avoidable inaccuracy, not a war.
Oh well, can't figure out the actual facts, better just publish whatever i do have?
Seriously. Also, the "i tried to contact you" is clearly a BS defense.
It wasn't a "reasonable effort".
This is a reporter. They know that people basically never respond to interview requests during what amounts to the busiest times in their lives, and so the reporter asked just so they could say they tried.
Otherwise, they would have held the story a week or whatever until they could get a comment. Because it would be just as interesting then if it was any good.
But nope, gotta try to get it out while anyone gives a crap about the story flavor of the week because it's not substantive enough for anyone to care otherwise.
If you just assume that both players in this story are human beings trying to do their jobs, you'll understand that neither of them did anything wrong.
The Guardian story was good. Perhaps it is slightly overblown, but it is arguable both ways, and it certainly highlighted a real issue.
Musk is way over defensive and never admits a problem of any kind, and in most of the stories about him there is a problem of some kind.
I haven't followed the Latter story at all.
I think it's more that the media is biased against corporations, because positive information about corporations sounds like an advertisement or is instead attributed to the employee. Headlines like "Zuckerberg fires 100 employees" or "Wal-mart saves puppy" seem to be either rare or nonexistent.
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.
This makes me highly suspicion my usage of Signal :-(
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.
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.
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.
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?
No. the WhatsApp client will not retransmit messages that have already been acknowledged by the recipient device.
Of course, you'll have to trust that this is the case; but obviously you'd have to trust the the WhatsApp client app isn't backdoored in the first place, so there is no change in security posture.
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.
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.
could not this be saved only localy ?
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...).
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.
Software being closed source doesn't make it impervious to analysis. Software being open source does not mean it has been analyzed.
I don't ever want to change the tires on my car, but I think it's essential that I have the ability to change the tires on my car.
What do you think Iran/the NSA/any TLA is more upset about, WhatsApp using the Signal protocol, or Matrix and Riot?
It's only a small step from criticism of WhatsApp crypto to criticism of Signal crypto. Why wouldn't moxie be interested?
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...
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.
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)
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)
Conflicts of interest.