我有一个移动应用程序(iOS)，它在URL中发送带有GET变量的服务器请求。
现在，所有请求都是SSL安全的，这意味着我们只对所有请求使用HTTPS。
现在它不在浏览器中，所以没有历史记录，也没有人真正看到URL，我们禁用了对服务器上服务器日志的所有访问(这两个事实与所有其他类似问题不同)。
话虽如此，假设传递的GET变量是安全的，不会被"中间人"攻击入侵，这安全吗？
严格来说，"中间人"攻击仍然可以执行。最大的问题是它对最终用户是否透明。
中间的人仍然可以劫持最初的SSL握手并返回自己的SSL证书。证书可以是正确的域名等，但区别在于(希望)它不会由可信来源(即证书颁发机构(CA))签名。如果你的应用程序识别出这一点并停止通信，那么你就可以了。另一方面，如果你的程序没有通过可信的CA检查真实性，那么你会与黑客协商一个会话，然后黑客可以看到你的流量，检查它，然后将它发送到真实的服务器进行处理。黑客也可以看到来自真实服务器的所有响应。
如果黑客能够以某种方式用受信任的CA密钥签署他们的欺诈证书，那么就无法阻止他们。这种情况很少见，但CA可能会受到损害。
在网络浏览器的情况下，这种攻击会向用户显示"停止，发生了可疑的事情"的消息，这在后来的浏览器版本中变得更加明显。尽管如此，最终用户还是可以接受不可信的证书，从而有效地允许黑客进行窃听。如果你的应用程序(或iOS本身)允许这样做，除了尽可能多地教育用户之外，你几乎无能为力。
总之，如果您的应用程序与目标服务器协商SSL通道，并确保返回的证书由受信任的权威机构签名(并且不会询问用户)，那么您应该没事。所有HTTP流量，包括GET/POST谓词和之后的标头，都将被加密。再警告两句是有道理的。
- 这就是为什么设备(在这种情况下是iOS)必须非常小心地保护其可信权限文件("根CA")
- 您需要使用安全密码进行底层通信。对于非关键数据(即非个人信息)，RC4可能很好，而且可能更快。对于任何个人事务(如银行业务)，都要尽全力。如果不是默认值，我建议使用AES-256
SSL为您的请求提供了一个加密通道，但正如您所知，一旦请求到达目的地，您的访问日志将记录纯文本变量。
如果您发送的信息在任何方面都是敏感的，那么您应该使用POST。这将阻止web服务器记录变量。它还将阻止您的安全请求从其他域调用(同源策略)，如果这与您的有关
不要忘记，您的请求可能会通过代理，这些代理也会记录消息。