如何建立TLS连接？TLS握手失败可能这个原因！

淩亂°似流年 2024-03-22 20:07 69阅读 0赞

签前面三个案例里的HTTP都没加密，使排查工作省去不少麻烦，抓包文件里直接就看清应用层信息。

但现实越来越多站点做HTTPS加密，所以像前面的三讲那样Wireshark里直接看到应用层信息的 case 越来越少。

根据w3techs.com [调查数据][Link 1]，Internet 78%以上的站点默认HTTPS。要对Internet上的问题做应用层方面的分析，TLS是绕不开的坎。

我主要内网问题，不关心太多HTTPS？勉强算对，但随各大企业不断推进零信任（ [Zero Trust][]）安全策略，越来越多内网流量也终将运行在HTTPS，内网和公网将无差。

所以，掌握HTTPS/TLS的相关知识和排查技巧对网络排查必备。

### 1 啥是HTTPS？ ###

首先我们要认识一下HTTPS。它其实不是某个独立的协议，而是HTTP over TLS，也就是把HTTP消息用TLS进行加密传输。两者相互协同又各自独立，依然遵循了网络分层模型的思想：

![043dc721d9bc49e1bca09002defefd11.png][]

加密技术是HTTPS的核心。

#### 加密技术基础 ####

加密技术其实也是一个古老的话题。早在公元前400年，斯巴达人就创造了密码棒加密法：纸条缠绕在一根木棒上，然后在纸上写字，这张纸条离开这根木棒后，就无法正确读取了。要“破解”它，就得找到同样粗细的木棒，然后把纸条绕上去后，才能解读。

纸条相当于密文，木棒相当于密钥。因为加密和解密用的木棒是相同的，所以它属于对称加密算法。

### 2 TLS基础 ###

TLS同时使用对称算法、非对称算法。

TLS整个过程分为：

*  握手阶段，完成验证，协商出密码套件，进而生成对称密钥，用于后续的加密通信
 *  加密通信阶段，数据由对称加密算法来加解密

TLS综合利用对称算法、非对称算法的优点：

*  对称算法效率高
 *  非对称算法安全性高

二者结合兼顾效率和安全性！

TLS问题排查也就面临两类问题：

*  TLS握手阶段
    
    真正加密还没开始，所以依托明文形式的握手信息，还可能找到握手失败原因。该阶段要掌握TLS握手原理和技术细节，才能指导展开排查工作
 *  TLS通信过程
    
    加密已开始，所有数据已是密文。假如应用层发生啥，而我们又看不到，如何排查？要 **把密文解密**，才能找到根因。

> “TLS要是能随便解密，是不是说明这协议还有漏洞？”TLS很安全的。这里说的解密肯定有前提条件，和数据安全性不冲突。

案例学习TLS握手失败的问题排查思路。

### 3 案例：TLS握手失败 ###

#### 3.1 问题原因 ####

如域名不匹配、证书过期等。这些问题一般都可通过“忽略验证”这简单操作来跳过。如在浏览器的警告弹窗里点击“忽略”，就能让整个TLS过程继续。

还有一些问题无法跳过。

有个应用要访问k8s集群的API server。因为我们有很多集群，相应API server也有很多。从同一台客户端：

*  访问API server 1可以
 *  但访问API server 2不行

发现失败原因就是TLS握手失败：

![04e0a41d32f54eb69e4c20c87c4ad7b3.png][]

在客户端的应用日志里的错误：

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

只说握手失败了。网络排查两大鸿沟之一的 **应用现象跟网络现象之间的鸿沟**：看得懂应用层日志，但不知道网络到底发生啥。

这里日志也无法告诉我们：到底TLS握手哪里问题。所以要做点别的事。

#### 3.2 排除服务端问题 ####

先用趁手小工具 **curl**，从这台客户端发起对API server 2（握手失败的）的TLS握手，发现能成功。这说明，API server 2至少某些条件下正常工作。

当时输出：

curl -vk https://api.server.777.abcd.io
    * Rebuilt URL to: https://api.server.777.abcd.io/
    * Trying 10.100.20.200...
    * Connected to api.server.777.abcd.io (10.100.20.200) port 443 (#0)
    * found 153 certificates in /etc/ssl/certs/ca-certificates.crt
    * found 617 certificates in /etc/ssl/certs
    * ALPN, offering http/1.1
    * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
    * server certificate verification SKIPPED
    * server certificate status verification SKIPPED
    * common name: server (does not match 'api.server.777.abcd.io')
    * server certificate expiration date OK
    * server certificate activation date OK
    * certificate public key: RSA
    * certificate version: #3
    * subject: CN=server
    * start date: Thu, 24 Sep 2020 21:42:00 GMT
    * expire date: Tue, 23 Sep 2025 21:42:00 GMT
    * issuer: C=US,ST=San Francisco,L=CA,O=My Company Name,OU=Org Unit 2,CN=kubernetes-certs
    * compression: NULL

> 第8行即协商出的密码套件 `* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256`。

既然curl能TLS握手成功，是不是客户端程序本身问题？开始“问题复现”。前一篇文章讨论偶发性问题的“复现+抓包”策略，而这问题必现，只要发起一次请求，做好抓包。

看抓包文件：

![c7a68d8b1b0f4d54bc43157f53dd75df.png][]

“话不投机半句多”，客户端就发个Client Hello报文，服务端就回复TLS Alert报文，结束这次对话。

为啥聊不起来？看Alert报文：

![f374fa319dca48f4a3fa8aa44d52f21d.png][]

编号40，指代Handshake Failure错误类型。要了解这错误类型的具体定义。

##### 正确做法 #####

去RFC寻找答案\*，而不是随意去网络搜索，因为可能被一些信息误导。

因为这次握手用TLS1.2协议，看 [RFC5246][]。在这个RFC里，找到Alert Protocol：

handshake_failure
          Reception of a handshake_failure alert message indicates that the
          sender was unable to negotiate an acceptable set of security
          parameters given the options available.  This is a fatal error.

结合实际场景，段意：“基于已收到的Client Hello报文中的选项，TLS服务端无法协商出一个可接受的安全参数集”。安全参数集在这指加密算法套件 **Cipher Suite**。

#### 3.3 Cipher Suite ####

TLS中真正的数据传输用的加密方式是 **对称加密**；对称密钥的交换使用 **非对称加密**。

TLS握手阶段要在下面四环里实现不同类型的安全性，TLS“四大护法”：

*  **密钥交换算法**：保证对称密钥的交换是安全，典型算法DHE、ECDHE
 *  **身份验证和签名算法**：确认服务端的身份，即对证书验证，非对称算法就用在这。典型算法RSA、ECDSA

> 补充：如双向验证（mTLS），服务端会验证客户端的证书。

*  **对称加密算法**：对应用层数据加密，典型算法AES、DES
 *  **消息完整性校验算法**：确保消息不被篡改，典型算法SHA1、SHA256

每个类型都有不同具体算法实现，它们的组合就是Cipher Suite。

#### 典型的密码套件 ####

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA（0xc013）

*  TLSTLS协议
 *  ECDHE，密钥交换算法，双方通过它就不用直接传输对称密钥，只需通过交换双方生成的随机数等信息，就可以各自计算出对称密钥
 *  RSA，身份验证和签名算法，主要是客户端来验证服务端证书的有效性，确保服务端是本尊
 *  AES128\_CBC，对称加密算法，应用层的数据就用它加解密。CBC块式加密模式，另外一类模式是流式加密
 *  SHA，最后的完整性校验算法（哈希算法），保证密文不被篡改
 *  0xc013，密码套件的编号，每种密码套件都有独立编号。完整编号列表 [IANA的网站][IANA]

不同的客户端和服务端软件上，这些密码套件也各不同。TLS握手的重要任务之一就是 **找到双方共同支持的那个密码套件**，即“共同语言”，否则握手就必定会失败。

这案例排查下一步，就是搞清

#### 客户端和服务端到底支持哪些Cipher Suite ####

客户端的密码套件有哪些？前面curl输出显示双方协商出来的是

ECDHE_RSA_AES_128_GCM_SHA256

但：

*  这是协商后达成的结果，只是个套件，不是套件列表
 *  这密码套件是curl这客户端的，不是出问题的客户端

出问题的客户端：实际的业务代码去连接API server时的客户端，它是个Java库，而非curl。

![64fdcfca8a8d4568a7ee51d192a16d7a.png][]

咋获得这Java库能支持的密码套件列表？最直接的， **抓包分析**。回到前面那抓包文件，检查Client Hello报文。在那就有Java库支持的密码套件列表：

![c34eb18f09e84b6db057427fe79b9504.png][]

找到客户端的密码套件列表了。

接下来，是不是找服务端的密码套件列表？不过，这抓包里，服务端直接回复了Alert消息，并未提供它支持的密码套件列表。排查如何推进？

#### 换个思路 ####

看服务端在TLS握手成功后用了哪个密码套件，而不是拿到它的全部列表。前面curl成功， 看curl那次协商出来的套件，看它是否被Java库支持，就能判定了。

我们要导出这次Client Hello里面的密码套件列表，可以这样做：选中Cipher Suite，右单击，选中Copy，在次级菜单中选中All Visible Selected Tree Items：

![1a1e86aa79774d51a826c8a3b824cd39.png][]

得到列表：

Cipher Suites (28 suites)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
        Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
        Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
        Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (0xc029)
        Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
        Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
        Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
        Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
        Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
        Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
        Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
        Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
        Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
        Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
        Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
        Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
        Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
        Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
        Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
        Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
        Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
        Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
        Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
        Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

确实没 **ECDHE\_RSA\_AES\_128\_GCM\_SHA256** 套件。至此，能确认问题根因：因为这Java库和API server 2之间没找到共同密码套件，所以TLS握手失败。

根因找到，下步就是升级Java库，让双方能协商成功。

> API server 1能兼容这相对旧的Java库，所以没问题。

这问题难吗？还好，对吧？因为我们一旦对协议本身有准确理解，很多问题就易被“看穿”。扎实的理论知识很重要。

### 4 案例：有效期内的证书为啥报告无效？ ###

产品开发团队向运维团队报告问题：他们的应用在代码发布后，就无法正常访问一个内部HTTPS站点，报错：certificate has expired。

我们日常对证书都做自动更新处理，不该有“漏网之鱼”塞。然后手工检查这HTTPS站点证书，确定在有效期内，这报错真见鬼了！

既然是代码发布后新问题，认为和发布有关。这次确实有变更，会在客户端打开服务端证书校验的特性，而这特性在以前不打开。但这还无法解释，为啥客户端居然会认为，一个明明在有效期内的证书是过期。

![986e4b9bbbfe4402b5c92778bdfb7569.png][]

“秀才遇到兵”，感觉“讲理”行不通，换个思路，不纠结在有效期问题。

类似前一案例，交叉验证推进排查。在这台客户端和另一台客户端，用OpenSSL向这HTTPS站点发起TLS握手。

![866cb68effa4490c9da52f29400c0ddc.png][]

结果：从另外一台客户端的OpenSSL去连接这HTTPS站点，也报告certificate has expired。

既然OpenSSL可复现，就可进一步检查！因为OpenSSL属OS命令，虽然我们不了解如何在Node.js debug，但对如何在OS排查有经验。

OpenSSL命令前加 **strace**，以便追踪OpenSSL执行过程中，特别在报告certificate has expired前到底发生啥：

strace openssl s_client -tlsextdebug -showcerts -connect abc.ebay.com:443

输出关键：

stat("/usr/lib/ssl/certs/a1b2c3d4.1", {
        st_mode=S_IFREG|0644, st_size=2816, ...}) = 0
    openat(AT_FDCWD, "/usr/lib/ssl/certs/a1b2c3d4.1", O_RDONLY) = 6
    ......
    write(2, "verify return:1\n", 16verify return:1
    )       = 16
    .......
    write(2, "verify error:num=10:certificate "..., 44verify error:num=10:certificate has expired
    ) = 44
    write(2, "notAfter=", 9notAfter=)                = 9
    write(2, "Oct 14 18:45:33 2020 GMT", 24Oct 14 18:45:33 2020 GMT) = 24

*  OpenSSL读取 `/usr/lib/ssl/certs` 下的文件 `a1b2c3d4.1`
 *  接着，OpenSSL就报告certificate has expired，expire日期2020年10月24日

明显进展：很可能就是这文件导致错误。它就是TLS客户端本地的Trust store里，存放的中间证书文件。Trust store一般存放根证书和中间证书文件，

### 5 TLS证书校验原理 ###

一般，证书先存入文件系统，然后通过命令或代码，导入应用的Trust store。

#### 5.1 TLS证书链 ####

TLS证书验证是“链式”机制。如客户端存有根证书和它签发的中间证书，那由中间证书签发的叶子证书，就可被客户端信任了，也就是这样一条信任链：

信任根证书
         |
    信任中间证书
         |
    信任叶子证书

3种信任链：

![673c39972c1b46a1805ef1a92c1495d4.png][]

*  case1、3，信任链完整，证书验证就可通过
 *  case2，由于中间证书既不在客户端Trust store，也不在服务端回复的证书链，导致信任链断裂，验证失败

发现案例里，服务端发送的证书链包含正确的中间证书，为啥还失败？因为从前面strace openssl输出发现，客户端本地也有中间证书且 **过期的**：

![2e41a05955ce4accad7bd35f706319c7.png][]

这两张中间证书，签发机构是同一个CA，证书名称也相同，这就导致了OpenSSL在做信任链校验时，优先用了本地的中间证书，进而因为这张本地的中间证书确实已经过期，导致OpenSSL抛出了certificate has expired的错误！

你可能问：“照理说，叶子证书是新的中间证书签发的，用老的中间证书去验证叶子证书的签名的时候，应该会失败？”

没错，最烧脑的是：这两张中间证书，不仅签发机构一样，名称一样， **私钥也一样**！

若你对TLS不熟，到这可能有点“爆炸”。核心在于：每次证书在更新时， **它对应的私钥不是必须要更新的，可保持不变**。

我们把本地已过期的中间证书，称old\_cert，新的中间证书称new\_cert。整个故事：

*  几年前，old\_cert被根证书签发出来，名为inter-CA，保存在这台客户端的Trust store
 *  2020年，old\_cert到期，根证书机构重新签发一张新的中间证书new\_cert，它用新有效期，而 **证书名称inter-CA** 和对应 **私钥** 都不变
 *  CA用这张new\_cert签发这次的叶子证书。因为客户端程序没打开证书校验机制，所以没报错
 *  这天，新代码发布，证书校验机制被打开，于是客户端开始校验。发现这张叶子证书的签发者名称是inter-CA，而自己本地就有张也叫inter-CA的证书，于是尝试用这张证书的公钥去解开叶子证书的签名部分，可成功解开，于是确认old\_cert就是对应的中间证书（而没用收到的new\_cert，这是关键）。但由于old\_cert已过期，结果客户端抛certificate has expired

#### 5.2 TLS证书签名 ####

TLS证书都有签名部分，这签名就是用签发者的私钥加密的。客户端为啥相信叶子证书真的是这CA签发的？因为客户端的Trust store里就有这CA的公钥（在CA证书里），它用这公钥去尝试解开签名，能成功，就说明这张叶子证书确是这CA签发。

![3de78be3db3e4204aae91f1866ae2100.png][]

最关键部分在于，新老中间证书用的私钥是同一把，所以这张叶子证书的签名部分， **用老的中间证书的公钥也能解开**，使得下图中的橙色的验证链条“打通”，不过，谁也没料到打通一条“死胡同”。

> PKI里有交叉签名的技术，就是新老根证书对同一个新的中间证书进行签名，但并不适用于这个案例。

![73a7167b24c946b2b9da901d1ffd4256.png][]

OpenSSL报错原因找到了，根据这发现，也确认Node.js的Trust store也存在同样问题。把它的Trust store里过期证书全部删除，问题解决。[Stack Overflow也有类似问题][Stack Overflow]。

### 总结 ###

*  加密算法的类型

对称加密算法：加密和解密用同一个密钥，典型算法有AES、DES。

非对称加密算法：加密和解密用不同的密钥，典型的非对称加密算法有RSA、ECDSA。

*  TLS基础

TLS是先完成握手，然后进行加密通信。非对称算法用于交换随机数等信息，以便生成对称密钥；对称算法用于信息的加解密。

*  Cipher Suite

在握手阶段，TLS需要四类算法的参与，分别是：密钥交换算法、身份验证和签名算法、对称加密算法、消息完整性校验算法。这四类算法的组合，就形成了密码套件，英文叫Cipher Suite。这是TLS握手中的重要内容，我们的案例1就是因为无法协商出公用的密码套件，所以TLS握手失败了。

*  TLS证书链

TLS的信任是通过对证书链的验证：

**信任根证书 -> 信任中间证书 -> 信任叶子证书**

本地证书加上收到的证书，就形成了证书链，如果其中有问题，那么证书校验将会失败。我们的案例2，就是因为一些极端情况交织在一起，造成了信任链过期的问题，导致证书验证失败了。

*  **Trust store**

它是客户端使用的本地CA证书存储，其中的文件过期的话可能导致一些问题，在排查时可以重点关注。

*  **排查技巧**

在排查技巧方面，你要知道使用 **curl命令**，检查HTTPS交互过程的方法：

curl -vk https://站点名

用 **OpenSSL命令** 来检查证书：

openssl s_client -tlsextdebug -showcerts -connect 站点名:443

需要分析OpenSSL为什么报错时，可加 **strace**，对排查根因有帮助。

**如何在Wireshark里导出Cipher Suite的方法**，就是在TLS详情中选中Cipher Suite，右单击，选中Copy，在次级菜单中选中All Visible Selected Tree Items。这时，列表就被复制出来了。

排查TLS Alert 40这个信息时，查阅 [RFC5246][] 得到答案。遇到一些协议类型、定义相关的问题时， **最好查阅权威的RFC文档，获得最准确信息**。

### FAQ ###

TCP是三次握手，那么TLS握手是几次？

也是三次。TLS握手过程包括客户端发送ClientHello消息，服务器返回ServerHello消息和证书，客户端验证证书并发送加密所需的信息，服务器确认并发送加密所需的信息，最后客户端发送Finished消息，完成握手过程。其中前两步是服务器和客户端交换信息的第一次和第二次握手，后面的步骤是第三次握手。

假设服务端返回的证书链是根证书+中间证书+叶子证书，客户端没有这个根证书，但是有这个中间证书。你认为客户端会信任这个证书链吗？

如果客户端缺少根证书，那么客户端将无法验证证书链的完整性和真实性。在这种情况下，客户端将无法信任该证书链，即使客户端拥有中间证书。因此，为了建立可信的TLS连接，客户端必须拥有完整的证书链，包括根证书、中间证书和叶子证书。

[Link 1]: https://w3techs.com/technologies/details/ce-httpsdefault
[Zero Trust]: https://en.wikipedia.org/wiki/Zero_trust_security_model
[043dc721d9bc49e1bca09002defefd11.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e927127a87304d18ab25762979bc7696.png
[04e0a41d32f54eb69e4c20c87c4ad7b3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5daa491c6bd4446c922a8734a66c841f.png
[c7a68d8b1b0f4d54bc43157f53dd75df.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/41dc34fe1b9a4afeaca87220bc307bcf.png
[f374fa319dca48f4a3fa8aa44d52f21d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5800309f0c7e43e69a3453948936d251.png
[RFC5246]: https://datatracker.ietf.org/doc/html/rfc5246
[IANA]: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[64fdcfca8a8d4568a7ee51d192a16d7a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/44761e841e8d485bbc6abeeebf99ce58.png
[c34eb18f09e84b6db057427fe79b9504.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c8865414431a44a3bd7aa41950540b78.png
[1a1e86aa79774d51a826c8a3b824cd39.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5e53acf732094b329667acca43ad6653.png
[986e4b9bbbfe4402b5c92778bdfb7569.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/5be76a6d905940e89351425dce194267.png
[866cb68effa4490c9da52f29400c0ddc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/627b87ef06c34ebb8e979aa0ad92148f.png
[673c39972c1b46a1805ef1a92c1495d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/598a9a57937b44b3ba0ee9a8e7f2bdff.png
[2e41a05955ce4accad7bd35f706319c7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/80eb186c7daf4076a65eddd79ff051c2.png
[3de78be3db3e4204aae91f1866ae2100.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/6120c9c35eac4633b7c8db7cd41da2fb.png
[73a7167b24c946b2b9da901d1ffd4256.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/2daaf69d8b0a4e39b4966fd65f4aa6db.png
[Stack Overflow]: https://stackoverflow.com/questions/24992976/openssl-telling-certificate-has-expired-when-it-has-not/68151948#68151948