Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 3 down vote accepted

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.

share|improve this answer
Thanks. I'll take this as the answer. Any further ideas on how you'd protect against what the engineer that discovered the problem shares in this email?: – Marc Cenedella Jul 25 '13 at 21:31
@marccenedelia You can't protect yourself against that, as your information is being leaked between the server and any client - not necessarily yours. The company in question has to make sure that it doesn't hand out more info than absolutely required to clients. In the case of the service in question here, the amount of information required to run the service is already more than many people would be willing to part with. If you are one of them, your only protection is not using such services at all. – us2012 Jul 31 '13 at 1:33

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.

share|improve this answer
The email referenced in the article: seems to pretty clearly indicate the engineer was able to MITM hijack the HTTPS? – Marc Cenedella Jul 25 '13 at 21:30
Ah, ok, they are apparently not validating the SSL certificate is trusted. That's a pretty big flaw as well, but is just an incorrect implementation of SSL within their app. Proper implementation of SSL should verify that the server certificate is trusted prior to sending data. – AJ Henderson Jul 25 '13 at 21:45
@AJHenderson McAfee details a way to inject removal of validations as well.… – kouton Nov 25 '15 at 8:40
@kouton those only apply if the attacker has control of your device. At that point ssl is irrelevant anyway. That white paper is more about legit uses of mitm ssl proxy and how to make specialized device configurations to allow monitoring of ssl connections. The general rule is that if someone has control of the device doing encryption and decryption, you can not be secure. – AJ Henderson Nov 25 '15 at 15:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.