当前位置: article > 正文

SSL/TLS介绍以及wireshark抓包TLS Handshake报文_ssl报文

作者：2023面试高手 | 2024-04-30 07:37:24

踩

ssl报文

文章目录

1.概念

SSL（Secure Sockets Layer）和TLS（Transport Layer Security）是一种安全协议，用于在计算机网络上实现加密通信。SSL最初由美国Netscape开发，随后发展为TLS，并得到了广泛应用，成为互联网上保护通信安全的标准协议。

TLS 位于 TCP 之上（也有基于 UDP 的，称为DTLS，这里不讨论它），如图所示。
在这里插入图片描述

SSL/TLS是在应用层和传输层之间的一个安全协议，通信的双方在进行通信前需要握手，通过在通信的两端建立一个安全的通道，保护数据在传输过程中的安全性。以下是SSL/TLS提供的几个重要的安全功能：

机密性（Confidentiality）： SSL/TLS使用加密算法对数据进行加密，防止未经授权的第三方窃取和读取敏感信息。只有身份验证通过的终端才能解密数据。
完整性（Integrity）： SSL/TLS使用消息认证码（MAC）或哈希函数来确保数据在传输过程中没有被篡改或损坏，接收方可以验证数据的完整性，确保数据在传输期间没有被篡改。
身份验证（Authentication）： SSL/TLS提供了一种机制，用于验证通信的两端的身份。这可以防止中间人攻击和伪造身份的风险。通常使用数字证书来验证服务器和客户端的身份。
抗重放攻击（Resistance to Replay Attacks）： SSL/TLS使用时间戳和随机数来抵御重放攻击。每个通信会话都用独特的随机数，从而防止攻击者重复使用已经捕获到的通信数据。
前向保密（Forward Secrecy）： SSL/TLS支持前向保密，即使长期密钥泄漏，过去的通信数据也不会被攻击者解密。这是通过动态生成临时会话密钥并定期更换来实现的。

1.1 SSL/TLS发展历史

在这里插入图片描述

1.2 TLS两个阶段

TLS协议可分为两个阶段：

握手（Handshake）阶段，目的是通信双方约定好在数据传输阶段使用的加密算法及密钥（为效率考虑，在数据传输阶段会使用对称密钥算法）；
数据传输阶段，即发送到网络前加密数据，从网络收到数据后解密数据。

1.3 TLS报文头

在这里插入图片描述

第1字节是类型（目前有4种类型）：

 Record Type Values       dec      hex
 -------------------------------------
 CHANGE_CIPHER_SPEC        20     0x14
 ALERT                     21     0x15
 HANDSHAKE                 22     0x16
 APPLICATION_DATA          23     0x17
1
2
3
4
5
6

第2-3字节是版本（目前有4种版本）：

 Version Values            dec     hex
 -------------------------------------
 SSL 3.0                   3,0  0x0300
 TLS 1.0                   3,1  0x0301
 TLS 1.1                   3,2  0x0302
 TLS 1.2                   3,3  0x0303
1
2
3
4
5
6

第4-5字节是长度（不包含报文头本身长度）

2.TLS Handshake

2.1 Handshake具体过程

在这里插入图片描述

第1步：客户端发送ClientHello报文。作用是告诉服务器，本客户端所支持的TLS协议版本，以及支持的加密算法等。
第2步：服务器发送ServerHello报文。主要是告诉客户端，服务器选择了一个它认为安全的，且双方都支持的加密算法；如果服务器认为客户端所支持的加密算法都不安全，则服务器可以发送一个ALERT报文。
第3步：服务器发送Certificate报文。其主要作用是服务器发送自己的证书给客户端。
第4步：服务器发送ServerKeyExchange。其作用是提供一些信息，以便双方有足够的信息来约定一个数据传输阶段所使用的对称密钥算法的密钥。这个报文是可选的，如果使用Diffie-Hellman方式来约定密钥，则这个是必须的；如果是RSA方式来约定密钥，它可以省略，参见后面介绍的ClientKeyExchange报文。
第5步：服务器发送CertificateRequest。作用是开启”双向认证（Mutual authentication）“模式，即不仅客户端要验证服务器，而且服务器还要验证客户端。这种方式在https网站中很少使用，如果对https网站进行抓包，一般不会有这个报文。
第6步：服务器发送ServerHelloDone。服务器发送此消息以指示握手消息的结束。
第7步：客户端发送Certificate报文（仅当客户端收到了CertificateRequest时才发送，即服务器开启了双向认证）。主要作用是客户端发送自己的证书给服务器。
第8步：客户端发送ClientKeyExchange报文。其主要作用是提供一些信息，以便双方有足够的信息来约定一个数据传输阶段所使用的对称算法的密钥。如RSA方式，则客户端生成一个对称算法的密钥后，使用服务器的公钥加密传送给服务器。如果是Diffie-Hellman方式，则传送必要信息以便双方可以按约定方式生成一个密钥。
第9步：客户端发送CertificateVerify报文（仅当客户端收到了CertificateRequest时才发送，即服务器开启了双向认证）。主要作用是客户端发送一段它签名的信息给服务器，这样服务器使用客户端的公钥就可以验证签名，从而验证客户端。
第10步：客户端发送ChangeCipherSpec报文，告诉服务器你可以使用加密模式了。注：ChangeCipherSpec报文不属于Handshake报文，它是TLS顶级报文，存在于TLS报文头中。
第11步：客户端发送Finished报文，告诉服务器我准备好加密通信了。
第12步：服务器发送ChangeCipherSpec报文，告诉客户端你可以使用加密模式了。
第13步：服务器发送Finished报文，告诉客户端我准备好加密通信了。至此，握手结束。

2.1.1 单向认证和双向认证

握手阶段，如果服务器发送了CertificateRequest，就意味着开启”双向认证“。和单向认证相比，”双向认证“在握手阶段多了下面3种报文：

服务器发送的 CertificateRequest ；
客户端发送的 Certificate 和 CertificateVerify 。

2.1.2 复用TLS协商结果

当客户端和服务器在TLS握手过程中建立了一个安全连接后，可以通过复用TLS协商结果来提升后续通信的效率和性能。这通常可以通过两种方式来实现：Session Identifier 和 Session Ticket。

Session Identifier（会话标识符）

Session Identifier 是一种简单的方式，它使用一个唯一的标识符来引用之前的TLS会话。

建立会话：在TLS握手过程中，如果服务器支持会话复用，它会在ServerHello消息中包含一个Session Identifier。客户端可以在以后的请求中使用这个标识符来复用会话。
客户端发送请求：客户端在HTTP请求中包含之前建立的Session Identifier。
服务器检查会话：当服务器收到请求时，它会检查Session Identifier是否有效。如果有效，服务器可以使用之前协商的加密参数和密钥，而不需要进行完整的TLS握手。

Session Identifier 的优点是它很简单，但它的缺点是，如果服务器重新启动或者会话超时，之前的Session Identifier就会失效，需要重新建立会话。

Session Ticket（会话票据）

Session Ticket 是一种更灵活的方式，它允许会话信息在服务器重启后仍然有效。

生成会话票据：在TLS握手完成后，服务器可以将会话信息加密并存储在一个会话票据中，然后发送给客户端。
客户端发送请求：客户端在HTTP请求中包含会话票据。
服务器解密会话票据：当服务器收到请求时，它可以解密会话票据并使用其中的会话信息来恢复会话。

Session Ticket 的优点是它可以在服务器重启后仍然保持会话的有效性，但需要确保会话票据的安全性，以防止被恶意利用。

总的来说，Session Identifier 是一种简单且有效的会话复用方式，但在某些情况下可能会失效。Session Ticket 提供了更灵活的会话复用机制，可以在服务器重启后仍然保持会话的有效性。服务器可以根据具体情况选择使用其中一种或两者结合使用。

2.2 Handshake报文格式

                         |
                         |
                         |
       Record Layer      |  Handshake Layer
                         |                              |                              |
                         |                              |                              |
+----+----+----+----+----+----+----+----+----+------ - -+----+----+----+----+------ - -+ ......
| 22 |    |    |    |    |    |    |    |    |          |    |    |    |    |          |
|0x16|    |    |    |    |    |    |    |    |message   |    |    |    |    |message   |
+----+----+----+----+----+----+----+----+----+------ - -+----+----+----+----+------ - -+
  /             /--/--/  | \    \----\-----\            | \    \----\-----\            |
 /                /      |  \         \                    \         \
type: 22         /       |   \     handshake message length \    handshake message length
                /             type                          type
               /
         length: arbitrary (up to 16k)


 Handshake Type Values    dec      hex
 -------------------------------------
 HELLO_REQUEST              0     0x00
 CLIENT_HELLO               1     0x01
 SERVER_HELLO               2     0x02
 CERTIFICATE               11     0x0b
 SERVER_KEY_EXCHANGE       12     0x0c
 CERTIFICATE_REQUEST       13     0x0d
 SERVER_HELLO_DONE         14     0x0e
 CERTIFICATE_VERIFY        15     0x0f
 CLIENT_KEY_EXCHANGE       16     0x10
 FINISHED                  20     0x14
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30