HTTPS 作为一种保护客户端/服务器通信的方式“足够安全”吗？答案

【问题标题】：Is HTTPS as a way of securing client/server communication "secure enough"?HTTPS 作为一种保护客户端/服务器通信的方式“足够安全”吗？
【发布时间】：2010-06-23 12:28:46
【问题描述】：

我正在开发的应用程序执行某种服务器端授权。通信是通过安全通道完成的（在我的例子中是 HTTPS，带有有效的 SSL 证书）。我计划实现一些东西来验证远程服务器是否正是他声称的那个人。

我知道没有任何客户端保护是牢不可破的，尤其是在有足够的时间和知识的情况下。但是，如果我实施我上面描述的，这种安全方法是否“足够安全”以保护数据在传输过程中不被篡改，或防止中间人攻击，并确保其有效性?

我正在考虑为传输的数据添加另一层安全性（通过使用私钥/公钥对），但我怀疑依靠 SSL 可能就足够了，而无需重新发明轮子。

【问题讨论】：

标签： security communication

【解决方案1】：

SSL 使用有效证书就足够安全了，但是 ...

很多人不知道收到无效证书错误意味着“您的数据可能会被其他人拦截”。他们只会忽略警告，中间人攻击仍然有效。此外，如果证书无效，某些较旧的浏览器（如 IE6）甚至可能不会向您显示任何警告。在这种情况下，问题在于用户，而不是所使用的技术。这意味着，与其尝试构建另一层安全性，不如告诉使用您的应用程序的人遇到无效证书错误意味着什么，以及为什么他们应该使用现代浏览器。

【讨论】：

在我的具体场景中，用户不是流程的一部分（并且他们几乎自动忽略与证书相关的警告），但证书有效性应由客户端程序自动确定。当然，恶意用户可以在客户端劫持该进程，但它比 MITM 攻击更难拉。这是否会改变故事以支持安全性？
使用带有“真实”证书的 SSL 使客户端信任服务器。但是如果你需要建立一个服务器->客户端信任（控制哪个客户端可以访问服务器），你应该使用某种身份验证。一种方法是在每个客户端/浏览器中安装 SSL 客户端证书，或者使用带有用户 ID/密码的 SSL 加密。
当我说人们忽略警告时，这是因为大多数人对“无效证书错误消息”的反应是简单地单击“忽略”或“继续”。它与是否有恶意软件没有任何关系，它只是关于人们对这种警告的行为。软件正确识别无效证书，但用户只是选择忽略错误并继续。这是 SSL 唯一可能出现的问题，它与软件没有任何关系，而与使用它的人有关。

【解决方案2】：

先生。乙，正如您提到的客户端将验证服务器 SSL 证书并且用户不是流程的一部分，我认为您将很好地验证服务器 SSL 证书。但是，您必须妥善处理验证过程。我见过几个客户端应用程序对证书的验证不够好。 “足够好”是指客户应该验证 - 1）认证机构 2）持续时间 3）发布给我正在渗透测试的其中一个应用程序有一个错误，它正在验证证书的“CN” - 这可以被欺骗（可以使用任意 CN 创建一个伪造的证书）。

【讨论】：

感谢您对我的问题提出宝贵意见！你能告诉我为什么要验证持续时间吗？这将阻止我在服务器端扩展证书，而无需客户端干预，对吧？
让我们假设服务器证书的有效期为 2 年（比如 2010 年到 2012 年）。假设在 2013 年，该证书的私钥被泄露，并且服务器的所有者已经撤销了 SSL 证书。如果客户端软件不验证证书的持续时间，它将信任受损的 SSL 证书。证书的持续时间因素有助于减少暴露于受损证书的风险。
好点。但是，它也使客户端从旧证书到新证书的转换变得复杂，对吧？基本上，它提高了安全性，但使部署复杂化，这是经典的安全性与简单性的权衡。将证书有效期限制为一年是否是个好主意？这会进一步降低妥协的风险，不是吗？
是的，你是对的。这是经典的安全性与简单性的权衡。如果您使用 .net 框架进行客户端开发，您可能会很幸运，证书验证可以/由 .net 框架自动处理，您不必担心处理证书过期等问题。根据您的威胁模型/风险评估，您可以调整证书到期日期。