TLS/SSL 握手是一个相对复杂的过程，在阿里云环境中结合产品，安全等特性，可能会让 TLS/SSL 握手过程的不定性更多。本文来总结下各种握手失败的场景。

一次 TLS/SSL 握手的过程

本文不详细介绍 TLS/SSL 基础知识，相关介绍可以参考文章。下面 3 张图描述了 3 种 TLS/SSL 握手的全过程。

服务器验证的完全握手 (Full Handshake with Mutual Authentication)
这种是互联网大部分 HTTPS 流量使用的验证模式。证书在服务器上，客户端通过证书来验证服务器是否可靠。

双向验证的完全握手 (Full Handshake with Server Authentication)

这种是对客户端安全性有要求的验证模式。除了客户端要验证服务器外，服务器对客户端也需要进行验证，所以需要双向验证。和上面的步骤相比，多了客户端向服务器传输证书的过程。

简单握手 (Abbreviated Handshake)

完全握手需要 2 个 RTT 并交互很多消息，在会话复用的场景下，可以让握手简化到 1 个 RTT 完成。过程如下：

常规 TLS/SSL 握手失败

TLS/SSL 版本不匹配

自从 TLS 1.2 版本在 2008 年发布以来，绝大部分 HTTPS 流量都跑在 TLS 1.2 上。服务器处于安全性考虑通常也只支持较高版本 TLS，比如 TLS1.0 及以上。但是仍然有一些版本比较旧的操作系统和浏览器存在，如果这些客户端用低版本 TLS/SSL 向服务器发起握手，会因为服务器不支持而直接失败。

比如淘宝网只支持 TLS 1.0 及以上版本，用 openssl 发起 SSL 3 版本的握手，就会出现 handshake failure。

# openssl s_client -connect www.taobao.com:443 -ssl3 -msg
CONNECTED(00000003)
>>> ??? [length 0005]
    16 03 00 00 8f
>>> SSL 3.0 Handshake [length 008f], ClientHello
    01 00 00 8b 03 00 2a a0 d3 c5 10 b0 0a c0 0b ea
    fc e7 49 8f d1 66 cd 2a 51 c1 ab f4 ab b7 63 e1
    a7 3e e0 d7 14 9b 00 00 64 c0 14 c0 0a 00 39 00
    38 00 37 00 36 00 88 00 87 00 86 00 85 c0 0f c0
    05 00 35 00 84 c0 13 c0 09 00 33 00 32 00 31 00
    30 00 9a 00 99 00 98 00 97 00 45 00 44 00 43 00
    42 c0 0e c0 04 00 2f 00 96 00 41 c0 12 c0 08 00
    16 00 13 00 10 00 0d c0 0d c0 03 00 0a 00 07 c0
    11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00
<<< ??? [length 0005]
    15 03 00 00 02
<<< SSL 3.0 Alert [length 0002], fatal handshake_failure
    02 28
140191222585232:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40
140191222585232:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent

TLS/SSL cipher suite 不匹配

在握手的前两个 ClientHello 和 ServerHello 包中有一个重要的任务就是协商 cipher。客户端在 ClientHello 中会带上所有支持的 cipher suite, 服务器在收到 ClientHello 中的 cipher suite 后，会和自己支持的 cipher suite 一一匹配，如果没有可以匹配的就会握手失败。

服务器出于安全性考虑通常只会支持安全性较高的 cipher，所以当客户端发过去的 cipher suite 安全性都比较低时会造成握手失败。

例如用 openssl 向淘宝网发起握手，客户端的 ClientHello 中只有一个安全性较低的 DHE-RSA-AES128-SHA256 cipher，会出现 handshake failure。

# openssl s_client -connect www.taobao.com:443 -cipher DHE-RSA-AES128-SHA256 -msg
CONNECTED(00000003)
>>> TLS 1.2  [length 0005]
    16 03 01 00 5e
>>> TLS 1.2 Handshake [length 005e], ClientHello
    01 00 00 5a 03 03 4a d3 f5 53 f0 f3 e2 8f a8 a3
    4a 26 81 91 84 fb fd cf 80 13 21 c6 42 d3 c4 2b
    a7 70 de 4c e0 48 00 00 04 00 67 00 ff 01 00 00
    2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
    03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
    02 03 03 02 01 02 02 02 03 00 0f 00 01 01
<<< TLS 1.2  [length 0005]
    15 03 03 00 02
<<< TLS 1.2 Alert [length 0002], fatal handshake_failure
    02 28
139737777813392:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent

TLS/SSL 握手 Warning

在握手过程中，客户端对服务器证书会做验证，验证不过时会出现 Warning。浏览器可以选择忽略，用 curl 也可以使用 - k 参数来忽略。严格来说并不算 Failure，这里归类成 Warning，不做详细讨论。例如如下几种比较常见的情况：

• 访问的域名不在服务器证书的 CN(Common Name)和 SAN(Subject Alternative Name)中。
• 服务器证书被吊销，导致验证不通过。
• 由于本地系统时间不准，导致验证证书有效期时出现误判。

云盾导致 TLS/SSL 握手失败

进入阿里云的流量会经过云盾，类似于其他安全设备，云盾会根据流量特征采取一定动作。

现象

如下是一个例子。客户端访问阿里云的一个公网 IP 地址 TLS/SSL 握手失败。先来看下现象，在客户端的抓包如下：

可以看到前面的 TCP 三次握手和一些数据交互 (特定协议相关，正常情况在 TCP 三次握手后直接开始 TLS/SSL 握手) 都没有问题。但是开始 TLS/SSL 握手交互过程客户端发出第一个报文，马上收到一个 TCP RESET。这个和上面提到的常规握手失败很不一样，TCP RESET 报文通常是设备或者主机协议栈主动发出，符合一定场景或者有一定网络管理含义。

根本原因

云盾根据访问的目的域名有没有备案做执行相关动作。云盾并没有在 TCP 建连时就针对源目 IP 做阻断，而是提取 ClientHello 中的 SNI(Servername Indication)域名信息判断是否备案而做阻断，返回 TCP RESET。

SNI 是 ClientHello 中的一个扩展字段，带有要访问的目标域名，让同一个 IP 上托管多个 HTTPS 站点的服务器知道客户端访问的是哪个目标域名，以便使用对应的证书进行交互。在 ClientHello 报文的如下位置：

客户端证书问题导致 TLS/SSL 握手失败

在双向验证的场景中，不仅仅客户端要验证服务器证书，服务器也需要验证客户端证书。在服务器验证客户端证书的过程中，由于客户端证书的安全性较低，可能会直接产生 Fatal Alert，导致握手直接中断。

现象

如下是一个手机 App 访问服务器的例子。72 号报文报出了 Bad Certificate 的 Fatal Alert，从上下文看，这里是客户端向服务器端发送完 Certificate, Client Key Exchange 等消息后，服务器返回给客户端的报错。

在手机 App 中的报错如下：

SSL handshake aborted: ssl=0x7c1bbf6e88: Failure in SSL library, usually a protocol error
error:10000412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE (external/boringssl/src/ssl/tls_record.cc:592 0x7c6c627e48:0x00000001)

根本原因

在双向认证时，openssl 认为客户端证书的安全性过低，中断 TLS/SSL 握手。

无法提取 SNI 导致 TLS/SSL 握手失败

在某些场景中，需要获取 ClientHello 中的 SNI 字段来作为一个必要条件, 比如用 NGINX stream 对 HTTPS 流量做 4 层代理时。客户端 ClientHello 中没有携带 SNI，则会造成一个通过代理握手失败的局面。

现象

和上面个握手失败的现象如出一辙，在客户端发出 ClientHello 后，马上被代理服务器 FIN 掉，唯一不同的是这里的 ClientHello 并没有带上 SNI 字段。

根本原因

在利用 NGINX stream 做正向代理时，NGXIN 服务器需要获取客户端想要访问的目的域名。利用 ngx_stream_ssl_preread_module 模块在不解密的情况下拿到 ClientHello 报文中 SNI 才能实现代理的正常功能。详情参考文章。

总结

上面总结了很多握手失败的场景，一个有趣的现象是：失败的原因可能各不相同，但是抓包的结果大部分都比较一致，即客户端发的一个 TLS/SSL 握手包被服务器 FIN/RST 掉。对于这类问题的排查和分析，抓包分析仅仅只是一个线索，更加关键的是需要理解 TLS/SSL 握手整个过程中的细节以及当前场景中的网络链路，比如链路中有没有安全设备，代理，有没有使用双向验证，Keyless 等等。

---

本文作者：怀知

阅读原文

本文为云栖社区原创内容，未经允许不得转载。