如何修复SSL/TLS握手失败?

0
2378

本文主要讲述互联网用户和网站所有者可以如何修复SSL/TLS握手失败错误。

与许多SSL错误消息一样,SSL/TLS握手失败可以从客户端和服务器端触发,因此,有时,普通互联网用户就可以修复它,但其他时候,有证据表明,是网站的配置出现了问题。

无论来源如何,该SSL错误可能都是令人沮丧的,因为它会阻止你与你试图访问的网站建立安全连接。

然而,不用担心,接下来我们将深入了解什么是SSL/TLS握手,SSL/TLS握手失败的原因以及修复它的具体方式。

让我们来看看吧。

什么是SSL/TLS握手?

在每个HTTPS连接开始时,客户端(互联网用户的web浏览器)和服务器(托管网站)都必须通过一系列检查来相互进行验证,并确定加密连接的参数。

TLS握手主要完成三件事:

  • 将服务器验证为非对称公钥/私钥对的合法所有者
  • 确定用于连接的TLS版本和密码套件
  • 交换用于通信的对称会话密钥

如果你想要简化PKI——作为整个SSL/TLS生态系统的基础设施——实际上你是在处理有关安全密钥交换的问题。在HTTPS连接期间,通信实际上是使用在客户端生成的对称会话密钥(通常是256位AES密钥)来完成的。对称密钥生成后,双方都会得到一个副本,然后就可以使用它进行加密和解密。

虽然256位加密仍然足够强大,但真正起到保护作用的是一个长度更长、安全性更高的私钥(通常是2048位RSA密钥),因为它帮助处理了连接的身份验证问题。身份验证很重要,因为客户端希望确保连接的另一方是正确的。从本质上来说,这就是握手的目的。它会在对两端的客户端和服务器进行身份验证时进行一系列检查,确定出HTTPS连接的参数(将会使用的密码套件),然后客户端会对会话密钥的副本进行加密,并将它发送到服务器,以供连接时使用。

一直以来握手都会使连接有所延迟,这导致一部分人称,HTTPS会减缓网站的运行速度。但是,最近几个版本的TLS协议已经解决了这一延迟的问题,因此该问题几乎已经不存在了——特别是在HTTP/2和HTTP/3中。

目前,有两个不同版本的TLS握手。TLS 1.2使用的握手会在客户端和服务器之间进行多次往返。

我们并不打算逐步阐述,但从本质上来说,这一过程包括客户端和服务器彼此进行连接, 然后SSL/TLS证书出现,客户端对其进行身份验证,彼此交换受支持的密码套件列表并就其中一个达成一致,最后交换密钥。

1.3将TLS握手简化为了单次往返。

很明显,这减少了连接启动所需的时间——我们在这里讨论的是毫秒,所以可能并不是很明显——并使一切变得更有效率。TLS 1.3还允许0-RTT恢复,这将进一步简化后续与支持TLS 1.3的网站的连接。

但是,考虑到TLS握手中不确定的因素很多,如果网站或设备配置错误,那么就有可能出现诸多问题。几年前,我们写过关于修复Firefox中TLS握手失败错误的文章,但是那篇文章比这更通用。现在,我们就来谈谈TLS握手可能出现的问题以及如何修复它。

SSL/TLS握手失败错误概述

为了使这篇文章更容易进行理解,我们计划把SSL/TLS握手失败所有可能的原因以及谁能修复它们都列举出来,然后我们将逐一讨论如何修复它们。

现在让我们来深入研究一下如何解决这些问题,我们可以做什么,然后我们讲述将一些你绝对不应当在客户端进行的事情,不管是否是为了修复这一错误。

SSL/TLS握手失败——客户端错误

每次握手失败时,通常都是网站/服务器及其SSL/TLS配置出现了问题。

实际上,此时只是TLS配置不再支持SSL 3.0。

但是,在一些上下文中,客户端错误也有可能导致SSL/TLS握手失败。其中很多看起来都微不足道,比如确保系统时间的正确性和浏览器的更新。

但是,正如我们所讨论的,TLS握手中不确定的因素很多,有时甚至是最微小的问题都有可能导致整个过程失败。

因此,让我们来看一下几种客户端修复办法。

不正确的系统时间

我真的不确定为什么有人会将其系统时钟从通用时间选项中去除,但很明显这是事实。也许你想要像某种精神病患者一样遵守自己的个人时钟,或者可能只是设置不小心更改了,但是如果你的系统时间错误,就有可能导致TLS握手问题。

由于SSL/TLS证书的生命周期有限,所以时间设置十分重要。事实上,在一些非常引人注目的证书过期案例中——比如有关Oculus Rift VR系统的案例中——互联网用户甚至故意将系统时间设置到了证书过期日期前,以便在证书到期时仍然可以连接。

很显然,不要这样做。如果你的系统时间是正确的,但SSL/TLS握手仍旧失败,那么问题就来源于其他地方。

浏览器错误

这并不是一个浏览器错误,这实际上是你的浏览器犯了一个错误。有时你的浏览器可能会配置错误,或者插件可能导致工作方式稍有不同,从而导致连接到其他合法网站出现了问题。虽然准确地诊断出当前浏览器上需要更改的内容可能有点困难,但解决办法相当简单:只需要尝试使用另一种浏览器。

如果你使用的是谷歌Chrome浏览器,则切换到你的操作系统的原生浏览器,比如苹果的Safari或微软的Edge,或者如果你有的话,切换到Mozilla Firefox。

只要打开它,然后试着连接到网站。如果SSL/TLS握手仍旧失败,那么你就知道这不是浏览器的问题。但是如果你能连接,现在你就知道你的插件或设置出了问题。

修复这个问题最快的方法就是将浏览器重置为默认设置并禁用所有插件。在这里,你可以根据需要配置浏览器,从而在不断进行调整的过程中测试与问题站点的连接。这可能需要一点时间,但如果浏览器配置错误或出错,这确实是解决问题的唯一方法。

中间人(Man-in-the-Middle, MITM)

人们通常将MITM描述为试图窃取信息或造成伤害的邪恶黑客,但事实上并不是这样的。为了检查或负载平衡等其他目的,许多程序和设备都会拦截流量,然后将其发送到应用服务器。这也构成了一个MITM。

不幸的是,这些设备上的问题有时会导致TLS握手失败。它可以是阻止连接的网络防火墙,也可以是服务器端网络上边缘设备的配置——因此这个问题实际上可能还是客户端的问题——或者根据情况的不同,是服务器端修复的问题。

事情是这样的,如果这个问题存在于客户端,那么你可以更改防病毒或VPN的设置,但这会将自身暴露在外。通常,应该可以建立一份白名单,将存在疑问的网站排除在外,但千万不要关闭防火墙或防病毒软件,只是单纯地连接到网站。如果问题存在于服务器端,则可能是边缘设备上的配置出现了问题。最近,Ross Thomas就告诉我,他处理过这样一个设备,为了表明它通过了检查,这个设备试图拦截流量,然后再附加上一个小数据串。这导致数据校验和散列失败,还可能会干扰身份验证。

再一次地,有太多可能的原因,因此很难用一种方法概括,但是,如果你有设备正在试图检查或拦截流量,那么这可以作为参考。

SSL/TLS握手失败:服务器端错误

大多数时间,SSL/TLS握手失败都是由服务器端的问题引起的。其中一些很容易修复,一些稍微复杂一些,还有一些可能根本不值得修复。

让我们来看看吧。

协议不匹配

该错误实际上在客户端和服务器端都有可能发生,而且根据情形的不同,事实上可能并不值得修复。当涉及到支持协议和密码时,最重要的一点是:永远向前看,决不回头。

TLS 1.2在十年前问世,但仍然有一小部分网站不支持它。今年夏天早些时候,IETF最终将TLS 1.3发布为RFC 8446。我们建议如果可以,各个网站应当尽早添加对TLS 1.3的支持。

另一方面,PCI DSS最近要求,所有收集支付卡信息的网站都必须结束对SSL 3.0和TLS 1.0的支持。此外,四大浏览器制造商——谷歌、Firefox、苹果和微软——共同宣布,将在2020年弃用TLS 1.1。

如果由于协议不匹配而导致SSL/TLS握手失败,这意味着客户端和服务器不能相互支持相同的TLS版本。这里有一个例子:

在这个场景中,并没有相互支持的TLS协议,而且服务器可能不支持向后版本控制。服务器不应该修复这个问题。在这个例子中,客户端应该升级其浏览器,或者维持浏览器不变,但需对它进行配置以支持最新的TLS版本。

此时,你应该在使用TLS 1.2或TLS 1.3,如果不是,请添加对它们的支持。但是记住,永远不要走回头路。

密码套件不匹配

这与协议不匹配非常相似——只是更精细一点。SSL/TLS并不能处理所有的事情(尽管ECC已经很接近了),它实际上是一组服务于不同功能的算法,这些算法协同工作共同组成了SSL/TLS。

SSL/TLS就像Megazord一样,而密码套件就像Power Rangers一样。

什么?你试图使一组算法听起来更有趣。

无论如何,尽管TLS 1.3所使用的密码套件已经得到了改进,但传统密码套件的算法可以处理:

  • 非对称公钥加密
  • 对称会话密钥加密
  • 密钥生成
  • 签名散列

不同的行业和政府机构拥有不同的加密标准,而这些加密标准又会建议使用不同的密码套件。一般来说,很有多重叠的地方,而且大多数网站都支持少量密码套件,因此客户端就拥有多个选择,并且通常都能找到一个双方都同意的密码。显然,如果网站只支持一个密码套件,那么协商成功的可能性就会大大降低。

如果你正在执行SSL桥接(边缘设备接收并解密HTTPS通信流,然后重新加密它,以便将其发送到应用程序服务器),那么在网络中通常都会发生这种情况。如果边缘设备和应用程序服务器不共享一个相互支持的密码套件,那么就会导致错误。

就像协议版本一样,在使用密码套件方面,你应该只向前看—而不是向后看。请记住,当一个协议版本或密码套件被弃用时,并不是因为行业试图让事情变得很困难,而是因为已经发现或即将发现漏洞。因此,向后看可能只会让你的连接不那么安全。

不正确的SSL/TLS证书

有许多因素可以使浏览器将SSL/TLS证书看作是不正确的,并阻止握手过程成功进行。我们将在下一小节中逐一介绍。同样值得注意的是,与SSL/TLS握手失败消息不同的是,有时这些问题会在客户端物化为一个不同的错误。一般来说,致使网站不能安全地进行连接的原因有多种。但从技术层面上来说,这个错误是握手失败造成的。

不正确的主机名

WWW和非WWW网站过去会出现这个问题,但是,由于证书机构允许免费将证书作为SAN列出,该问题已经普遍得到了解决。这个问题通常可以通过重新颁发证书来解决,有时也可以通过使用通配符证书来解决。

错误的证书链

几个月前,我们深入探讨了证书链、根和中间证书,但是可归纳如下。SSL/TLS和PKI中的信任模型通常依赖于精心策划的根程序,而这些根程序是一系列可信的、真实存在于计算机系统中的CA根证书的集合。

这些CA根如此宝贵,以至于证书颁发机构并不会冒险直接从这些根签发证书,而是会创建中间根,并使用这些中间根来签发SSL/TLS终端实体证书。这儿就要提到链了。根CA证书用于对中间根进行数字签名,而这些中间体则用于对其他中间体或SSL/TLS终端实体证书进行签名。

当浏览器接收到SSL/TLS证书时,为了验证它的真实性,它所做的一件事就是跟踪签名。它会查看SSL/TLS证书上的数字签名,并跟踪它返回到对它进行了签名的中间根。然后,它会查看该中间根的数字签名,并跟踪它返回到对该中间体进行了签名的证书。如此这样,直到最终到达其信任存储库中的一个根CA证书为止。

如果不能做到这一点,证书链通常是不完整的,这意味着浏览器无法定位其中一个中间体,SSL/TLS就会握手失败。要解决这个问题,你需要找到并安装丢失的中间证书。根据你所购买证书的供应商,证书的中间体应该可以在其网站上找到。

过期/撤销的证书

虽然当前SSL/TLS生态系统中的撤销流程还有很多不足之处,但是在某些情况中,浏览器仍然会看到证书已被撤销,并因此使得握手失败。更多的时候,这是证书过期的结果。

SSL/TLS证书过期有两个原因:

  • 为了确保验证信息准确
  • 为了确保更快速地更新协议和密码

现在,SSL/TLS证书最大的有效期为两年(27个月,因为CA允许你从以前的证书最多结转3个月)。最终,它可能短至6个月。这意味着你需要定期置换证书。如果你忘记了,这可能就是SSL/TLS握手失败的原因。只需获取一个有效的证书并安装它,就可以解决你的问题。

自签名替换

在公共互联网上,如果客户端没有在其根存储中手动安装你的私有根,那么自签名证书将100%返回错误。但是,在内部网络中,自签名证书相当常见。如果置换的次数足够多,就会产生问题。

大多数浏览器都会对证书进行缓存,因此在返回网站的时候,握手流程就会更快速,但是如果你定期生成新证书,从而不断地把这些新生成的证书添加到本地数据库,那么就会导致混乱局面的发生,最终浏览器就会因挣扎于路径构建而崩溃掉。

过去,Firefox一直在努力解决这个问题——重新签发7-8个证书将导致严重的延迟,如果证书的数量超过10个,握手时间就会超过30秒。

支持SNI的服务器

这更多的是一个存在于不同设备之间的内部问题,但有时,当客户端与SNI(服务器名称指示)服务器进行通信时,如果系统不支持SNI,SSL/TLS握手也会失败。

你需要做的第一件事是识别所涉及的服务器的主机名和端口号,并确保启用了SNI,以及它正在进行所需的通信。同样,这通常不是一个面向公众的问题,有时问题来自于内部。

不应当做的事——不要奖赏糟糕的SSL/TLS实现

很多时候,网站所有者都不想有所改变,直到问题无法再进行忽视。虽然在客户端可以修复部分SSL/TLS握手失败错误,但通常这一个过程都是在服务器端进行的。

这意味着作为一个普通的互联网用户,你的选择是有限的。最好的方法是将问题告知网站所有者,等待他们修复。如果他们没有修复,那么停止使用该网站可能是十分明智的。访问网站时,有一些事情你绝对不应当做:

  • 不要放弃你的防火墙,通常你可以为网站建立一个白名单,但永远都不要放弃你的防火墙。
  • 不要禁用你的防病毒软件,如果可能的话,也不要禁用白名单插件,但要保持时刻更新。
  • 不要通过HTTP进行连接或点击插页警告

如果网站不能提供安全的浏览体验,你就不应当访问它。

LEAVE A REPLY

Please enter your comment!
Please enter your name here