行业新闻与博客
如何修复 SSL / TLS 握手失败错误
针对 Internet 用户和网站所有者的 SSL / TLS 握手失败错误修复程序
现在该发表另一篇技术文章了。今天,我们将讨论 SSL / TLS 握手失败错误及其修复方法。像许多 SSL 错误消息一样,SSL 握手错误可以从客户端和服务器端触发,因此有时可以由常规的互联网用户修复,而有时它表示网站方面的配置问题。
无论其起源如何,这都可能是令人沮丧的 SSL 错误,因为它会阻止您与尝试访问的网站建立安全连接。这对用户和网站所有者都是不利的-对网站所有者而言,因为它可以驱散业务(可能直接进入竞争对手的怀抱)。
我们将研究什么是 SSL / TLS 握手,然后我们将介绍 SSL / TLS 握手失败错误的原因以及可以解决的方法。
让我们将其散列出来。
下载: 证书管理清单 Essential 14 Point Free PDF。
什么是 SSL / TLS 握手?
在每个 HTTPS 连接开始时,客户端(互联网用户的 Web 浏览器)和服务器(托管网站)都必须进行一系列检查-缺乏更好的条件-以便彼此进行身份验证并确定参数。加密的连接。这被称为 TLS 握手,尽管业内某些人仍将其称为 SSL 握手。
(由于 SSL 是已弃用的协议,因此从技术上讲不再是准确的。但是,由于人们仍在使用该术语,因此我们在整篇文章中仍将其称为 SSL。因此,您会看到“ SSL 握手”和“ TLS 握手”在整个内容中可以互换使用,但只知道我们仍在讨论 TLS 握手。)
TLS 握手过程完成了三件事:
- 将服务器认证为非对称公钥 / 私钥对的合法所有者。
- 确定将用于连接的 TLS 版本和密码套件。
- 交换将用于通信的对称会话密钥。
如果简化公钥基础结构(PKI)(它是整个 SSL / TLS 生态系统的基础结构),那么实际上就是安全密钥交换。在 HTTPS 连接期间,实际上是使用对称会话密钥(通常是 256 位高级加密标准(AES)密钥)完成通信,该会话密钥是在事物的客户端生成的。生成对称密钥时,双方都会得到一份副本。他们可以使用它来加密和解密在它们之间传输的数据。
尽管 256 位加密仍然足够可靠,但真正的安全性却在门口,更大,更强的私钥(通常为 2048 位 RSA 密钥)有助于处理连接的身份验证部分。身份验证很重要,因为客户端希望确保它与正确的参与者连接。从本质上讲,这就是 SSL / TLS 握手的目的-这是一组检查,其中:
- 客户端和服务器相互认证,
- 他们确定 HTTPS 连接的参数(将使用哪种密码套件),然后
- 客户端加密会话密钥的副本,并将其发送到服务器以在连接期间使用。
从历史上看,SSL / TLS 握手给连接增加了一点延迟,这就是 HTTPS 减慢您网站速度的说法。不过,该延迟已在 TLS 协议的最新版本中得到解决,因此今天几乎完全不正确-尤其是对于 HTTP / 2 和 HTTP / 3。
当前,正在使用两种不同版本的 TLS 握手:TLS 1.2 和 TLS 1.3。
TLS 1.2 和 TLS 1.3 中的 SSL / TLS 握手过程
TLS 1.2 使用一次握手,可以在客户端和服务器之间进行多次往返。
想知道 TLS 握手过程如何工作?我们不会逐步进行,但实际上是:
- 客户端和服务器相互 ping 通。
- 服务器出示其 SSL / TLS 证书。
- 客户端验证证书颁发机构(CA)签名的证书。
- 他们交换一列受支持的密码套件并达成协议,然后进行密钥交换。
此过程涉及很多步骤-所有这些步骤都在很短的时间内发生。
另一方面,TLS 1.3 已将 TLS 握手改进为单个往返。
显然,这减少了连接启动所花费的时间-我们在这里说的是毫秒,因此可能并不明显(除非是大规模的)-并使所有工作效率更高。TLS 1.3 还允许恢复 0-RTT,从而进一步简化了与启用 TLS 1.3 的网站的后续连接。
但是,考虑到 TLS 握手中的活动部件数量,如果网站或设备配置错误,可能会出错。几年前,我们写过关于在 Firefox 上修复 TLS 握手失败错误的文章,但这些错误的普遍性远不止这些。因此,现在让我们谈谈 TLS 握手可能出什么问题以及需要解决的问题。
仔细研究 SSL / TLS 握手
在一切加密中 作者:Patrick Nohe
通过 HTTPS 连接到网站时,引擎盖下发生了很多事情。首先,每个人都需要……握手?!
阅读更多
SSL / TLS 握手失败错误概述
为了使本文更容易理解,我们将介绍 SSL / TLS 握手失败错误(SSL 握手错误)的所有可能原因以及谁可以修复它们。之后,我们将为每个部分提供专门的部分,其中将介绍如何修复它们。
原因 | TLS 握手错误的描述 | 固定 |
系统时间不正确 | 客户端设备的时间和日期不正确。 | 客户 |
浏览器错误 | 浏览器配置导致错误。 | 客户 |
中间人 | 第三方正在拦截 / 操纵连接。 | 客户 |
协议不匹配 | 服务器不支持客户端使用的协议。 | 服务器 |
密码套件不匹配 | 服务器不支持客户端使用的密码套件。 | 服务器 |
证书不正确 |
| 服务器 |
启用 SNI 的服务器 | 客户端无法与启用 SNI 的服务器通信。 | 服务器 |
现在,让我们来解决这些 SSL 握手失败错误。然后,我们将完成一些您绝对不应从客户端执行的操作来尝试纠正此错误。
SSL / TLS 握手失败-客户端错误
当握手失败时,通常是网站 / 服务器及其 SSL / TLS 配置的问题。这会导致讨厌的 SSL / TLS 握手错误。
实际上,这只是 TLS 配置,因为几乎完全不支持 SSL 3.0。(据 SSL Labs 报告,截至 2020年8月,只有 4.6%的站点仍支持 SSL 3.0。协议。)
但是,在某些情况下,客户端错误会导致 SSL / TLS 握手失败错误。而且其中许多看起来似乎都很琐碎-诸如确保系统时间正确且浏览器为最新之类的事情。
但是,正如我们所讨论的那样,TLS 握手有很多可移动的部分,有时即使是很小的打 ic 也会导致整个问题。
因此,让我们讨论一下此问题的一些客户端修补程序。
系统时间不正确
我真的不确定为什么有人会从通用时间选项中删除系统时钟,但显然是这样。也许您想像某种精神病患者一样遵守自己的个人时钟,或者设置只是被意外更改了,这实际上与我无关,但如果您的系统时间不正确,则可能导致 TLS 握手问题。结果,这可能导致 SSL / TLS 握手失败错误。
这主要是由于 SSL / TLS 证书的使用寿命有限,因此时间很重要。实际上,在某些知名度很高的证书过期情况下(例如 Oculus Rift VR 系统),互联网用户甚至故意将其系统时间设置为上述过期之前的日期,以便他们仍然可以连接。(最近的著名证书过期示例影响了从 COVID-19 报告到流音乐服务的所有方面。)
显然,不要更改系统时间。如果您仍然遇到 SSL / TLS 握手失败错误,并且系统时间正确,则问题出在其他地方。
浏览器错误
这并不像浏览器错误-实际上是您的浏览器犯了一个错误。有时,您的浏览器可能配置错误,或者插件可能导致工作方式略有不同,从而导致连接至其他合法网站的问题。虽然确切诊断需要在当前浏览器上进行调整的操作可能会有些困难,但是将问题缩小到特定的浏览器错误非常简单:只需尝试使用另一个浏览器,然后看看会发生什么。
如果您使用的是 Google Chrome 浏览器,请切换到操作系统的本机浏览器,例如 Apple Safari 或 Microsoft Edge。否则,请使用 Mozilla Firefox(我的偏爱)(如果有)。
基本上,只需将其切换并尝试连接到该站点即可。如果收到相同的 SSL / TLS 握手失败错误,则说明不是由浏览器引起的问题。但是,如果可以连接,现在您知道插件或设置有问题。
解决此 SSL / TLS 握手错误的最快方法是将浏览器重置为默认设置并禁用所有插件。在这里,您可以根据需要配置浏览器,并在进行调整时测试与该站点的连接。这可能会花费一些时间,但是,这实际上是解决您的浏览器配置错误或出现错误的唯一方法。
中间人
中间人(MITM)通常表示为试图窃取信息或造成伤害的邪恶的黑客。实际上并非总是如此。许多程序和设备会拦截流量以进行检查或其他非恶意目的(例如负载平衡),然后将其发送到应用程序服务器。从技术上讲,此过程也构成了一个 MITM。
不幸的是,有时这些设备的问题可能导致 TLS 握手失败。它可能类似于阻止连接的网络防火墙,也可能是服务器端网络上边缘设备上的配置。因此,根据情况,此问题实际上可以是客户端修复或服务器端修复。
事情是这样的:如果此问题是客户端问题,则在使用防病毒或 VPN 上的设置时可能会暴露自己的风险。通常应该有一种方法可以将有问题的网站列入白名单或创建例外。但是,永远不要丢弃防火墙或杀毒软件,只需连接到网站即可。如果问题是在服务器端,则很可能是边缘设备上的配置问题。
最近,罗斯·托马斯(Ross Thomas)告诉我他曾经处理过的一种设备,该设备拦截了流量并附加了一个小的数据字符串以表明它已通过检查。这导致数据无法通过校验和散列,并且还可能使身份验证混乱。
同样,对于我来说,有太多可能的来源将其缩小到一个单一的解决方法,但是如果您有检查或拦截流量的设备,请从这里开始。
SSL / TLS 握手失败:服务器端错误
大多数情况下,SSL / TLS 握手失败是服务器端问题的结果。其中有些易于修复,有些涉及更多,有些可能根本不值得修复。
让我们来看看。
协议不匹配
这实际上是在客户端和服务器端都可能发生的错误,并且根据上下文的不同,实际上可能是不值得修复的错误。在支持协议和密码方面,最重要的智慧是:始终前进,永不退步。
TLS 1.2 诞生于十多年前,但仍有一小部分网站不支持它。IETF 于 2018年最终将 TLS 1.3 发布为 RFC 8446。截至 2020年8月,Qualys SSL Labs 报告称,Alexa 前 15 万个站点中有 98.4%支持 TLS 1.2,而 32.8%则支持 TLS 1.3。
从另一方面讲,PCI DSS 要求所有收集支付卡信息的网站都必须终止对 SSL 3.0 和 TLS 1.0 的支持。谷歌,Firefox,苹果和微软这四大浏览器制造商联合宣布,TLS 1.1 将于 2020年弃用。
如果由于协议不匹配而导致 SSL / TLS 握手失败错误,则意味着客户端和服务器对相同的 TLS 版本没有相互支持。这是一个例子:
客户 | 服务器 |
支持 TLS 1.0,TLS 1.1 | 支持 TLS 1.2 |
在这种情况下,没有相互支持的 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 握手失败消息不同的错误。通常,网站上的某些内容无法提供安全的连接。但是在技术层面上,由于握手失败而导致发生错误。
问题 | 描述 |
主机名不匹配 | 证书中的 CN 与主机名不匹配。 |
证书链不正确 | 证书链缺少中间体。 |
证书已过期 / 已撤销 | 服务器提供了已过期,已吊销或不受信任的证书。 |
自签名替换 | (内部网络)证书替换路径混乱。 |
主机名不正确
这曾经是 WWW 和非 WWW 版本的网站的问题。但是,证书颁发机构社区已大大缓解了此问题,允许其免费列为 SAN(主题备用名称)域。通常可以通过重新颁发证书或有时使用通配符证书来解决此问题。
证书链不正确
在上一篇文章中,我们对证书链,根和中间证书进行了深入研究,但这是快速版本。SSL / TLS 和 PKI 中的信任模型通常依赖于精心策划的根程序。这些是从字面上存在于计算机系统中的受信任 CA 根证书的集合。
根程序 | 使用者 |
Mozilla | Firefox 桌面版和移动版 |
谷歌 | 安卓操作系统 |
苹果 | iOS,macOS |
微软 | 视窗 |
这些 CA 根是无价的-如此之多,以至于证书颁发机构可以旋转中间根,并使用这些中间层对 SSL / TLS 叶子(最终用户)证书进行签名,而不是直接从它们发出风险。这是链开始出现的地方。根 CA 证书用于对中间根进行数字签名。这些中间物用于签署其他中间物或最终用户叶 SSL / TLS 证书。
当浏览器收到 SSL / TLS 证书时,检查其真实性的其中一项工作就是签名。它查看 SSL / TLS 证书上的数字签名,并将其返回到对其进行签名的中间根。然后,它查看该中介的数字签名,并将其返回给签署该中介的证书。依此类推,直到最终,它到达其信任库中的根 CA 证书之一。
如果无法做到这一点,则证书链通常是不完整的,这意味着浏览器无法找到其中一个中间体,并且 SSL / TLS 握手失败。为了解决这个问题,您将需要找到并安装缺少的中间证书。根据您从哪个 CA 购买证书,它们应该在其网站上提供其中间体。
过期 / 吊销的证书
尽管当前 SSL / TLS 生态系统中的证书吊销还有很多需要改进,但在某些情况下,浏览器仍会看到证书已被吊销,并且在此基础上的握手失败。通常,这是证书过期的结果。SSL / TLS 证书仅在一定时间内有效。
相关: 这是当您的 SSL / TLS 证书过期时发生的情况
SSL / TLS 证书到期的发生有几个潜在原因(取决于您询问的人):
- 确保验证信息保持准确。
- 迅速增加协议和密码更新。
- 为了消除需要的证书吊销列表(CRL) 。
- 为了防止网络罪犯破坏标准的加密算法(尽管如果没有量子计算,这实际上是不可能的)。
截至 2020年9月1日,SSL / TLS 证书的最大有效期现在为一年(精确到 398 天)。这意味着您需要定期换出证书。如果您在过期之前忘记了密码,那可能就是 SSL / TLS 握手失败的原因。只需获得签发的有效证书并安装它,即可解决您的问题。
自签名替换
在公共互联网上,如果客户端尚未在根存储中手动安装您的私有根,则自签名证书将在 100%的时间内返回错误。但是,在内部网络上,自签名证书相当普遍。如果将它们交换出去足够多,则可能会导致问题。
大多数浏览器都会缓存证书,以便在返回网站后可以更快地进行握手。但是,如果您要定期生成新证书,则将所有这些新生成的证书连续添加到本地数据库中会引起混乱。最终,浏览器将难以进行路径构建和崩溃。
过去,Firefox 一直在为此付出很大的努力-直到 7-8 证书重新颁发将导致大量延迟,而 10 或更多可能导致握手花费 30 秒钟以上。
启用 SNI 的服务器
这更多是设备之间存在的内部问题,但是有时客户端在未启用 SNI 的情况下与服务器名称指示服务器进行通信可能是 SSL / TLS 握手失败的原因。
您需要做的第一件事是确定所讨论服务器的主机名和端口号,并确保它已启用 SNI 并正在传达所需的一切。同样,这通常不是一个面向公众的问题,但可能是内部不时引起的。
不应该做的事-不奖励不良的 SSL / TLS 实施
很多时候,网站所有者直到出现无法忽略的问题时才希望进行更改。尽管 SSL / TLS 握手失败错误有一些客户端修复程序,但通常是服务器端问题。
这意味着,作为普通的互联网用户,在减轻 SSL / TLS 握手错误方面,您的选择是有限的。最好的办法是将问题告知站点所有者,然后等待他们解决。如果他们不这样做,明智的做法是停止使用该网站。
您绝对不能做某些事情来访问网站:
- 不要丢下防火墙。通常,您可以将网站列入白名单,但不要丢弃防火墙。曾经
- 不要禁用您的防病毒软件。再次,如果可能,将其列入白名单,但请继续将其列入名单并进行更新。
- 不要通过 HTTP 连接或点击插页式警告。从任何角度看,这都是不好的,并且可能导致很多问题。
如果该网站不能提供安全的浏览体验,则不应访问该网站。消除 SSL / TLS 握手错误并不影响安全性。
最近新闻
2024年11月12日
2024年11月12日
2024年11月12日
2024年11月12日
2024年10月28日
2024年10月28日
2024年10月28日
2024年10月28日
需要帮助吗?联系我们的支持团队 在线客服