Whatsapp is a quite popular chat application that every user loves and 99.55% security admins hate. Users love it because an additional encryption layer provides them privacy, security admins hate it due to that same additional encryption layer that blinds their security tools. That said, as of today it is not possible to inspect Whatsapp traffic, but we are able to manipulate a little bit of it and mitigate some of the issues.
First of all, the scenario in mind is a desktop/laptop using the traditional Whatsapp application and also the browser version as both operate similarly and this seems to be a common concern related to data exfiltration and productivity.
If you need to block this traffic completely, just add a Cloud App Control rule for Collaboration & Online Meetings as Zscaler Internet Access provides an out-of-the-box app:
If you need to apply more granular controls, keep reading… 
One myth related to Whatsapp is that it pins the certificate to protect its communication path yet this is not true. If we turn on SSL inspection for this traffic (*.whatsapp.com and *.whatsapp.net), the app won’t break and some visibility is revealed:
The first two URLs on the above screenshots are almost identical and provide some insightful details:
media-gru1-2.cdn.whatsapp.net : The host section defines how the CDN can be reached;
/mms/image/ : this path defines what kind of media is being accessed;
The rest identifies the content and who is accessing it. Not really important at this time.
Thus if a user is trying to access or sending an image to another fellow or group, it will always rely on an url that contains *.cdn.whatsapp.net/mms/image/* .
Not so fast. Take a look at the third and forth URLs:
media-gru1-2.cdn.whatsapp.net/v/t62.7118-24/30987240_1590282731368368_8329308349979241637_n.enc?ccb=11-4&oh=01_AVxe9qVe4eeKLO1HwHITkMUpzcEFAfC_smLfkpyGP8SpCQ&oe=6336A711&hash=GlBBAvZxtQ7OSwWiDQK-HxPw225KKxwk-yqryyxoa-w=&mode=auto&mms-type=image&__wa-mms=
Same host but where is the /mms/image/ path prefix? Yeah, no prefix and still this is an URL used to reference an image. But everything’s not lost, notice the mms-type=image tag inside the path. This also identifies the media as an image.
In short, if you need to control images, allow/block urls containing the path *.cdn.whatsapp.net/mms/image/ and the keyword mms-type=image&__wa-mms=. Why add the &__wa-mms? This will reduce the probability of other URLs containing our magic keyword.
This technique can be extended to control not only images but almost* all medias used on Whatsapp:
| Media Type | URL | Keyword |
|---|---|---|
| Audio | .cdn.whatsapp.net/mms/ptt/ | mms-type=ptt&__wa-mms= |
| Document | .cdn.whatsapp.net/mms/document/ | mms-type=document&__wa-mms= |
| Image | .cdn.whatsapp.net/mms/image/ | mms-type=image&__wa-mms= |
| Sticker | .cdn.whatsapp.net/mms/sticker/ | mms-type=sticker&__wa-mms= |
| Video | .cdn.whatsapp.net/mms/video/ | mms-type=video&__wa-mms= |
In practice you may create a Custom URL Category for all the above URLs and block all in one shot:
Or you may want more granular controls and create a Custom URL Category for each type of media:
Lastly, apply the desired URLs Categories into an URL Filtering policy and that’s it:
And one more (cool) thing: we can manipulate the http request method too! Why is this important? You can address a use case where you allow a user to view all images but won’t be able to send any. Nice isn’t it?
Bonus Stage: Audio and video calls run on 3478/UDP. If you block this port all calls won’t be established.
Final note: Media such as Location and Contacts are sent as text to the chat and the app will render it as a map or a nice Icon. I have not tried Payment, if you are interested in that please reach me to send me some cash and we can analyze its behavior together… ;D
20221014
Update: Whatsapp tries to send (post) media multiple times before giving up.
Make sure that you also control the host mmg.whatsapp.net or blocking uploads may fail.
