TLS1.2 TLS1.3握手协议区别和问题排查
修复internet用户和站点所有者的SSL/TLS握手失败错误
现在是发表另一篇技术文章的时候了，今天我们将讨论SSL/TLS握手失败错误及其修复方法。与许多SSL错误消息一样，这可以从客户端和服务器端触发，因此有时可以由普通互联网用户修复，而其他时候则表明网站存在配置问题。
不管它的起源如何，这都可能是一个令人沮丧的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使用握手，在客户机和服务器之间进行多次往返。
我们不会一步一步地进行，但实际上，客户机和服务器相互ping，提供SSL/TLS证书，客户机对其进行身份验证，他们交换一个受支持的密码套件列表并就其中一个达成一致，然后进行密钥交换。
TLS 1.3将TLS握手改进为一次往返。
很明显，这减少了连接启动所需的时间——我们在这里讨论的是毫秒，所以可能不太明显——并使一切都更加高效。TLS 1.3还允许0-RTT恢复，这将进一步简化与启用TLS 1.3的网站的后续连接。
但是，考虑到TLS握手中移动部件的数量，如果网站或设备配置错误，可能会出现很多问题。现在我们来讨论一下TLS握手会出现什么问题，以及需要做些什么来修复它。
仔细看一下SSL/TLS握手
帕特里克·诺赫的所有加密技术
当你通过HTTPS连接到一个网站时，引擎盖下面发生了很多事情。首先，每个人都需要…握手？！
SSL/TLS握手失败错误概述
为了使本文更易于理解，我们将介绍SSL/TLS握手失败错误的所有可能原因以及谁可以修复这些错误，然后稍后我们将为每个问题提供一个专门的部分，我们将介绍如何修复它们。
| CAUSE | DESCRIPTION | FIX |
| Incorrect System Time | Client device has the incorrect time & date | Client |
| Browser Error | A browser configuration is causing the error | Client |
| Man-in-the-Middle | A third party is intercepting/manipulating connection | Client |
| Protocol Mismatch | Protocol used by client is not supported by server | Server |
| Cipher Suite Mismatch | Cipher Suite used by client is not supported by server | Server |
| Incorrect Certificate |
|
Server |
| SNI-Enabled Server | Client can’t communicate with SNI-enabled server | Server |
现在让我们深入讨论解决这些问题和可以做的事情，然后我们将完成一些您绝对不应该从客户端尝试解决这个错误的事情。
SSL/TLS握手失败-客户端错误
当握手失败时，通常是网站/服务器及其SSL/TLS配置的问题。
实际上，现在只是TLS配置，因为对SSL 3.0的支持几乎完全被否决了。
但是，在一些上下文中，客户端错误可能导致SSL/TLS握手失败错误。其中很多看起来都很简单，比如确保系统时间正确，浏览器更新。
但是，正如我们所讨论的，在TLS握手时有很多活动部件，有时甚至是最轻微的打嗝都会导致整个事情变得一团糟。
所以，让我们来看看一些客户端修复。
系统时间不正确
我真的不知道为什么有人会把他们的系统时钟从通用时间选项中去掉，但很显然这是真的。也许你想像精神病患者一样遵守自己的个人时钟，或者设置只是意外改变——这不关我的事，真的——但如果你的系统时间不对，可能会导致TLS握手出现问题。
这主要是因为SSL/TLS证书的寿命有限，所以时间很重要。事实上，在一些相当引人注目的证书过期案例中，比如Oculus Rift虚拟现实系统，互联网用户甚至故意将其系统时间设置回到期前的某个日期，以便他们仍然可以连接。
显然，不要这样做。如果您仍然收到SSL/TLS握手失败错误，并且您的系统时间正确，则该问题是由其他地方引起的。
浏览器错误
这不像是一个浏览器错误，这实际上是你的浏览器犯了一个错误。有时你的浏览器可能会配置错误，或者插件可能会导致工作方式有点不同，从而导致连接到其他合法网站的问题。虽然诊断当前浏览器上需要调整的内容可能有点困难，但将其缩小到文本浏览器错误是非常简单的：只需尝试另一个浏览器。
如果你使用的是Google Chrome，可以切换到苹果Safari或微软Edge等操作系统的原生浏览器，如果你有，也可以使用Mozilla Firefox（我的首选）。
只要把它打开，然后试着连接到站点。如果您得到相同的SSL/TLS握手失败错误，您知道它不是浏览器。但是如果你能连接，现在你知道你的插件或设置有问题了。
解决这个问题的最快方法就是将浏览器重置为默认设置并禁用所有插件。在那里，你可以根据自己的需要配置浏览器，在你调整的时候测试你与相关站点的连接。这可能需要一点时间，但如果您的浏览器配置错误或出错，这确实是解决问题的唯一方法。
中间人
中间人（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。谷歌、火狐、苹果和微软四大浏览器制造商联合宣布，到2020年，TLS 1.1将被弃用。
如果由于协议不匹配而导致SSL/TLS握手失败错误，则意味着客户端和服务器对同一TLS版本没有相互支持。下面是一个例子：
| CLIENT | SERVER |
| Supports TLS 1.0, TLS 1.1 | Supports TLS 1.2 |
在这个场景中，没有相互支持的TLS协议，服务器可能不支持向后版本控制。服务器不应该修复这个问题。在此示例中，客户端应升级其浏览器，或者在浏览器为当前版本的情况下，将其配置为支持最新的TLS版本。
此时，您应该使用TLS 1.2或tls1.3，如果没有，请添加对它们的支持。但请记住，永远不要倒退。
密码套件不匹配
这与协议不匹配非常相似——只是更精细一些。SSL/TLS不仅仅是一个处理所有事情的算法（尽管ECC很接近），它实际上是一个提供不同功能并与SSL/TLS协同工作的算法集合。
SSL/TLS就像Megazord，密码套件就像Power Rangers。
什么？你试图使一组算法听起来更有趣。
总之，虽然TLS 1.3使用的密码套件已经过改进，但传统的密码套件有处理以下问题的算法：
非对称公钥加密
对称会话密钥加密
密钥生成
签名哈希
不同的行业和政府机构有不同的加密标准，建议使用不同的密码套件。一般来说，这里有很多重叠，而且大多数网站都支持少数密码套件，这样客户机就有几个选项，并且通常能够找到一个双方都满意的密码。显然，如果一个站点只支持一个密码套件，那么成功协商的几率将大大降低。
如果执行SSL桥接（边缘设备接收和解密HTTPS通信量，然后对其进行重新加密，以便将其发送到应用程序服务器），则在网络中经常会发生这种情况。如果边缘设备和应用程序服务器不共享相互支持的密码套件，将导致错误。
与协议版本非常相似，您应该只使用密码套件，而不是向后移动。请记住，当一个协议版本或密码套件被弃用时，并不是因为这个行业正试图变得困难，而是因为已经发现或迫在眉睫的漏洞。所以，向后走只会降低你的连接的安全性。
SSL/TLS证书不正确
有很多不同的东西可以使浏览器将SSL/TLS证书视为不正确，并阻止握手成功完成。我们将在下一小节中逐一讨论。值得注意的是，有时这些问题会在客户端变成不同的错误，而不是SSL/TLS握手失败消息。一般来说，网站上没有提供安全连接的东西。但在技术层面上，错误是由于握手失败而产生的。
| ISSUE | DESCRIPTION |
| Host Name Mismatch | The CN in the certificate does not match the host name |
| Incorrect Certificate Chain | The certificate chain is missing intermediates |
| Expired/Revoked Certificate | The server presented an expired, revoked or untrusted certificate |
| Self-Signed Replacements | (Internal Networks) Certificate replacements confused path |
主机名不正确
这曾经是WWW和非WWW版本的网站的一个问题，但证书颁发机构社区通常会减少这一问题，允许将一个站点免费列为SAN。此问题通常可以通过重新颁发证书或有时使用通配符证书来解决。
证书链不正确
几个月前，我们深入研究了证书链、根证书和中间证书，但这里是快速版本。SSL/TLS和PKI中的信任模型通常依赖于精心管理的根程序，这些根程序是可信CA根证书的集合，它们实际上存在于计算机系统上。
| ROOT PROGRAM | USED BY |
| Mozilla | Firefox Desktop and Mobile |
| Android OS | |
| Apple | iOS, macOS |
| Microsoft | Windows |
这些CA根是非常宝贵的，以至于证书颁发机构没有直接从中发出风险，而是将中间根旋转起来，并与这些中间根签署SSL/TLS leaf（最终用户）证书。这就是锁链开始进入的地方。根CA证书用于对中间根进行数字签名，这些中间根用于对其他中间根或最终用户的leaf SSL/TLS证书进行签名。
当浏览器收到SSL/TLS证书时，它要做的检查其真实性的一件事就是跟踪签名。它查看SSL/TLS证书上的数字签名，然后返回到签名它的中间根。然后，它查看中间层的数字签名，并跟随它返回到签署中间层的证书。以此类推，直到最终到达其信任存储区中的一个根CA证书。
如果它做不到这一点，证书链通常是不完整的，这意味着浏览器找不到中间层之一，并且SSL/TLS握手失败。要解决这个问题，您需要找到并安装丢失的中间证书。根据您购买证书的CA，它应该在其网站上提供其中间产物。
过期/吊销的证书
虽然在当前的SSL/TLS生态系统中，撤销操作还有很多需要改进的地方，但在某些上下文中，浏览器将看到证书已被撤销，并且在此基础上握手失败。更常见的情况是由于证书过期。
RELATED: This is what happens when your SSL/TLS certificate expires
SSL/TLS证书过期有两个原因：
确保验证信息的准确性
以更快的速度扩展协议和密码更新
现在，SSL/TLS证书的最大有效期是两年（27个月，因为CAs将允许您从以前的证书中携带最多3个月）。最终，可能会缩短到六个月。这意味着您需要定期交换证书。如果忘记了，这可能就是SSL/TLS握手失败的原因。只要获得一个有效的证书，并安装它-这应该可以解决你的问题。
自签名替换
在公共internet上，如果客户端没有在其根存储中手动安装您的私有根，则自签名证书将100%返回错误。但是，在内部网络上，自签名证书相当常见。如果你把它们换得足够多，可能会导致问题。
大多数浏览器都会缓存证书，这样在返回网站时，握手速度会更快，但是如果您定期生成新证书，不断地将所有新生成的证书添加到本地数据库将导致混乱，最终浏览器将难以构建路径并崩溃。
在过去，Firefox一直在努力解决这个问题，以至于7-8个证书的重新颁发将导致显著的延迟，而10个或更多证书可能导致握手需要30秒以上。
启用SNI的服务器
这更多的是设备之间存在的内部问题，但有时在未启用SNI时与服务器名称指示服务器通信的客户端可能是SSL/TLS握手失败的原因。
首先要做的是确定所讨论的服务器的主机名和端口号，并确保它启用了SNI，并且它可以传递所需的所有信息。再说一次，这通常不是一个公众面临的问题，但它可能是不时的内部原因。
什么都不动-不要奖励糟糕的SSL/TLS实现
很多时候，网站所有者不想做任何改变，直到它产生了一个他们不能忽视的问题。虽然有一些针对SSL/TLS握手失败错误的客户端修复，但通常是服务器端的。
这意味着作为一个普通的互联网用户，你的选择是有限的。最好的办法是通知网站所有者问题并等待他们解决。如果他们不这样做，最好停止使用网站。有些事情你绝对不应该去访问网站：
不要放弃防火墙，你通常可以列出一个网站，但不要放弃防火墙。永远。
如果可能的话，不要再次禁用你的防病毒软件，但是要保持更新和开启。
不要通过HTTP连接或单击间隙警告
如果网站不能提供安全的浏览体验，你不应该访问它。