图解TLS握手连接

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

TLS是在SSL的基础上标准化的产物，目前SSL3.0与TLS1.0保持一致的，二者是并列关系，只是大家习惯称呼SSL。注明的web服务nginx默认支持的就是TLS1.0、TLS1.1、TLS1.2协议。

说明了SSL和TLS的区别后，我们通过wireshark对TLS的每一个byte进行分析。先来一张握手图：

对应的wireshake中的握手记录

1. Client Hello

会话从client说“hello”开始, client提供以下数据：

• 协议版本
• 客户端随机数(之后会在握手中使用到)
• 一个用来恢复的可选session id
• 密码套件列表
• 压缩方法列表
• 扩展列表

1.1 Record Header

16 03 01 02 00

16 - 表示ContentType指示SSL通信处于握手(handshake)阶段

03 01 - 表示TLS的版本是 TLS1.0

02 00 - 表示512字节的握手消息

1.2 Handshake Header

每个握手消息都以类型和长度开始。

01 00 01 fc

01 - 表示握手消息的类型为 client hello

00 01 fc - 表示握手消息的长度

1.3 客户端TLS版本

给出了协议版本“3,3”(即TLS 1.2)。不寻常的版本号(“3,3”表示TLS 1.2)是由于TLS 1.0是SSL 3.0协议的一个小修订。因此，TLS 1.0用“3,1”表示，TLS 1.1用“3,2”表示，依此类推。

03 03

可见上图

1.4 客户端随机数

74 ac 35 84 e3 0b d2 a4 63 75 1e a9 94 d2 43 94

6b bf 67 ab f9 a6 8e c7 0b e6 cb ab f0 91 bc db

客户端提供32字节的随机数据。在本例中，我们将随机数据设置为可预测的字符串。TLS 1.2规范说，前4个字节应该是当前时间.

在握手时，客户端和服务器都会提供随机数。这种随机性对每次握手都是独一无二的，在身份验证中骑着举足轻重的作用。它可以防止重放攻击，并确认初始数据交换的完整性。

1.5 会话ID

在第一次连接时，会话ID（Session ID）字段是空的，这表示客户端并不希望恢复某个已存在的会话。在后续的连接中，这个字段可以保持会话的唯一标识。服务器可以借助会话ID在自己的缓存中找到对应的会话状态。典型的会话ID包含32自己随机生成的数据，这些数据本身没有什么价值。

1.6 加密套件

客户端提供一个有序的列表，其中列出了它将支持的密钥交换、密钥加密和消息身份验证的加密方法。该列表是按优先级顺序排列的。

1.7 压缩方法

客户端可以提交一个或多个支持压缩的方法。默认的压缩是null，代表没有压缩。这种压缩将在加密之前应用(因为加密的数据通常是不可压缩的)。压缩具有削弱加密数据安全性的特征(参见CRIME)。因此，这个特性已经从未来的TLS协议中删除。

• 01 - 压缩方法的长度
• 00 - 使用的哪种压缩方法, 00代表未使用任何压缩方式

1.8 Extensions长度

Extensions是由任意数量的扩展组成。这些扩展会携带额外数据。

* 00 58 - the extensions will take 0x58 (88) bytes of data

每个扩展都以两个字节开始，表示它是哪个扩展，然后是一个双字节内容长度字段，然后是扩展的内容。

1.9 Extension - Server Name

客户端提供了它所联系的服务器的名称，也称为SNI(服务器名称指示)。

如果没有这个扩展，HTTPS服务器将无法为单个IP地址(虚拟主机)上的多个主机名提供服务，因为它无法知道要发送哪个主机名的证书，直到经过TLS会话协商并发出HTTP请求之后才知道.

* 00 00 - 这个值表示扩展名为‘Server Name’

* 00 13 - Extension Length

* 00 11 - Server Name list length

* 00 - list entry is type 0x00 "DNS hostname"

* 00 0e - Server Name Length

* 65 78 61 ... 6e 65 74 - 表示服务器名

1.10 Extension - Status Request

客户端为服务器提供在其响应中提供OCSP信息的权限。OCSP可用于检查证书是否已被撤销。客户端发送空扩展的这种形式是必要的，因为服务器使用客户端首先没有提供的扩展进行应答是一个致命错误。因此，客户端发送一个空形式的扩展，而服务器用填充了数据的扩展进行应答。

00 05 00 05 01 00 00 00 00

• 00 05 - 表示该extension为 "status request"
• 00 05 - 表示该扩展的长度
• 01 - 表示certificate status type: OCSP
• 00 00 - 表示Responder ID list length
• 00 00 - 表示Request Extensions Length

1.11 Extension - Supported Groups

客户端表示支持4条曲线的椭圆曲线加密。这个扩展最初被命名为“椭圆曲线”，但现在被重命名为“受支持的组”，以便与其他加密类型通用。

• 00 0a - assigned value for extension "supported groups"
• 00 0a - 0xA (10) bytes of "supported groups" extension data follows
• 00 08 - 0x8 (8) bytes of data are in the curves list
• 00 1d - assigned value for the curve "x25519"
• 00 17 - assigned value for the curve "secp256r1"
• 00 18 - assigned value for the curve "secp384r1"
• 00 19 - assigned value for the curve "secp521r1"

1.12 Extension - EC Point Formats

在椭圆曲线(EC)加密期间，客户机和服务器将以压缩或未压缩的形式交换所选点上的信息。这个扩展表明客户机只能解析来自服务器的未压缩信息。在下一版本的TLS中，不存在协商点的能力(而是为每个曲线预先选择了一个点)，因此不会发送此扩展。

• 00 0b - assigned value for extension "EC points format"
• 00 02 - 0x2 (2) bytes of "EC points format" extension data follows
• 01 - 0x1 (1) bytes of data are in the supported formats list
• 00 - assigned value for uncompressed form

1.13 Extension - Signature Algorithms

随着TLS的发展，有必要支持更强大的签名算法，如SHA-256，同时仍然支持使用MD5和SHA1的早期实现。此扩展指示客户机能够理解哪些签名算法，并可能影响服务器发送给客户机的证书的选择。

• 00 0d - assigned value for extension "Signature Algorithms"
• 00 12 - 0x12 (18) bytes of "Signature Algorithms" extension data follows
• 00 10 - 0x10 (16) bytes of data are in the following list of algorithms
• 04 01 - assigned value for RSA/PKCS1/SHA256
• 04 03 - assigned value for ECDSA/SECP256r1/SHA256
• 05 01 - assigned value for RSA/PKCS1/SHA386
• 05 03 - assigned value for ECDSA/SECP384r1/SHA384
• 06 01 - assigned value for RSA/PKCS1/SHA512
• 06 03 - assigned value for ECDSA/SECP521r1/SHA512
• 02 01 - assigned value for RSA/PKCS1/SHA1
• 02 03 - assigned value for ECDSA/SHA1

1.14 Extension - Renegotiation Info

该扩展的存在防止了使用TLS重新协商执行的攻击类型。重新协商连接的能力已经从该协议的下一个版本(TLS 1.3)中移除，因此将来不再需要这个扩展。

• ff 01 - assigned value for extension "Renegotiation Info"
• 00 01 - 0x1 (1) bytes of "Renegotiation Info" extension data follows
• 00 - 重新协商数据的长度为零，因为这是一个新连接

1.15 Extension - SCT

客户端为服务器提供返回签名证书时间戳的权限。客户端发送空扩展的这种形式是必要的，因为服务器使用客户端首先没有提供的扩展进行应答是一个致命错误。因此，客户端发送一个空形式的扩展，服务器使用填充了数据的扩展进行响应，或者根据发送扩展的客户端更改行为。

• 00 12 - assigned value for extension "signed certificate timestamp"
• 00 00 - 0x0 (0) bytes of "signed certificate timestamp" extension data follows

2. Server Hello

服务器回以“你好”。服务器提供以下信息:

• 选择的协议版本
• 服务器随机数据(稍后在握手中使用)
• 会话id
• 选定的密码套件
• 选择的压缩方法
• 扩展列表

2.1 Record Header

TLS会话被分解为“记录”的发送和接收，“记录”是具有类型、协议版本和长度的数据块。

• 16 -类型是0x16(握手记录)
• 03 03 -协议版本是“3,3”(TLS 1.2)
• 00 31 - 0x31(49)字节的握手消息

2.2 Handshake Header

每个握手消息都以类型和长度开始。

• 02 -握手消息类型0x02(服务器你好)
• 00 00 2d - 接下来是服务器hello数据的0x2D(45)字节

2.3 服务器TLS版本

给出了协议版本“3,3”(TLS 1.2)。不寻常的版本号(“3,3”表示TLS 1.2)是由于TLS 1.0是SSL 3.0协议的一个小修订。

03 03 - TLS Version = 1.2

2.4 服务器随机数

服务器提供32字节的随机数据。在本例中，我们将随机数据设置为可预测的字符串。

2.5 会话ID

服务器可以为这个会话提供一个ID，客户机可以在以后的会话协商中提供这个ID，以便重用关键数据并跳过大多数TLS协商过程。为了使其工作，服务器和客户端都将来自前一个连接的密钥信息存储在内存中。恢复连接可以节省大量的计算和网络往返时间，因此只要有可能就会执行连接。

• 00 - length of zero (没有选择任何会话ID)

2.6 服务器选择的加密方式

服务器从客户机提供的选项列表中选择了密码套件0xC02F (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)。

其中SHA256就是客户端和服务端使用的HMAC算法

2.7 服务器选择的压缩方式

服务器从客户机提供的选项列表中选择了压缩方法0x00(“Null”，它不执行压缩)。

2.8 Extension长度

服务器向客户端返回了一个扩展列表。由于禁止服务器使用客户机没有发送其hello消息的扩展进行应答，所以服务器知道客户机将支持列出的所有扩展。

• 00 05 -扩展将占用0x5(5)字节的数据

2.9 Extension - Renegotiation Info

该扩展的存在防止了使用TLS重新协商执行的攻击类型。重新协商连接的能力已经从该协议的下一个版本(TLS 1.3)中移除，因此将来不再需要这个扩展。

• ff 01 -为扩展分配值“重新协商信息”
• 00 01 - 0x1(1)字节的“重协商信息”
• 00 00 - 扩展数据如下重新协商数据的长度为零，因为这是一个新的连接

2.10 Extended Master Secret

无“Extended Master Secret”

master_secret = PRF(pre_master_secret, "主秘钥", ClientHello.random + ServerHello.random)[0..47]

具有“Extended Master Secret”

master_secret = PRF(pre_master_secret，“扩展的主密钥”，session_hash)[0..47];

session_hash = hash(handshake_message)

3. Server Certificate

服务器提供一个包含以下内容的证书:

• 服务器的主机名
• 此服务器使用的公钥
• 来自可信第三方的证据，证明此主机名的所有者持有此公钥的私钥

这里先介绍下证书认证的过程：

1). 服务器发送给浏览器端的证书只有public key, 服务器端保存着private key。

2). client随机生成一串数，用server这里的public key加密，发给server

3). server用private key解密后返回给client

4). client与原文比较，如果一致，则说明server拥有private key，也就说明与client通信的正是证书的拥有者，因为public key加密的数据，只有private key才能解密

3.1 Record Heade

TLS会话被分解为“记录”的发送和接收，“记录”是具有类型、协议版本和长度的数据块。

• 16 -类型是0x16(握手记录)
• 03 03 -协议版本是“3,3”(TLS 1.2)
• 03 2f - 0x31(49)字节的握手消息

3.2 Handshaker Heade

每个握手消息都以类型和长度开始。

• 02 -握手消息类型0x02(服务器你好)
• 00 00 2d - 接下来是服务器hello数据的0x2D(45)字节

3.3 Certificate Length

证书消息以随后的所有证书数据的长度开始。

* 00 03 28 - 0x328 (808) bytes of certificate list follows

3.4 Certificate

证书采用ASN.1 DER二进制编码。这种编码由以下序列中的记录组成:类型标记、长度、数据。

type标签包含以下信息:

type class (2 bits):通用的、应用程序的、特定于上下文的或私有的

constructed (1 bit):如果记录由更小的记录组成，则设置

type (5 bits):如果类型类是通用类型，那么类型表示整数、ASCII字符串、对象ID等。

https://tls.ulfheim.net/certificate.html

4. Server Key Exchange

服务器提供了密钥交换信息。作为密钥交换过程的一部分，客户端需要拥有一组公钥+私钥，公钥用于加密发送的数据, 私钥用于解密服务器发送过来的数据。并且将互相发送对方的公钥。然后，将使用各方的私钥和另一方的公钥的组合生成共享加密密钥。

双方同意使用ECDHE密码套件,这意味着密钥对将基于选择的椭圆曲线,diffie - hellman,密钥对都是暂时的(为每个连接生成),而不是使用的公钥/私钥证书。

4.1 Record Header && HandShaker Header

略

4.2 Curve info

服务器选择椭圆曲线, 椭圆曲线上的所有点。

• 03 - assigned value for "named_curve": 曲线类型
• 00 1d - curve 0x001d ("curve x25519")

4.3 Public Key

服务器端提供的公钥来自于之前的步骤 "Server Key Exchange Generation".

• 20 - length of 0x20 (32) bytes
• 9f d7 ... b6 15 - public key

4.4 Signature

因为服务器正在生成临时密钥，所以它没有使用服务器证书中提供的公钥。为了证明服务器拥有服务器证书(在TLS会话中提供证书有效性)，它使用证书的私钥签署临时公钥。可以使用证书的公钥验证此签名。

• 04 01 - reserved value for RSA signature with SHA256 hash
• 01 00 - length of signature (0x100 or 256 bytes)
• 04 02 b6 ... ac 41 fb - the computed signature for SHA256(client_hello_random + server_hello_random + curve_info + public_key)

我们可以自己计算签名使用服务器的私钥.