通过Wireshark分析HTTPS握手过程与协议概述

逃离我推掉我的手 2022-08-28 01:54 207阅读 0赞

TLS是一种密码学协议，用于保证两者之间的会话安全。整个SSL/TLS协议内容太多，本文只从握手，加密，套件等方面对TLS 1.2进行简要总结。  
协议详细内容，可以参见：

*  RFC：http://tools.ietf.org/html/rfc5246
 *  CLOUDFLARE：https://www.cloudflare.com/learning/ssl/what-is-ssl/

# 1. 握手（Handshake） #

握手是TLS协议中最精密复杂的部分。在这个过程中，通信双方协商连接参数，并且完成身份验证。根据使用的功能的不同，整个过程通常需要交换6~10条消息。根据配置和支持的协议扩展的不同，交换过程可能有许多变种。在使用中经常可以观察到以下三种流程：

1.  完整的握手，对服务器进行身份验证；
2.  恢复之前的会话采用的简短握手；
3.  对客户端和服务器都进行身份验证的握手。

## 1.2 完整的握手 ##

完整的握手流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70]

也可以参考cloudflare的流程：https://www.cloudflare.com/learning/ssl/keyless-ssl/

在Wireshark中的数据包为：  
![在这里插入图片描述][20191205111822492.jpg]

上图的流程大概可总结为：

1.  客户端开始新的握手，并将自身支持的功能提交给服务器。
2.  服务器选择连接参数。
3.  服务器发送其证书链。
4.  根据选择的密钥交换方式，服务器发送生成主密钥的额外信息。
5.  服务器通知自己完成了协商过程。
6.  客户端发送生成主密钥所需的额外信息。
7.  客户端切换加密方式并通知服务器。
8.  客户端计算发送和接收到的握手消息的MAC并发送。
9.  服务器切换加密方式并通知客户端。
10. 服务器计算发送和接收到的握手消息的MAC并发送。

TLS/SSL使用非对称加密提供身份认证和密钥协商(RSA、DH、ECC)，使用对称加密完成信息加密(AES、DES、RC4)，使用散列算法提供完整校验(MD5、SHA)

接下来将用Wireshark来分析一次真实的握手过程

### 1.2.1 ClientHello ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 1]

ClientHello为握手的第一条消息，发送的内容有：

*  TLS版本
 *  Handshake Type
 *  随机数：总共包含32字节的数据。只有28字节是随机生成的，剩余的4字  
    节包含额外的信息，受客户端时钟的影响。这里标记为random\_c
 *  Session ID:在第一次连接时，会话ID（ session D）字段是空的，这表示客户端并不希望恢复某个已存在的会话。在后续的连接中，这个字段可以保存会话的唯一标识。服务器可以借助会话ID在自己的缓存中找到对应的会话状态
 *  支持的密码套件cipher suites:客户端支持的所有密码套件组成的列表，该列表是按优先  
    级顺序排列的
 *  压缩方法:客户端可以提交一个或多个支持压缩的方法。默认的压缩方法是null，代表没有压缩
 *  Extensions:扩展（ extension）块由任意数量的扩展组成。这些扩展会携带额外数据。

### 1.2.2 ServerHello ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 2]  
ServerHello消息的意义是将服务器选择的连接参数传送回客户端，结构与ClientHello类似。这里返回了随机数（标记为random\_s）,选择的套件TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256，以及扩展

### 1.2.3 Certificate ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 3]

该部分是服务器返回给客户端的证书链，如果你访问百度，会发现会有两个证书且按照等级高的在前的顺序列出来，由于样例中的证书是自己签发的且不涉及CA,所以只有一个证书。

服务器必须保证它发送的证书与选择的算法套件一致。因为并非所有套件都使用身份验证，也并非所有身份验证方法都需要证书，所以该消息是可选的。

### 1.2.4 ServerKeyExchange ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 4]

该消息的目的是携带密钥交换的额外数据，消息内容对于不同的协商算法套  
件都会存在差异。由于这里采用的是ECDHE算法，类似DH算法，所以需要密钥交换阶段，RSA算法是没有这步的。

### 1.2.5 ServerHelloDone ###

![在这里插入图片描述][20191205112043393.jpg]  
ServerHelloDone消息表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息

### 1.2.6 Client Key Exchange ###

![在这里插入图片描述][20191205112052137.jpg]  
ClientKeyExchange消息携带客户端为密钥交换提供的所有信息，内容随着不同的协商密码套件而不同。  
如果是DH算法，则是发送交换密钥，如果是RSA则是使用服务器公钥加密随机数pre-master，与random\_c、random\_s共同构成协商密钥

本例中的是DH算法的的秘钥

### 1.2.7 Change Cipher Spec ###

![在这里插入图片描述][20191205112122915.jpg]  
ChangeCipherSpec消息表明发送端已取得用以生成连接参数的足够信息，已生成加密密钥，并且将切换到加密模式,此后客户端的数据均为协商密钥加密的密文。

**ChangeCipherSpec不属于握手消息，它是另一种协议，只有一条消息，作为它的子协议进行实现**

### 1.2.8 Encypted Handshake Message(finish) ###

![在这里插入图片描述][20191205112145308.jpg]  
为结合所有当前的通信参数信息生成一段数据，并使用协商密钥加密后的内容

### 1.2.9 New Session Ticket ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 5]

会话标识符，解决会话缓存问题，这些数据采用一个只有服务器知道的密钥进行加密。Session Ticket由客户端进行存储，并可以在随后的一次会话中添加到 ClientHello消息的SessionTicket扩展中

### 1.2.10 ChangeCipherSpec,Encypted Handshake Message(finish) ###

与客户端发送的意义类似，代表服务器端协商的结束，与加密的开始。

## 1.3 会话恢复 ##

完整的握手协议非常复杂，需要很多握手消息和两次网络往返才能开始发送客户端应用数据。会话的恢复机制可以减少网络的交互以及计算秘钥的资源开销。话恢复机制为：在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保存一段时间。

*  服务器希望恢复:服务器在ServerHello消息中将会话ID发回客户端。
 *  客户端希望恢复:客户端将会话ID放入ClientHello消息，然后提交。

服务器如果愿意恢复会话，就将相同的会话ID放入ServerHello消息返回，接着使用之前协商的主密钥生成一套新的密钥，再切换到加密模式，发送Finished消息。客户端收到会话已恢复的消息以后，也进行相同的操作。这样的结果是握手只需要一次网络往返。

在Wireshark中的流程为：

![在这里插入图片描述][20191205112231413.jpg]

此时Client Hello的消息已经包含了Session ID.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 6]

# 2. 秘钥交换(Key Exchange) #

密钥交换的主要目的是计算预主密钥（ premaster secret）。这个值是组成主密钥的来源。

master_secret=PRF(pre_master_secret,"master secret",random_c,random_s)

## 2.1 RSA ##

由客户端生成一个随机值作为预主密钥，**并以服务器公钥加密**，将其包含在ClientKeyExchange消息中，最后发送出去。服务器只需要解密这条消息  
就能取出预主密钥。  
优点：简单，快速  
缺点：

1.  不支持向前保密
2.  用于加密预主密钥的服务器公钥，一般会保持多  
    年不变。如果可以得到私钥，就可以恢复预主密钥，并构建相同的主密钥

## 2.2 ECDHE(临时椭圆曲线Diffie-Hellman:ephemeral elliptic curve Diffie-Hellman) ##

临时椭圆曲线Diffie-Hellman（ ephemeral elliptic curve Diffie-Hellman， ECDHE）密钥交换建立在椭圆曲线加密的基础之上，其有速度快且向前兼容的优点。在TLS中， ECDHE可以与RSA或者ECDSA身份验证  
一起使用。

ECDHE密钥交换由服务器发起，它选择一条椭圆曲线和公开参数(EC point)，**并使用自己的私钥签名**:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 7]

然后客户端提交自己的公开参数：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 8]

现在就可以计算预主密钥。

# 3. 身份验证 #

身份验证的目的是来验证双方的身份，基础是证书包含的公钥密码（最常见的是RSA，有时也用ECDSA）。不同的秘钥交换算法，验证的方式存在一点差异：

1.  RSA秘钥交换：在RSA密钥交换的过程中，客户端生成一个随机值作为预主密钥，并以服务器公钥加密后发送出去，只有拥有证书对应私钥的服务器才能解开预主密钥
2.  ECDHE秘钥交换：服务器使用证书对应的私钥对算法参数进行加密，客户端收到参数使用证书的公钥进行解密。

# 4. 加密算法与类型 #

加密算法主要用来对应用数据进行加密，常见的算法有：3DES、 AES、 ARIA、 CAMELLIA、 RC4。目前最为广泛的是AES

TLS支持的加密类型包括以下三种：

1.  序列加密

使用序列密码时，加密由两步组成。第一步，计算MAC值，范围包含记录序列号、标头、明文。MAC包含标头能确保未进行加密的标头不会遭受篡改。MAC包括序列号，能确保消息不被重放。第二步，加密明文和MAC，生成密文。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 9]

1.  分组加密：

使用分组密码时，加密会涉及更多内容，因为需要为分组加密的特性准备解决方案。具体来 说，需要以下几个步骤：  
1. 计算序列号、标头和明文的MAC。  
2. 构造填充，确认加密前的数据长度是分组大小(通常16字节)的整数倍。  
3. 生成一个长度与分组大小一致的不可预期的初始向量(initialization vector，IV)。IV能保证加密是不确定的。  
4. 使用CBC分组模式加密明文、MAC和填充。  
5 将IV和密文一起发送。  
操作流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 10]

1.  以验证加密

已验证的密码将加密和完整性验证合二为一，全名是使用关联数据的已验证加密。已验证加密被认为是当前TLS中可用的加密模式中最好的一种，因为它可以避免MAC-then-  
encrypt方式带来的问题。

虽然TLS当前定义了基于GCM和CCM块模式的已验证套件，实际上仅支持GCM套件。

操作流程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 11]

# 5. 重新协商 #

大部分TLS连接都以握手作为起点，经过应用数据的交换，最后关闭会话。但如果请求重新协 商，就会发起一次新的握手，对新的连接安全参数达成一致。该功能在以下场景很有用：

*  客户端证书：客户端证书并不常用，但因为它可以提供双因素身份验证，所以还是有一些网站在使用它
 *  改变加密强度： 当网站加密刚刚出现(而且是CPU密集的)的时候，经常可以发现网站将加密配成两个级别。你可以默认使用比较弱的加密，而在特定区域使用强加密。当尝试进入网站中更安全的子区域时，服务器将请求更强的安全性。

# 6. 警报协议 #

警报的目的是以简单的通知机制告知对端通信出现异常状况。它通常会携带close\_notify异常，在连接关闭时使用，报告错误。警报非常简单，只有两个字段：

*  level:表示警报的严重程度，可取值warning或者fatal
 *  description:表示警报代码

# 7. 秘钥操作 #

在TLS中，伪随机函数(pseudorandom function，PRF)用于生成任意数量的伪随机数据，其中主密钥，最终秘钥都依赖伪随机函数

## 7.1 预主秘钥(premaster secrets) ##

密钥交换过程的输出是预主密钥。不同的秘钥交换算法采取的方式有所不同：

*  RSA：RSA密钥交换的过程十分直接。客户端生成预主密钥(46字节随机数)，使用服务器公钥对其加密，将其包含在ClientKeyExchange消息发送出去
 *  ECDHE：使用客户端以及服务器端的dh参数生成预主秘钥

## 7.2 主秘钥 ##

对预主密钥进行进一步加工，就是使用PRF生成48字节(384位)主密钥:

master_secret = PRF(pre_master_secret, "master secret",
    ClientHello.random + ServerHello.random)

由于PRF输出的长度是固定的，所以即使预主密钥长度可能不同，最终结果的长度也是一致的。

同时，因为客户端和服务器的随机字段被用作种子，所以主密钥实际上也是随机的.

## 7.3 秘钥 ##

最终用来加密数据的秘钥生成方式如下：  
key\_block = PRF(master\_secret, “key expansion”, server\_random + client\_random)

由于生成key\_block的参数，在server以及client上都是一致的，所以两方生成的key\_block也是一致的。

key\_block块分为六个密钥:

*  两个MAC密钥:已验证加密的套件不使用MAC密钥，例如GCM。
 *  两个加密密钥：加密数据
 *  两个初始向量:只在必要时生成;序列密码不会使用IV。

# 8. 密码套件 #

密码套件定义了秘钥交换，身份验证，加密算法，加密模式等方式。密码套件的构成如下：  
![在这里插入图片描述][20191205112455247.jpg]

密码套件并未完全掌控其安全参数。它们只是定义了最关键的身份验证和密钥交换算法，而 对这些算法的实际参数并没有控制能力(比如密钥和参数强度)。

对于身份验证，其强度主要依靠证书，更确切地说是证书中的密钥长度和签名算法。RSA密 钥交换的强度也依赖证书。可以为DHE和ECDHE密钥交换配置不同的强度，这通常是在服务器 级别的配置中完成的

# 9. 发展历史 #

SSL3（1995年末发布）->TLS 1.0(1999年初)->TLS 1.1(2006.4发布) ->TLS1.2(2008年8月发布，目前使用较广的版本)

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70]: /images/20220828/0207aea260b04bd6852cb83ad4a3c053.png
[20191205111822492.jpg]: /images/20220828/bf9350f10181408fb791c044366a8de6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 1]: /images/20220828/ea31ece4c3024d6aab24c004528c2613.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 2]: /images/20220828/8f004bd96ea94d8ea8d790949cabc160.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 3]: /images/20220828/ecedfbdf8fb6402b8851474d1518de20.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 4]: /images/20220828/3a6c88fd12e043338099480256d6fda1.png
[20191205112043393.jpg]: /images/20220828/843790b8d9394c4599c461a14fa0a61d.png
[20191205112052137.jpg]: /images/20220828/f0b961f7607545e7a3c2d6bc604080fc.png
[20191205112122915.jpg]: /images/20220828/0745fcd1a5104aa1b83750862ac722a9.png
[20191205112145308.jpg]: /images/20220828/69a19b0dabb042709eb3569e4d5ac027.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 5]: /images/20220828/5df627bc770e48e48d15c07c8cf85d30.png
[20191205112231413.jpg]: /images/20220828/bf2b95a9306d485f89451164e5ce5355.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 6]: /images/20220828/c4ee3d8603f648c7ab1c52f1736d32ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 7]: /images/20220828/5111cc09a9e64a18a324dcb341ed89a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 8]: /images/20220828/fde2c6366d5042a3aa935ae8fe1b651f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 9]: /images/20220828/27804a7f5cda4085957af6573185c007.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 10]: /images/20220828/3d00b9f8d2144adfac33f7e1717e5db7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 11]: /images/20220828/141af3612685439cb9a486ab210e94c3.png
[20191205112455247.jpg]: /images/20220828/7f8070e8d8c0464695b84be95a7742f1.png