Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
There are a variety of other questions that address elements of this security issue, but none that seem (to a non-expert) to address the substantial core of the issues raised in this article:
From a mobile perspective, what are the correct steps the company should have taken to prevent, other than using a CA-issued SSL certificate?
General SSL-related answer: To do SSL (HTTPS) securely, the really important point is that the client system (smartphone, PC... it does not matter) can make sure that the server public key it is using for the SSL handshake is really the genuine one from the intended server. CA-issued certificates are about that, really. Without a validation of the server public key of some kind, MitM attacks are possible. Otherwise, they are not (unless the client and/or server implementation goofs up, but that's another matter).
With certificates, the MitM attack can work only if the attacker can get a fake certificate, with the genuine server name but the attacker's public key in it, from a CA that the client trusts. Incidents with fake certificates being issued are rare (we hear about one such incident per year). Much more often, a gullible user decides to disregard the scary warning from his browser, and clicks through it. If you pay heed to your browser warnings, you should be fine.
Unfortunately, a lot of SSL connections are not between a Web browser and a server, but between an application and a server, and it is up to the application to not do the stupid click-through-warning (metaphorically). There has been a lot of reports of application who do not check the server certificate properly, or at all. This is app-specific and, as a user, this is hard to check.
About Tinder: none of the above applies to the issues described in the article you link to. Apparently, Tinder runs a dating service, with customer running a specific app on their phone; the app talks to a central server. The central server then computes "possible encounters", i.e. warns customers about the nearby presence of other customers with whom romantic compatibility is heuristically estimated to be above average.
It so happens that the dialog between the app and the server involves the server telling the app a lot about other customers -- actually a lot more than should be needed for the described service, including leaking Facebook IDs and other similar information. The app user interface won't show it, but a custom application could obtain such data from the server and record it.
SSL would have done nothing for or against this privacy issue. Maybe they are using SSL; it does not matter. The problem is that the server leaks too much private information to whoever asks for it. A MitM attack is relevant only when the attacker tries to intercept a data transmission containing data that an authorized client may legitimately obtain, but attackers should not; here, the client should not be able to obtain the information in the first place, and that is the problem the article talks about.
The article you mention has nothing at all to do with HTTPS. If an HTTPS connection is used, regardless of desktop or mobile, then the connection is protected between the client system and the server that holds the private key for the certificate being used.
In this case, the API appears to have been operating over a non-encrypted link. Simply encrypting the link and/or not including unnecessary personal information in the API requests would have been sufficient.
