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?

2 Answers 2


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.

  • 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?: i.imgur.com/0MBgayA.png Jul 25, 2013 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, 2013 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.

  • The email referenced in the article: i.imgur.com/0MBgayA.png seems to pretty clearly indicate the engineer was able to MITM hijack the HTTPS? Jul 25, 2013 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. Jul 25, 2013 at 21:45
  • @AJHenderson McAfee details a way to inject removal of validations as well. mcafee.com/us/resources/white-papers/…
    – kouton
    Nov 25, 2015 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. Nov 25, 2015 at 15:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .