一般 SSL 相关答案：要安全地执行 SSL (HTTPS)，真正重要的一点是客户端系统（智能手机、PC ......没关系）可以确保它用于 SSL 握手的服务器公钥确实是来自预期服务器的正品。CA 颁发的证书就是这样，真的。如果没有对某种类型的服务器公钥进行验证，MitM 攻击是可能的。否则，它们不是（除非客户端和/或服务器实现出错，但这是另一回事）。

有了证书，MitM 攻击只有在攻击者能够从客户端信任的 CA 获得假证书（其中包含真正的服务器名称但其中包含攻击者的公钥）时才能起作用。签发假证书的事件很少见（我们听说每年都会发生一次此类事件）。更常见的是，轻信的用户决定无视浏览器发出的可怕警告，然后点击它。如果您注意浏览器警告，则应该没问题。

不幸的是，很多 SSL 连接不是在Web 浏览器和服务器之间，而是在应用程序和服务器之间，并且由应用程序决定不执行愚蠢的点击警告（隐喻）。有很多应用程序没有正确检查服务器证书的报告，或者根本没有。这是特定于应用程序的，作为用户，这很难检查。

关于 Tinder：以上均不适用于您链接到的文章中描述的问题。显然，Tinder 提供约会服务，客户在手机上运行特定的应用程序；该应用程序与中央服务器对话。中央服务器然后计算“可能的相遇”，即警告顾客附近存在其他顾客，这些顾客的浪漫兼容性被启发式地估计为高于平均水平。

碰巧的是，应用程序和服务器之间的对话涉及服务器告诉应用程序很多关于其他客户的信息——实际上比所描述的服务所需要的要多得多，包括泄露 Facebook ID 和其他类似信息。应用程序用户界面不会显示它，但自定义应用程序可以从服务器获取此类数据并记录下来。

SSL 不会支持或反对这个隐私问题。也许他们正在使用 SSL；没关系。问题是服务器向任何要求它的人泄露了太多的私人信息。仅当攻击者试图拦截包含授权客户端可能合法获取的数据的数据传输时，MitM 攻击才相关，但攻击者不应该这样做；在这里，客户端首先应该无法获取信息，这就是文章要讨论的问题。

您提到的那篇文章与 HTTPS 完全没有关系。如果使用 HTTPS 连接，无论台式机还是移动设备，客户端系统和持有所使用证书的私钥的服务器之间的连接都会受到保护。

在这种情况下，API 似乎一直在未加密的链接上运行。只需加密链接和/或不在 API 请求中包含不必要的个人信息就足够了。