在证书错误的情况下允许用户通过 HTTP 连接的最佳指南

信息安全 http
2021-09-06 14:41:33

我已将我的应用程序编码为使用 https,但如果 https 事务由于任何原因失败,我认为这是因为服务器未配置为 https,然后使用 http 启动所有事务。似乎这是一个漏洞。同样,一个脚本小子使用代理拦截其客户端硬件上的流量将能够使所有 https 事务失败。

有人告诉我,如果有人尝试 MITM 您的应用程序的 HTTPS 请求,那么请求应该失败(无效证书)并且您的应用程序应该失败并出现错误,而不是回退到 HTTP。当然,在 SSL 可靠可用的世界中,维护有效的 SSL 证书本身就是一项任务。例如,由于一些安全问题,letsencrypt 最近撤销了他们的一些证书并强制更新。除了吊销之外,证书是短期的并且必须更新,更新过程涉及很多缝合工具,并且可能会失败。如果 SSL 出现故障,我不希望我的网站变暗。

什么是最好的指导:

  1. 更可靠地维护证书(这样,如果它们确实失败了,由此产生的停机时间落在“五个九”SLA 不可用窗口内),而不会让人头疼,或者

  2. 如果 SSL 失败,是否允许站点继续工作?允许大多数活动使用 http 进行是否容易,但允许已知的关键事务需要 https。

请注意,与我有关的场景中不涉及任何浏览器。

4个回答

我已将我的应用程序编码为使用 https,但如果 https 事务由于任何原因失败,我认为这是因为服务器未配置为 https,然后使用 http 启动所有事务。似乎这是一个漏洞。同样,一个脚本小子使用代理拦截其客户端硬件上的流量将能够使所有 https 事务失败。

那么,您是否控制服务器?它要么是为 https 配置的,要么不是。SSL 可能会失败,但您更有可能遇到其他问题,例如 httpd 服务因某种原因崩溃或服务器过载。结果是一样的:服务中断。

有人告诉我,如果有人尝试 MITM 您的应用程序的 HTTPS 请求,那么请求应该失败(无效证书)并且您的应用程序应该失败并出现错误,而不是回退到 HTTP。当然,在 SSL 可靠可用的世界中,维护有效的 SSL 证书本身就是一项任务。

您应该自动部署和更新证书。尽可能自动化,始终如一。如果任务很无聊,那就是自动化它的另一个原因。

但还要确保如果过程出错,您的脚本会发送警报。既然你提到让我们加密,如果我没记错的话,他们确实提供了一些脚本。

如果您只有一台服务器并且想要手动完成,请至少将续订日期添加到您的议程中。不要等到最后一刻才更新您的证书。

如果您选择使用 https,那么您应该坚持使用它,而不是设计变通方法来破坏您自己的安全措施。如果服务可用性很重要,您可以通过在网络架构中添加更多服务器/端点来提高冗余。然后,如果所选服务器不可用,您的应用程序可以尝试另一台服务器。

降级传输层不是一个好的举措,并且可能会出现更多与 SSL 无关的问题。你的努力应该集中在使服务更有弹性。

建议:记录网络服务器错误,例如 SSL 协商失败(很可能您的网络服务器软件已经这样做了),然后确保尽快向您报告严重错误。设置一个日志收集器什么的。如果没有人注意,日志将毫无用处。

如果 SSL 失败,是否允许站点继续工作?允许大多数活动使用 http 进行是否容易,但允许已知的关键事务需要 https。

您可以,但您必须将“敏感”流量与临时流量分开。这可能意味着添加一些应用程序逻辑。由于上述原因,我认为它没有多大价值。

我用不同的方法为这个问题提供了三个不同的答案——点击这里这里查看其他答案。我这样做是为了允许对所有答案进行独立投票、评论和接受。

维护有效的 SSL 证书本身就是一项任务

这实际上听起来像是雇用某人为您做这件事的一个很好的案例。为了使 SSL 尽可能简单易用,我们付出了很多努力,以便每个人都已经开始使用它,但我明白了。对某些人来说,有些任务是难以理解的。他们已经做好了一切准备,刚喝下一杯新鲜的咖啡并坐在办公桌前,但他们几乎无法敲击键盘,然后就马上准备再喝一杯咖啡。(我应该知道 - 我在网上约会时就是这样。)

幸运的是,并不是每个人都对任何给定的任务都这样。有些人可以在睡梦中设置可靠的 SSL 证书流。许多其他人发现这项任务很困难,但无论如何都喜欢进入那种事情的杂草(包括我自己)。如果您可以在您的朋友组或专业网络中找到可以为您做一些 SSL 配置的人(或者作为一名正在从事其他工作的成熟员工,或者只是几个小时的会议),那么您可以找到自己使用可靠的 HTTPS,您无需接触任何东西,特别是如果它们为您所做的一切是完全自动化的。

编辑:澄清一下,这很可能在实践中通过让团队中的另一个开发人员也可以帮助其他事情来实现。拥有另一个开发人员也会使您对站点中断更有弹性,因为你们中的一个更有可能起床并手动解决它们。

我用两种不同的方法为这个问题提供了三个不同的答案——点击这里这里查看其他答案。我这样做是为了允许对所有答案进行独立投票、评论和接受。

让我们假设您尝试过的所有事情都经常发生证书错误(可能是因为您尝试设置证书,到处使用它们,但仍然无法让它们足够可靠地工作)。我们还假设您发送的数据不够重要,以至于绝对需要 HTTPS 加密(例如,您不使用真钱做任何事情)并且您可以不加密地发送它。在这种情况下,在一种情况下继续进行 HTTP 降级可能是安全的:知情用户同意

这对您来说本质上意味着您的 HTTP 降级不应该是在用户背后自动进行的。相反,如果您在网站上遇到证书错误,您应该按照现代浏览器遇到此类错误的示例并通知用户,可能会使用某种对话框。让他们知道 SSL 证书已失败,虽然他们在技术上仍然可以继续,但这将以加密为代价 - 然后他们可以在他们想要的选项之间做出选择,并在他们自己的同意下继续进行,你现在知道你的连接是脆弱的。

当然,当要求用户做出这样的决定时,存在一个道德问题,即要求用户公开他们发送的数据是否正确,这取决于您希望处理的数据类型. 一般来说,用户可以合理发送的数据越自由,就越不道德,因为自由数据很容易成为秘密数据。这在国际市场上尤其棘手,用户发送的敏感数据可能包括他们甚至在使用该应用程序这一事实,具体取决于用户的管辖范围。

即使您可以确定该选择可能是一个合乎道德的选择,但它不应该是一个盲目的选择 - 大多数用户都受过培训,只要您允许他们点击“是”,即使他们约束自己出售他们的长子婴儿。大多数浏览器在提供证书绕过选项时,最初往往根本不提及它,而是将选项隐藏在一些听起来不祥的“高级选项”按钮后面,只有技术人员才会愿意点击。

而且,毕竟,一旦您允许了不安全的 HTTP 连接,您可能希望对它进行不同的处理,因为它已经受到损害,可能会直接拒绝某些交易并限制其他交易的影响。例如,可以合理地将 HTTP 事务限制为只读,并且不允许它们影响任何状态。

只是不要。试图让你的 https 连接回退到 http 是一种基本攻击,之后你的所有流量都可以被同一个 mitm 访问。

您正在尝试做的事情与系统地通过 http 没有区别。

仅仅因为 https - 在您看来 - 偶尔维护起来有点复杂,这并不足以成为将其扔出窗外的充分理由。