Created
July 13, 2016 19:10
-
-
Save paragonie-scott/37b36318c8985d86b428a0e65813fff6 to your computer and use it in GitHub Desktop.
WhatsApp Blocking Encrypted Calls to All Saudi Numbers
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Suppose I have a friend named Alice. Alice has registered to WhatsApp with a | |
Saudi number but resides in Europe. We chat over WhatsApp regularly. We are both | |
using the latest version of WhatsApp for Android (2.16.155). | |
However, Alice is unable to receive or initiate WhatsApp calls, even though she | |
is in Europe and is using European WiFi. If you can test this, I suggest you do. | |
Get a Saudi phone number, register to WhatsApp, and then fly to France and make | |
a call. You will encounter the same result even if you're on French WiFi. | |
WhatsApp claims that "the Saudis are blocking the initial handshake [for | |
encrypted calls]" and that this is why encrypted calls are dropped. However, I | |
insist that WhatsApp is dropping all encrypted calls made by, or received by any | |
WhatsApp user that registers with a Saudi number, regardless of whether they are | |
connectiing from Saudi Arabia, the United States via WiFi, or Tahiti. | |
Here is what initially led me to call this claim into question: | |
Reason 1: The call-prohibiting screen [0] is obtained even when Alice is in | |
Europe and using European WiFi. How can "Saudi firewalls" affect her phone then | |
and "drop the initial handshake?" | |
Reason 2: How could Saudi firewalls distinguish an initial encrypted call | |
handshake from a regular Signal protocol handshake if both handshakes are | |
transported over the same Noise-encrypted transport layer? Are they | |
man-in-the-middling the transport layer? How is this accomplished in a way that | |
bypasses static server authentication on behalf of WhatsApp clients? | |
This explanation doesn't make sense even in that respect. Since WhatsApp | |
messages and encrypted phone calls are both initiated and carried over Noise | |
pipes, they are indistinguishable to an active attacker (such as a Saudi telco | |
agency.) WhatsApp knows this, and I strongly suspect they chose to block calls | |
in their apps so that the Saudi government wouldn't blanket-block regular | |
WhatsApp messages as well by dropping all Noise pipe key exchanges: the only way | |
the Saudi government could have stopped encrypted calls is by also dropping | |
encrypted WhatsApp messages, and WhatsApp is dropping calls made from/to Saudi | |
numbers in order to save their text messaging business. | |
To put it simply: because of the way WhatsApp clients communicate with | |
WhatsApp servers, I find it impossible to believe that the Saudi government | |
could drop phone calls and not messages, especially at the key exchange level | |
(which occurs bundled atop a regular Signal session!) This makes me suspect that | |
the WhatsApp client itself is dropping calls if the caller/callee is registered | |
with a +966 number. | |
I then decided to decompile the APK binary of the latest WhatsApp release | |
(again, version 2.16.155). I found evidence that strongly supports my assertion | |
that WhatsApp is blocking encrypted calls purely based on the country code of | |
the registered phone number and without any attempt to even connect the call in | |
the first place, thereby not even giving the Saudi telcoms a chance to "drop the | |
initial handshake": | |
1. In `res/values/public.xml`, we find the string `%s is in a country where | |
WhatsApp Calling is unavailable.`, which is the UI string I presented in [0]. | |
The string is referenced with the identifier `0x7f070612`. [1] | |
2. This identifier, `0x7f070612`, pops up in | |
`com/whatsapp/VoipNotAllowedActivity.java`, which references it in a code block | |
that can be triggered programatically to render [0]. [2] | |
3. The function triggered in [2], `VoipNotAllowedActivity`, can be seen called | |
by a central call provisioning method in `com/whatsapp/App.java` [3]. This | |
central provisioning function first calls a series of functions which determine | |
whether the call recipient has registered with a phone number that is capable of | |
receiving encrypted phone calls. | |
I strongly urge that WhatsApp stop blocking encrypted phone calls based on phone | |
number and allow Saudis to communicate safely. At the very least, WhatsApp should | |
allow users with Saudi numbers to make calls when using data and WiFi networks | |
that are outside Saudi jurisdiction. However the only true solution that respects | |
the human rights of Saudi users is to give them encrypted calls no matter the | |
consequences, instead of downgrading them to using regular Saudi phone lines, | |
which are tapped by a religious dictatorship. | |
Addendum: WhatsApp's claim of Saudis "dropping the initial handshake" | |
is contradicted by their own website. [4] | |
References and media: | |
[0] http://i.imgur.com/rQu9Ocf.jpg | |
[1] http://i.imgur.com/bOfMIPD.png | |
[2] http://i.imgur.com/d6NdoGO.png | |
[3] http://i.imgur.com/i1R6Mu7.png | |
[4] https://www.whatsapp.com/faq/en/general/28030008 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment