Recently, the Guardian published a story claiming that WhatsApp’s end-to-end encryption was inadequate, detailing a vulnerability that allowed WhatsApp’s servers to silently change a user’s key and force undelivered messages to be encrypted and resent under this new key, allowing WhatsApp to remotely decrypt messages for targeted users.
Shortly after publication, a number of prominent security and cryptography experts published a rebuttal, claiming the story was irresponsible and calling for its retraction. The rebuttal’s argument is that this “vulnerability” is actually a known and carefully considered property of WhatsApp: the developers had to settle a trade-off between security and usability, and the developers reasonably choose usability.
However, despite having a great deal of respect for the experts that signed this rebuttal, I disagree with their conclusion.
There’s no doubt that end-to-end encryption is hard to get right, and that security applications have difficult usability trade-offs where difficult decisions must be made. But these difficult choices do not excuse vulnerabilities that are clearly within an application’s threat model (the set of capabilities and adversaries that we wish to defend against).
And to be clear, “WhatsApp could be (compelled to be) malicious” is within the threat model of the application. If it weren’t, we wouldn’t need end-to-end encryption at all. We could simply trust the WhatsApp servers and use TLS between clients and the server to protect messages. But WhatsApp has gone to the effort of adopting Open Whisper System’s implementation of off-the-record end-to-end encryption. Furthermore, they claim that “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.” We should be worried about the WhatsApp server being compromised or compelled to do things against the will of its users.
Still, the rebuttal points out that the exploitation of this vulnerability is “a remote scenario requiring an adversary capable of many difficult feats.” While true, it is also true that this “remote scenario” is well within the threat model for WhatsApp.
Hand-waving over security holes in cryptographic protocols or applications is not an appropriate response to a vulnerability, and we don’t do this for other protocols. When we discover problems with TLS, we fix them: When the Lucky Thirteen attack was published, security experts did not dismiss it as requiring an “adversary capable of many difficult feats.” Instead, we hardened the constant-time code in CBC modes, or removed CBC modes entirely. When evidence suggested the NSA and other well-funded adversaries may be able to perform discrete logarithm attacks on common small Diffie-Hellman groups, we didn’t label this as a “remote scenario”. Rather, we moved to server-specific Diffie-Hellman groups or moved away from finite field Diffie-Hellman key exchanges. When we discover vulnerabilities in cryptographic protocols, we fix them or stop using them altogether.
So what can we do about the WhatsApp vulnerability? What’s the fix here? That’s where things get tricky: There is no silver bullet or easy answer. WhatsApp could warn users when a key has changed, but as the rebuttal points out, users may become frustrated by extraneous warnings or prompts that require them to approve key changes. Worse yet, those frustrated users might choose to stop using the app and switch to plaintext or other less secure (but more user-friendly) messaging applications, ultimately harming users. This is a difficult challenge, and remains an open problem to solve. But just because we don’t have an easy solution to a problem doesn’t mean that we can ignore trying to solve it. If the best you can do is not enough to defend against your threat model, your application is not secure. At the very least, we should not be making false claims, such as “not even WhatsApp can read your messages” when the developers purposefully decided on a trade-off that makes that not true by default.
It is important that we allow stories like the Guardian’s to point out when the Emperor isn’t wearing any clothes. Even though WhatsApp is doing everything right in terms of the best practices that we know about does not mean they have done enough. WhatsApp’s version of end-to-end encryption is a step in the right direction, and helps protect billions of people from mass surveillance. But the best we have been able to come up with should not be immune from criticism, even if we think that criticism will cause non-expert users to do non-expert things. It is irresponsible to tell users white lies under the belief that it’s ultimately for their own good.
In this case, the rebuttal warns that the Guardian story will cause users to distrust WhatsApp, and switch to less secure apps for communication. The rebuttal likens the article to publishing a headline “VACCINES KILL PEOPLE”, which might cause more people to refuse vaccination, ultimately killing more people. However, there is a subtle but important difference between that claim and the Guardian article. Vaccines are not currently lying prominently on vaccination websites and throughout the medical community about the impossibility of death. In contrast, WhatsApp is specifically telling users that they do not have to trust the WhatsApp servers for the privacy of their messages, when in fact they do. Rather than worry about what damage such uncomfortable truths could do to non-expert users, we should instead be worried about the original false statements that lulled users into a belief that they were safe when they weren’t. WhatsApp should not claim their messages are end-to-end encrypted when the trade-offs they have consciously made leave room for WhatsApp to circumvent these protections.
This vulnerability was responsibly disclosed to WhatsApp several months before the Guardian article was published. Instead of fixing the problem, or clarifying the statements about the protection they provide, Facebook (WhatsApp’s parent company) responded to the researchers by essentially saying this was “expected behavior” and that they wouldn’t fix it. That’s an insane position to take about a vulnerability that’s not only inside your threat model, but is the main threat that motivates using end-to-end encryption in the first place. If end-to-end encryption is not important for WhatsApp users, it should be removed in favor of a simpler protocol. If it is important (and I think it is), why isn’t it worth talking about if not fixing this particular vulnerability?
I don’t think users should stop using WhatsApp over this vulnerability; encouraging users to switch to other applications would very likely put even more users at risk. But I also think that WhatsApp should not get a free pass simply because we don’t actually know how to provide real end-to-end encryption to a billion users in a usable way. Instead, we should not tell users that something is end-to-end encrypted when by default it is not.
Secure messaging is a hard problem, and there remain many open problems to be solved. WhatsApp is pushing end-to-end encryption in a positive direction, protecting a huge number of users, and should be applauded for moving us toward a more secure world. But it has not yet fully solved this difficult problem, and it’s important that we in the security community keep them honest, rather than help cover up partial truths for what we believe to be the greater good.