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.
To my understanding, that's simply not true. What you can accurately say is that with key change notifications turned on, any one* message could be exposed without any means of recourse, but subsequent exposures would require user error.
*Question for anyone: could this apply to a "batch" of messages? That is, could servers hold back the delivery of some number of messages and then the attack could be applied to all such undelivered messages? But once the attack took place, the double check would be displayed on the sender's phone and the notification of key change would appear. My understanding is that the answer to the question is 'Yes'.
The responses by Bob are presumably numbered, and some might be delivery receipts, or contain delivery receipts (e.g. A cumulative ACK as in TCP). Could the server selectively suppress the read receipts, or manipulate the cumulative ACK? If it simultaneously triggered rekeying on Bob's side, presumably yes. But not seen a definitive statement on that.
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.
Because of exactly what Moxie said in his post. This is a relatively common occurrence in practice. Someone gets a new device. Or uninstalls/reinstalls the WhatsApp app. Or wants to read messages on their laptop, too. And so on.
Warning everyone about this all the time leads to people becoming subconsciously blind to these notifications — even to people who should care about them. The solution taken by WhatsApp is a great compromise in this situation. Not everyone will have it on, but the odds are in favor that someone they might want to intercept messages for will. And if they can't know who has the notifications enabled and who doesn't, they run the risk of tipping their hand that they're doing it at all.
So yeah, it is actually kind of like rocket science, and I guarantee you that Moxie has spent orders of magnitude more time thinking with, dealing with, and collecting data on this kind of problem than you or I combined.
Furthermore, this is an argument via authority[1]. Of course there are experts, but even an expert should explain and discuss his rationale in the interest of sharing knowledge (which moxie is doing here) - otherwise problems like this will stay "hard" for a long time.
And Moxie has explained his rationale in this thread. Argument to authority isn't always wrong — particularly in the case where the other side has no data or theory to back up their claims. For instance, I personally only know little about the actual mechanisms behind anthropogenic climate change. What I do supports the notion. But I'd be lying if I didn't acknowledge that the most compelling argument is the absolute agreement by 99.9%+ of the actual experts in the matter.
Likewise, in the absence of any obviously compelling evidence validating GP's approach, combined with Moxie's explanation above and my own experience as a security engineer, I'm going to go with the guy with literally decades of both theoretical an operational experience here.
The entities this is designed to thwart are not going to want to risk leaving behind a trail of evidence, even if the risk is small.
It also prevents fishing expeditions, since the risk would quickly add up as more targets were added.
All that said, a one-time prompt to turn on the notifications for users that care about extra-strong security seems like a good idea to me.
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.)
The alternatives are running agents on your machine that capture everything you do (which most shops I've been at do as well) and removing local administrative rights to prevent users from removing auditing software and deploying workarounds like your VM (also the norm now).
This has absolutely no bearing on the security of HTTPS/TLS as a whole, the chain of trust is working exactly as it's supposed to in this instance. It's distasteful as an end-user (and even more distasteful as one of the network engineers deploying it, wondering why it's not Information Security's job instead), but you can always quit that job and find another one (yep, that's what I did).
"In Europe, there is technically no uniform body of “European law” that directly applies between employers and employees"
"Courts and scholars increasingly reference EU law, usually without clarifying whether the existence of a particular civil right protection in the EU Charter actually changed the legal situation as a matter of law, rather than as a matter of public policy."
There's a lot of fuzziness around implementation of a very loosely worded human rights clause, combined with prior national laws. Mostly aimed at protection from Government. Previous tests have mostly been cases where the individual did not consent or some such thing.
More directly, EC data protection directive hinges on: 1) contractual obligation; 2) consent; 3) statutory obligations; 4) balancing test. It seems highly likely that most business can legally MITM me if I sign the contract they want me to sign.
Most - but not all - of the private sector examples given (including Germany and France) hinge on the employer not following the correct process: either not notifying the employees, not gaining consent, or opting to allow private communications at work which are strictly forbidden from being monitored (in some countries).
That said, there is also:
"A number of EC member states, including Germany, Italy, the Netherlands, Spain, and the United Kingdom, strictly prohibit ongoing monitoring of employee communications and permit electronic monitoring only in very limited circumstances (e.g., where an employer already has concrete suspicions of wrong-doing against particular employees),265 subject to significant restrictions with respect to the duration, mode, and subjects of the monitoring activities"
It's not immediately clear if the applies to specific, targeted monitoring. The footnote says gives an example where informing the employee of valid reasons for investigating is sufficient.
The pages I gave are specific case studies of the law in Germany & France. You are right that there is not too much overarching EU level legislation about these things, it's generally in national legislation and up to each country.
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.
For some reasons everybody uses an address book, many people let browsers remember passwords but almost everybody resists the idea of using a password manager and end up with low entropy passwords.
How would these 'trivial' steps look like if a telephone gets stolen or upgraded? What easy steps did Facebook & Moxie overlook?
Just as 'trivial' as it is Facebook to swap your key at the request of a government. You should have to start from a blank slate (zero trust) in that situation.
Getting your phone stolen is an extraordinary event that warrants requesting some attention from your contacts, even if only to inform them of the old identity being compromised. And then you might as well have them verify a new key.
Buying a new phone and switching to it Reinstalling your phone OS because "it's slow" Reinstalling WhatsApp because "it crashes" or "it's slow" Swapping a phone because the screen is broke or I dropped into the toilet
I think it's romantic to think that 1 billion of WhatsApp users can be taught about the risks of MITM attacks and how to do a key check.
This is what I do: I have the warnings turn on. When the key change warning appears, and if I care enough about the person and the discussions we have, I try to match the warning with a real world event, so either I already know that something happened, or I try to remember to ask somehow if the person repaired or changed the phone. If I can match the warning with such an event, I feel satisfied. Otherwise, i ask for a key check when I meet that person in real life.
It would help if WhatsApp provided a UI to show whether I have verified the current key of each user (something like a green check-mark next to the name) because it's hard to remember.
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.
Not paying Verisign your rent? That's an "error condition".
(Here of course referring to the choice of browser vendors to block access to web sites that offer secure end-to-end crypto via TLS, but merely haven't paid a browser-trusted CA to issue a new cert with a future expiration date.)
Would have been a fair statement a couple of years ago, but we live in a day when you can get free annual certs manually (Startssl) and free 90 day certs automatically (Letsencrypt).
LetsEncrypt just barely left beta (also this summer) and I'll admit that I haven't investigated it thoroughly, but it appears that some widespread devices are still incompatible (also consider the versions that accept LetsEncrypt; some of those are fairly recent, like CM 10). [1]
While some noble souls like LetsEncrypt have sought to remedy this rent-seeking behavior, it remains the fact that in most cases, a traditional CA is going to be required for a couple more years at least.
[0]https://www.schrauger.com/the-story-of-how-wosign-gave-me-an...
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.
Without understanding these technologies very deeply, they are all creating a false sense of security to some degree.
That doesn't make your statement false, just very difficult to apply. That's not to say it can never be applied. There are clearly cases in which people are deliberately mislead.
But whatsapp markets itself as a secure system when the client just blindly accepts re-keying from the server without notifying the user by default,
It could easily have the notification on by default, and when a user turns it off actually explain that you are no longer secure.
The very best would of course be to require the users to physically exchange keys whenever they get a new phone etc, but we all know this will never happen.
But my point is that the current approach is not simply "false security". It is incomplete or optional security against specific threats and not others. Depending on a particular user's expectations it may amount to false security. You're right about that. But it's not clear to me that having this sort of security is worse than nothing for the average user.
Also, you have to consider that this sort of optional and partial security used by a very large number of people allows those with real security needs to hide in the crowd. Taking a clear all or nothing approach, as you suggest, would put a bullseye on the back of those who do need security.
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.
(Almost always) when someone mentions the 'impossibility of analysis' of closed-source programs they are actually referring to the difficulty in doing so -- not actually stating that it's impossible.
It is easier to look through source code.
Now, if we're progressing through this conversation according to script, it will be mentioned that open source projects have had tremendous security problems, too. (OpenSSL comes to mind..)
But that's beside the point expressed.
The only point, and it's the point that was originally expressed, is that open source code is easier to look through than a closed code base.
The hurdles posed by closed source, although not impossible to jump, significantly hinder the progress of analysis.
Is this not true?
Meanwhile, addressing your (different) argument directly: sure, reading C code is easier than reading assembly code, and reading Python is easier than reading C. The easier it is to read a program the easier it is to reason about it.
But:
* It's not terribly difficult to reason about the functionality of messaging software in any language.
* WhatsApp is an extremely high-profile target; it would be weird if people hadn't reversed it by now, since less well-known programs that are much harder to reverse have been productively (as in: findings uncovered) reversed.
* The particular things we're looking for in a program like WhatsApp fall into two classes: (1) basic functional stuff like data flow that is even more straightforward to discern from control flow graphs than the kinds of things we routinely use reversing to find (like memory corruption flaws), and (2) cryptographic vulnerabilities that are difficult to spot even in source code, because they're implemented in the mathematical domain of the crypto primitives regardless of the language used to express them to computers.
Sure, though. It is easier to spot backdoors in open source software. It's just not capital-H Hard to do it in closed-source software, so this open vs. closed debate about backdoors is usually a red herring.
No, you are oversimplifying the problem a lot.
In an Open Source project it is possible to create transparency in the development process by every commit public and allowing 3rd parties to mirror the sources repositories as well as perform reproducible builds, sign the artifacts and so on.
Once a project has been reviewed, it becomes pretty difficult to sneak in a backdoor later or deliver a backdoored build only to some specific targets.
In case of closed source smartphone applications it's very Hard to reverse engineer every single release simply because it takes a staggering amount of work.
It's also Hard to verify that some unsuspecting users are receiving a "custom" apk and block the update automatically.
Nope to what? Are you saying that binary diffing is possible or that the amount of effort required is (remotely) comparable with analyzing source code?
I would like to see evidence supporting the latter statement, if this is what you are saying.
Consider all the people who study closed source browsers (MSIE) and plugins (Flash) to write malware. Consider all the people who reverse engineer malware to write protections or ransomware decryptors.
The people who can do such work don't work exclusively for the NSA and Google, and you can probably hire them for $1000 a day. but none of them will do tricks for you for free just to prove that they exist. They're too busy making money.
I saw some of the work described in this [1] excellent paper on reverse engineering NSA's crypto backdoor in Juniper equipment being done live on twitter. People exchanging small pieces of code, piecing together all the changes that were made in order to allow passively decrypting VPN traffic.
At one of the better-attended Black Hat USA talks last year, a team from Azimuth got up and stage and walked the audience through an IDA reverse of the iOS Secure Enclave firmware. Your argument is that it's somehow harder to reverse a simple iOS application?
When you only have decompiled assembly, obfuscation is much easier.
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.
That's not true. The design of a language can make it easier to verify with respect to certain properties. For example, it is much easier to verify that a typical Python program does not dereference dangling pointers than a typical C program.
It is true that open source does not help as much as some of its adherents like to think. But that doesn't mean that it doesn't help at all, and it is certainly not true that it cannot help substantially in principle even if it does not help much in current practice.
[1] Which I'll note was written and verified in Coq a high-level proof-oriented language.
https://blog.trailofbits.com/2014/08/07/mcsema-is-officially...
There are a bunch of other lifters, not all of them to LLVM.
Already, with the idea of IR lifting, we're at a point where we're no longer talking about reading assembly but rather a higher-level language. But this leaves out tooling that can analyze IR (or, for that matter, assembly control flow blocks).
Someone upthread stridently declared that analyzing one version of a binary in isolation was hard enough, but that the work of looking at every version was "staggering", "capital-h Hard". But that problem is in some ways easier than basic reverse engineering, which is why security product companies and malware research teams have teams of people using BinDiff-like tools to do it. "BinDiff" is a deceptive name; "Bin" refers to compiled binaries, because the tools work based on graph comparisons of program CFGs.
Part of the problem I have talking about this stuff is that this isn't really my area of expertise --- not in the sense that I can't reverse a binary or use a BinDiffing tool, because most software security people can, myself included, but in the sense that I'm describing the state of the art as of, like, 6 years ago. I'm sure the tooling I'm describing is embarrassing compared to what our field has now.
Open vs. closed source is an orthogonal concern to verifiability.
The evidence you have presented does not support this conclusion. All you've shown is that it is possible to reverse-engineer object code, but this was never in doubt. It is still an open possibility (indeed it is overwhelmingly probable) that it is a hell of a lot easier to audit code if you have access to the source. All else being equal, more information is always better than less, and, as I pointed out earlier, the constraints imposed by some languages can often be leveraged to make the verification task easier.
"You can demonstrate the presence of a vulnerability in closed source software but there's no way to demonstrate (or even provide evidence of) the absence of any vulnerabilities." [Emphasis added] (Also please note that I very deliberately did not use the word "prove".)
Your response was:
"That's identically true of open-source software."
If you acknowledge that it is easier to audit source code then it cannot be the case that anything is "identically true" of open and closed source software (except for uninteresting things like that they are both subject to the halting problem). If it is easier to audit source code (and you just conceded that it is) then it is easier to find vulnerabilities, and so it is more likely that vulnerabilities will be found, and so (for example) the failure of an audit conducted by a competent and honest agent to find vulnerabilities is in fact evidence (not proof) of the absence of vulnerabilities.
But if you have source code written in a language designed to admit formal proofs then it is actually possible to demonstrate the absence of certain classes of vulnerabilities. For example, code written in Rust can be demonstrated (maybe even proven) to not be subject to buffer overflow attacks.
The point you made is orthogonal to the question of whether we can understand and evaluate ("verify") closed-source software.
Let me try to advance a different thesis then: it is possible to write software in such a manner that the source code is amenable to methods of analysis that the object code is not. Accordingly, for software written in such manners, it is possible to provide certain guarantees if the source code is available for analysis, and those guarantees cannot be provided if the source code is not available. Would you agree with that?
So, it's an interesting question, and one I have much less of a strong opinion on.
If you can't tell, my real issue here is the idea that closed-source software is somehow unknowable. I know you're not claiming that it is. But I think if you look over these threads, you'll see that they tend to begin with people who do believe that, or claim to.
Over the years interacting with you here on HN, I think this basically sums up the worldview that puts you and I at odds:
> Open vs. closed-source software is a concern orthogonal to verifiability.
Is there a place where you have written at length, defending this assertion?
I am open to it. But it does not resonate with my understanding, nor my (substantial, I think) experience in deployments of open- and closed-source software with specific respect to verifiability.
If you are using a casual, inspection = verification definition then I think most would agree that it is true that open source is easier to inspect.
But "verified" software often means formal mathematical verification, and that is orthogonal to if the source is open.
I think there may be cross-talk here related to who's doing the verifying too. I think the parent is assuming "verification" would imply that a 3rd party could verify the software in question. AFAIUI it's currently nowhere near practical for a 3rd party to verify closed-source software of any non-trivial size. (Correct me, if I'm wrong, obviously.)
It's still a research problem even for open-source unless the software is built with formal verification in mind (for example in Coq or Agda), but at least there's an existence proof that it's possible to do for non-trivial software (see CompCert C). That was still a multi-year effort and it's still a somewhat (architecturally) simple program as compilers tend to be.
I do agree that 'who is verifying' is a valid way of looking at it too.
Regardless, it's pretty clear that tptacek means formal verification.
More parties have the opportunity to be verifiers of open software. However, a given OSS program might not attract skilled verifiers.
That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.
Now, you say that open source (e.g. C) is not only easier, but qualitatively different: open source good, closed source bad.
tptacek points out: higher level (e.g. Haskell) is easier to reason about than lower level (e.g. C) - maybe even qualitatively.
So, why are people only complaining about closed source, when they should (by analogous reasoning) be complaining about code written in C? Granted, it's possible to analyse, but it's obviously easier when it's written in Haskell!
If the vendor is lazy about verifying code, it being closed is a big disadvantage. "We're not combing the code for bugs, and neither is anyone else; if it's not reported to us, it doesn't exist."
I would guess that programs in a Turing-incomplete language will be easier to verify than ones in a Turing complete one.
I'd say that's hard for open source software to do as well.
EDIT: WTF people? Why is every response to this comment being downvoted into oblivion? The sibling comment to this one (https://news.ycombinator.com/item?id=13395657) was killed in a matter of minutes despite being (IMHO) a perfectly reasonable and constructive response.
(That comment is incorrect but I agree with you that it's constructive).
Introducing backdoors into open source source is also more difficult.
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.
Could it just eat them all?
EDIT: after a quick look at the spec¹, it seems that it supports out-of-order messages, meaning the server could selectively eat receipts.
[1] https://whispersystems.org/docs/specifications/doubleratchet...
(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.
t1: Server sends message (1) to Client B
t2: Client B fails to decode message (1) due to an outdated key. Sends failure notification to Server
t3: Server sends rekey notification to Client A
t4: (usually <400ms or >1 second) Client A sends rekeyed message (1') to Server for Client B
For t4, if the Server notices the response from Client A came faster than a user could ever have seen and responded to a notification, it now knows Client A is more susceptible to a MitM attack. If, on the other hand, Client A takes an appreciable amount of time to send the rekeyed message (say, 1 second or more) then we know that either there was a network latency, or the user had to respond to a rekey notification before the message was resent. We should be more careful about launching a MitM attack on this class of user.
So, without changing the actual _actions_ that the Server sees, but just the pattern of the timing of those actions, we're still leaking important information.
Note: all numbers completely made up.
I was more thinking along the lines of discharging rekeyed messages and not showing the message at all to security conscious receivers. Whether this is behavior is good, I can not say, UX tests could give more insights.
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.”