7 ms·

The gist explicitly claims that's not possible. Specifically, it claims that there's no way for the Saudi teleco to distinguish encrypted phone calls from encry

by eridius 10y ago

The gist explicitly claims that's not possible. Specifically, it claims that there's no way for the Saudi teleco to distinguish encrypted phone calls from encrypted messages, and since you can send encrypted messages to Saudi users, there's no technical reason why you can't also call them. The implication is that if WhatsApp did allow the calls, the Saudi telecos might block both calls and messages (since they can't distinguish them), and so WhatsApp disallows calls to avoid provoking them. And the OP's point is that WhatsApp should detect whether the user is actually in-country and allow the calls if they're in another country (since the Saudi telecos won't matter there).

DominikR 10y ago
You can definitely distinguish with near 100% reliability if someone is messaging or calling, even if there is encryption involved. All you need to do is profile for relatively constant data transfer rates over the course of many minutes that exceed a very low minimum. If Whatsapp uses a media proxy for calls then you could just trigger on connections made to these servers where these data transfers in question occur. But even if they don't use a media proxy they'll the clients will connect to specific IP's for call signalling and that's when you'll also know that a call was attempted. I'm neither defending Saudi Arabia nor Whatsapp, just wanted to let you know that there are very simple ways to detect calls. I'm sure that there are even better, much more advanced techniques that are currently in use by both oppressive (and likely our) governments.
- eridius 10y ago
  Detecting calls like that would be for detecting calls in-progress, not for shutting them down during the initial handshake, which is what the gist claims is WhatsApp's explanation.
  - DominikR 10y ago
    My point was that this is one way to detect the IP where the client connects to for calls as call signalling, call media transfer and chat messaging all connect to different IP's. Once you have that you can block media transfer, or if the clients use peer to peer media transfer at least block the call signalling. After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used. Bandwidth usage pops up in your logs that somehow resembles the profile of a call - investigate by doing a simple test and then block the IP.
    - iamdave 10y ago
      After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used. Erm, well...I suppose this could be done if you're fond of the "navigating through the digestive terminus to arrive at the synovial hinge" method[1]. There are several much easier and much less lossy ways of blocking voice transmissions streams that doesn't involve continuous and arduous logging of IP addresses or even blocks of IP addresses. --- [1] also known as "going through your ass to get to your elbow"
      - DominikR 10y ago
        I wrote myself that there are surely more advanced ways to do that but I'm not a professional in this particular area as I'm not in the business of censoring people or blocking communication. Still my point remains valid I believe: The OP claimed with certainty that no one could know if a call is being made which is wrong. But you can outline your ideas on how to detect a call attempt without "going through your ass to get to your elbow" as you put it. I still feel that blocking IP's or ports is an easy solution for governments that feel the need to censor.
Retric 10y ago
Bandwidth is going to be a major tell even if you have zero clue about content.
- eridius 10y ago
  Bandwidth won't be apparent during the handshake. And voice data isn't really that large anyway, though it would be plausible to detect that some kind of stream is going on as opposed to discrete messages. Still, that would have to come mid-call rather than when the call is attempted.
  - Retric 10y ago
    Sure, in this case it's based on what port they are using. But, it's not a winnable problem due to bandwidth and the option to simply block everything. Limit encrypted streams to 3kbps and you can do eCommerce or slowly send a selfie not real time audio.
Cyph0n 10y ago
This is the correct answer. There is definitely cooperation between WhatsApp and the Saudi authorities. I live in the UAE and it's exactly the same over here.
subliminalpanda 10y ago
WhatsApp calls are made to a different port; I worked at a teleco in Oman and that's how they blocked the calling feature while keeping messaging alive.
- iamdave 10y ago
  To localize this behavior to the US as an example, Verizon wireless is known to block SIP traffic coming and going out of port 5060; it's entirely possible the Saudis are engaging this very similarly and have effectively blocked traffic, encrypted or not coming and going to a specific protocol port. So I don't think saying "there's no way to tell" is entirely accurate
  - subliminalpanda 10y ago
    I believe you would be correct in your assumption. I asked one of the engineers how they did it and that's what they told me to much chagrin.
    - eridius 10y ago
      Seems like WhatsApp could easily choose to use a different port if they wanted to, but I guess this comes back to not wanting to have their encrypted messages get blocked.
      - ultramancool 10y ago
        Yeah, if they push back too much the Saudis would most likely just outright ban the entire service.
      - moxie 10y ago
        VoIP traffic is UDP, and will always be very easy to identify. We barely have functional circumvention strategies for higher-latency traffic types, so building a circumvention strategy for traffic like realtime voice with ultra low-latency requirements is a tall order. Honestly getting VoIP to work well in the best possible network scenarios is enough of a challenge. I assume that higher latency communication like WhatsApp's push-to-talk "voice notes" works just fine in SA though.
dogma1138 10y ago
There are plenty of DPI/TM solutions that identify and classify the protocol very quickly and efficiently, every ISP today does it. It's highly unlikely that a Saudi or any modern telco would would not be able to analyse the traffic and extrapolate the exact protocol and application from it as well as other information such as if it's an encrypted stream or not (heck testing if data is encrypted or not is as simple as running compression on random samples and checking the compression ratio, you'll have to classify if the data is compressed to begin with but if it's not compressed data and it's not compressible it's quite likely to encrypted).
- eridius 10y ago
  This would work for a call in-progress. The gist explicitly claims the calls are blocked during the handshake, which would be before there's enough data to analyze. It appears from other comments that what's really going on is calls simply use a different port and that port is blocked.
  - tptacek 10y ago
    The root comment on this thread resolves that distinction: it might make sense from a UX perspective to block calls that are known in advance not to be workable. WhatsApp can sensibly be reacting to something that occurs once a session is in steady state.
    - eridius 10y ago
      Sure, though I think there's still merit in the OP's request for WhatsApp to detect when a customer with a Saudi number is actually in another country and allow the call to go through (though I don't know how easy it is to detect that).
Canada 10y ago
Assuming WhatsApp uses ZRTP, it's possible to detect and block encrypted calls no matter what port is used because the ZRTP advertisement can be seen in the RTP packet. In order to know when ZRTP will fail WhatsApp would need to maintain lists of address space where ISPs drop such packets. It would have to be done on the client side, but then clients can't easily discover their public address because NAT. The signaling server that sets up the call could check easily, but if the server decided when not to use encryption that would be a backdoor. It's easier to just do it by country code, despite the drawbacks.
- eridius 10y ago
  According to Wikipedia, ZRTP use a specific encryption protocol (SRTP). Surely that means that calls made using Signal can't be using ZRTP.
  - Canada 10y ago
    ZRTP is a key agreement protocol. It sets the key for SRTP, which is ultimately responsible for securing the RTP payload. SRTP keys can also be set by the signaling server, but then the encryption is not end to end. There's another protocol called SDP to handle this Signal does use ZRTP. It just doesn't use SIP. ZRTP is currently the best choice for voice.
    - amluto 10y ago
      > ZRTP is currently the best choice for voice. I beg to differ. ZRTP is currently the best choice for voice when the caller and callee share no key material to begin with. In the context of Signal-the-app, the caller and callee often do share key material, but the protocol (to the best of my knowledge) doesn't bother to use that key material to authenticate the voice channel. This means that two users with the ability to securely text-message each other can still have their voice calls tapped if they fail to validate the short code each time. The same omission also means that you cannot confirm that you have real end-to-end encryption by making a voice call and comparing the short authentication string on the screen. I don't know whether Signal-the-protocol in WhatsApp is better designed, but calling ZRTP a good choice is ignoring the fact that current uses are not well thought out.
moxie 10y ago
The author is incorrect. While Signal Protocol is used to communicate an SRTP master secret and a session id, the clients still need to do an ICE handshake in order to establish communication with each other before the responder can even ring. It is very straightforward for SA to block that traffic, and it is established fact that they do. It seems as if WhatsApp is short circuiting this frustrating series of timeouts to improve a flaky seeming UX. That strategy does negatively effect people on the internet who register for WhatsApp with Saudi VoIP numbers when they're in France, but it is a much clearer UX for almost everyone who is actually a Saudi WhatsApp user or calling actual Saudi users. What the author is demanding is a worse UX for the same outcome. It sounds like there might be room for improvement, but I have a feeling that if WhatsApp were recording their users' locations in order to provide a more advanced location-aware version of the same strategy, people would not be very happy about that.
- stefs 10y ago
  so this does affect foreign users using saudi telcos (roaming/wireless)? how about not blanket-blocking by country code, but by country-ip lookup?
  - pfg 10y ago
    Seems like a lot of effort for an edge case. Now you've added a dependency on some network service you need to access (and from WhatsApp's POV: maintain) before placing outgoing calls. If you use GPS instead, you're dependent on having the location permission (which is not needed to run WhatsApp in general), and you're draining everyone's battery and adding latency to get a sufficiently accurate location lock. Doesn't seem like it would be worth the trouble to me.
    - jlgaddis 10y ago
      There would also be a number of people complaining loudly, demanding to know "why does WhatsApp look up my exact location [using the GPS] at the precise time I make a call!?". Good luck convincing them that the location is not being logged permanently by WhatsApp servers -- or even sent to them in the first place.
walrus01 10y ago
DPI can most definitely distinguish encrypted phone calls and traffic patterns. It's a lot more kbps of flow than messages.

by eridius 10y ago

DominikR 10y ago

You can definitely distinguish with near 100% reliability if someone is messaging or calling, even if there is encryption involved. All you need to do is profile for relatively constant data transfer rates over the course of many minutes that exceed a very low minimum. If Whatsapp uses a media proxy for calls then you could just trigger on connections made to these servers where these data transfers in question occur. But even if they don't use a media proxy they'll the clients will connect to specific IP's for call signalling and that's when you'll also know that a call was attempted. I'm neither defending Saudi Arabia nor Whatsapp, just wanted to let you know that there are very simple ways to detect calls. I'm sure that there are even better, much more advanced techniques that are currently in use by both oppressive (and likely our) governments.

eridius 10y ago
Detecting calls like that would be for detecting calls in-progress, not for shutting them down during the initial handshake, which is what the gist claims is WhatsApp's explanation.
- DominikR 10y ago
  My point was that this is one way to detect the IP where the client connects to for calls as call signalling, call media transfer and chat messaging all connect to different IP's. Once you have that you can block media transfer, or if the clients use peer to peer media transfer at least block the call signalling. After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used. Bandwidth usage pops up in your logs that somehow resembles the profile of a call - investigate by doing a simple test and then block the IP.
  - iamdave 10y ago
    After this it is only a matter of keeping the list of IP's updated which you could easily do by ongoing logging of bandwidth used. Erm, well...I suppose this could be done if you're fond of the "navigating through the digestive terminus to arrive at the synovial hinge" method[1]. There are several much easier and much less lossy ways of blocking voice transmissions streams that doesn't involve continuous and arduous logging of IP addresses or even blocks of IP addresses. --- [1] also known as "going through your ass to get to your elbow"
    - DominikR 10y ago
      I wrote myself that there are surely more advanced ways to do that but I'm not a professional in this particular area as I'm not in the business of censoring people or blocking communication. Still my point remains valid I believe: The OP claimed with certainty that no one could know if a call is being made which is wrong. But you can outline your ideas on how to detect a call attempt without "going through your ass to get to your elbow" as you put it. I still feel that blocking IP's or ports is an easy solution for governments that feel the need to censor.

Retric 10y ago

Bandwidth is going to be a major tell even if you have zero clue about content.

eridius 10y ago
Bandwidth won't be apparent during the handshake. And voice data isn't really that large anyway, though it would be plausible to detect that some kind of stream is going on as opposed to discrete messages. Still, that would have to come mid-call rather than when the call is attempted.
- Retric 10y ago
  Sure, in this case it's based on what port they are using. But, it's not a winnable problem due to bandwidth and the option to simply block everything. Limit encrypted streams to 3kbps and you can do eCommerce or slowly send a selfie not real time audio.

Cyph0n 10y ago

This is the correct answer. There is definitely cooperation between WhatsApp and the Saudi authorities. I live in the UAE and it's exactly the same over here.

subliminalpanda 10y ago

WhatsApp calls are made to a different port; I worked at a teleco in Oman and that's how they blocked the calling feature while keeping messaging alive.

iamdave 10y ago
To localize this behavior to the US as an example, Verizon wireless is known to block SIP traffic coming and going out of port 5060; it's entirely possible the Saudis are engaging this very similarly and have effectively blocked traffic, encrypted or not coming and going to a specific protocol port. So I don't think saying "there's no way to tell" is entirely accurate
- subliminalpanda 10y ago
  I believe you would be correct in your assumption. I asked one of the engineers how they did it and that's what they told me to much chagrin.
  - eridius 10y ago
    Seems like WhatsApp could easily choose to use a different port if they wanted to, but I guess this comes back to not wanting to have their encrypted messages get blocked.
    - ultramancool 10y ago
      Yeah, if they push back too much the Saudis would most likely just outright ban the entire service.
    - moxie 10y ago
      VoIP traffic is UDP, and will always be very easy to identify. We barely have functional circumvention strategies for higher-latency traffic types, so building a circumvention strategy for traffic like realtime voice with ultra low-latency requirements is a tall order. Honestly getting VoIP to work well in the best possible network scenarios is enough of a challenge. I assume that higher latency communication like WhatsApp's push-to-talk "voice notes" works just fine in SA though.

dogma1138 10y ago

There are plenty of DPI/TM solutions that identify and classify the protocol very quickly and efficiently, every ISP today does it. It's highly unlikely that a Saudi or any modern telco would would not be able to analyse the traffic and extrapolate the exact protocol and application from it as well as other information such as if it's an encrypted stream or not (heck testing if data is encrypted or not is as simple as running compression on random samples and checking the compression ratio, you'll have to classify if the data is compressed to begin with but if it's not compressed data and it's not compressible it's quite likely to encrypted).

eridius 10y ago
This would work for a call in-progress. The gist explicitly claims the calls are blocked during the handshake, which would be before there's enough data to analyze. It appears from other comments that what's really going on is calls simply use a different port and that port is blocked.
- tptacek 10y ago
  The root comment on this thread resolves that distinction: it might make sense from a UX perspective to block calls that are known in advance not to be workable. WhatsApp can sensibly be reacting to something that occurs once a session is in steady state.
  - eridius 10y ago
    Sure, though I think there's still merit in the OP's request for WhatsApp to detect when a customer with a Saudi number is actually in another country and allow the call to go through (though I don't know how easy it is to detect that).

Canada 10y ago

Assuming WhatsApp uses ZRTP, it's possible to detect and block encrypted calls no matter what port is used because the ZRTP advertisement can be seen in the RTP packet. In order to know when ZRTP will fail WhatsApp would need to maintain lists of address space where ISPs drop such packets. It would have to be done on the client side, but then clients can't easily discover their public address because NAT. The signaling server that sets up the call could check easily, but if the server decided when not to use encryption that would be a backdoor. It's easier to just do it by country code, despite the drawbacks.

eridius 10y ago
According to Wikipedia, ZRTP use a specific encryption protocol (SRTP). Surely that means that calls made using Signal can't be using ZRTP.
- Canada 10y ago
  ZRTP is a key agreement protocol. It sets the key for SRTP, which is ultimately responsible for securing the RTP payload. SRTP keys can also be set by the signaling server, but then the encryption is not end to end. There's another protocol called SDP to handle this Signal does use ZRTP. It just doesn't use SIP. ZRTP is currently the best choice for voice.
  - amluto 10y ago
    > ZRTP is currently the best choice for voice. I beg to differ. ZRTP is currently the best choice for voice when the caller and callee share no key material to begin with. In the context of Signal-the-app, the caller and callee often do share key material, but the protocol (to the best of my knowledge) doesn't bother to use that key material to authenticate the voice channel. This means that two users with the ability to securely text-message each other can still have their voice calls tapped if they fail to validate the short code each time. The same omission also means that you cannot confirm that you have real end-to-end encryption by making a voice call and comparing the short authentication string on the screen. I don't know whether Signal-the-protocol in WhatsApp is better designed, but calling ZRTP a good choice is ignoring the fact that current uses are not well thought out.

moxie 10y ago

The author is incorrect. While Signal Protocol is used to communicate an SRTP master secret and a session id, the clients still need to do an ICE handshake in order to establish communication with each other before the responder can even ring. It is very straightforward for SA to block that traffic, and it is established fact that they do. It seems as if WhatsApp is short circuiting this frustrating series of timeouts to improve a flaky seeming UX. That strategy does negatively effect people on the internet who register for WhatsApp with Saudi VoIP numbers when they're in France, but it is a much clearer UX for almost everyone who is actually a Saudi WhatsApp user or calling actual Saudi users. What the author is demanding is a worse UX for the same outcome. It sounds like there might be room for improvement, but I have a feeling that if WhatsApp were recording their users' locations in order to provide a more advanced location-aware version of the same strategy, people would not be very happy about that.

stefs 10y ago
so this does affect foreign users using saudi telcos (roaming/wireless)? how about not blanket-blocking by country code, but by country-ip lookup?
- pfg 10y ago
  Seems like a lot of effort for an edge case. Now you've added a dependency on some network service you need to access (and from WhatsApp's POV: maintain) before placing outgoing calls. If you use GPS instead, you're dependent on having the location permission (which is not needed to run WhatsApp in general), and you're draining everyone's battery and adding latency to get a sufficiently accurate location lock. Doesn't seem like it would be worth the trouble to me.
  - jlgaddis 10y ago
    There would also be a number of people complaining loudly, demanding to know "why does WhatsApp look up my exact location [using the GPS] at the precise time I make a call!?". Good luck convincing them that the location is not being logged permanently by WhatsApp servers -- or even sent to them in the first place.

walrus01 10y ago

DPI can most definitely distinguish encrypted phone calls and traffic patterns. It's a lot more kbps of flow than messages.