Yik Yak’s HTTPS communication for iOS is actually fine […] so what’s the problem?
The vulnerability begins in the fact that Yik Yak’s sole means of user identification is one string; the userID. There are no passwords.
Yik Yak, like many apps, does not only communicate with its own server API. It makes other requests to the Internet; external requests from mobile apps include things like advertising, user tracking, and use of other third party libraries. By configuring an iPhone to use a proxy, we were able to analyze all the traffic between the device and the internet. In the case of Yik Yak, we discovered that the app makes calls to a 3rd party advertising/analytics tool called Flurry.
Unfortunately, Flurry, by default, disables HTTPS and sends all traffic over plaintext HTTP. As a result, the [Yik Yak] userID is leaked to anyone who happens to be watching network traffic.
Use HTTPS. Everywhere.
And keep certificate checks in place:
[On Android] the
X509TrustManagerinterface is a method that is supposed to throw an exception if an invalid certificate is provided to the client (the app).
The YY app has replaced the default
X509TrustManagerwith a custom class that does nothing when an invalid certificate is sent by the server.
The internet is scary. Consider keeping private thoughts to yourself.