408/notes_estom
1
0
Fork 0
mirror of https://github.com/Estom/notes.git synced 2026-04-02 02:20:25 +08:00
Code Issues Packages Projects Releases Wiki Activity

TLS实验完成

Browse Source
This commit is contained in:
Estom
2021-06-21 11:54:49 +08:00
parent 4d6feb55c9
commit 8cf547b09b
24 changed files with 792 additions and 174 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
加密/2 TLS加密协议.md
View File

@@ -1,4 +1,4 @@
## 1 简介
## 1 基本概念
### 协议简介
@@ -11,8 +11,8 @@ SSL/TLS是一种密码通信框架，他是世界上使用最广泛的密码通
包括秘钥生成、加密、解密三个主要过程。
* 非对称加密算法：RSA，DSA/DSS,Diffie–Hellman
* 对称加密算法：AES，RC4，3DES
* 非对称加密算法：RSA，DSA/DSS,Diffie–Hellman。协商对称加密的**共享密钥**。（也称为**主密钥**或者**会话密钥**）
* 对称加密算法：AES，RC4，3DES。用来加密数据
* 秘钥生成算法：premaster secret、master secret
### 消息摘要算法
@@ -50,7 +50,9 @@ SSL/TLS是一种密码通信框架，他是世界上使用最广泛的密码通
* 应用最广泛的是TLS1.0，接下来是SSL3.0 。但主流浏览器都已经实现了TLS 1.2 的支持。TLS 1.0有时被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。TLS和SSL协议理论上属于传输层，在应用层实现，所以我们可以在浏览器中设置是否使用此协议，使用哪一版本的协议。
## 2 应用
## 2 功能作用
### 主要应用
SSL/TLS是一个安全通信框架，上面可以承载HTTP协议或者SMTP/POP3协议等。下层基于TCP可靠数据连接实现。
@@ -64,14 +66,14 @@ SSL/TLS是一个安全通信框架，上面可以承载HTTP协议或者SMTP/POP3
数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。
### 安全性
### 安全性分析
- 可以使用非对称或公钥、密码术（例如，RSA [RSA]、DSA [DSS] 等）来验证对等方的身份。此身份验证可以是可选的，但通常需要至少其中一位同行。
- 共享机密的协商是安全的：窃听者无法获得协商的机密，并且对于任何经过身份验证的连接，即使攻击者可以将自己置于连接中间，也无法获得该机密。
- 协商可靠：任何攻击者都不能在不被通信双方检测到的情况下修改协商通信。
## 3 架构
## 3 架构实现
![](image/2021-06-15-20-12-34.png)

181
加密/3 TLS协议变迁.md
View File

@@ -7,6 +7,107 @@
* 对话的内容用”对称加密”,而对于”对称加密”带来的密钥传输问题,则由”非对称加密”来解决,由于客户端没有”非对称加密”的解密能力,所以密钥由客户端来产生并用公钥加密传输给服务端,这样就(在思路上)解决了密钥传输的安全问题和对话数据解密的性能问题
### 技术
## 2 TSL1.1
### 特点
- 隐式初始化向量（IV）被显式IV替换以防止CBC攻击[CBCATT]。
- 填充错误的处理被更改为使用坏的\u记录\u mac警报，而不是解密失败的警报，以防止CBC攻击。
- IANA注册表是为协议参数定义的。
- 过早关闭不再导致会话不可恢复。
- 为TLS上的各种新攻击添加了其他信息注释。
### 技术
## 3 TSL1.2
### 特点
本文件是TLS 1.1[TLS1.1]协议的修订版，其中包含改进的灵活性，特别是对于密码算法的协商。主要变化是：
- 伪随机函数（PRF）中的MD5/SHA-1组合已被密码套件指定的PRF所取代。本文档中的所有密码套件都使用P_SHA256。
- MD5/SHA-1组合在数字电视中的应用.签名元素已被替换为单个哈希。有符号元素现在包含一个字段，该字段显式指定所使用的哈希算法。
- 增加了对附加数据模式的认证加密的支持。
- TLS扩展定义和AES密码套件由外部[TLSEXT]和[TLSAES]合并而成。
- 更严格地检查加密的premastersecret版本号。
- 验证数据的长度现在取决于密码套件（默认值仍然是12）。
- 在许多情况下，现在必须发送警报。
- 在证书请求之后，如果没有可用的证书，客户端现在必须发送一个空的证书列表。
- TLS_RSA_WITH_AES_128_CBC_SHA现在是实现密码套件的必备工具。
- 添加HMAC-SHA256密码套件。
- 删除IDEA和DES密码套件。它们现在已被弃用，并将记录在一个单独的文档中。
- 支持SSLv2
### 技术
## 4 TSL1.3
### 概念
* ClientHello 中的参数ClientHello---{ Random_C 、extension } 在 extension中的扩展中包含 （ supported_version 、 supported_groups、 signatureschemlist、key_shared ）
* 服务器接收到之后需要选择支持的最高版本协议，秘钥分发算法和选择的公钥，加密签名算法、以及random_S、session_id 回复 serverHello，算出自己前主秘钥，紧接着使用自己选择的加密方式加密发送一个 Encryption_Extension报文，接着服务器加密发送CA证书与数字签名，然后等待客户端的回复 Finished
* 客户端收到服务器的 SeverHello报文之后，计算前主秘钥，解密接下来收到的文件，验证其正确性，如果存在问题，发送警告报文，然后终端此次握手。重新建立握手，如果正确加密发送Finished 报文，之后可以发送加密的数据报文。
* 服务器计算主秘钥，收到Finished报文之后，加密发送Finished 报文，然后握手成功，可以选择新的会话 tickets报文
* 传统的加密算法被精简了，剩下的都是有关认证加密的关联。客户端和服务端，服务读研收到客户端的ClientHello之后，响应客户端发送ServerHello ,如果选择（EC）DHE 秘钥建立方法，ServerHello包含 “key_share”的扩展 但是如果选择的是PSK秘钥建立ServerHello中包含“pre_shared_key”扩展，表明客户端提供的PSKs被选择，注意实现方式可以同时选择 （ EC）DHE 和 PSK两种方式。当选择两种方式的时候两个扩展都应该包括
### 特点
- 受支持的对称加密算法列表已从所有被认为是遗留的算法中删去。剩下的都是使用关联数据（AEAD）算法进行身份验证的加密。密码套件的概念已经改变，将身份验证和密钥交换机制与记录保护算法（包括密钥长度）分开，并将哈希与密钥派生函数和握手消息身份验证码（MAC）一起使用。
- 添加了零往返时间（0-RTT）模式，节省了一些应用程序数据在连接设置时的往返时间，但牺牲了某些安全属性。
- 删除了静态RSA和Diffie-Hellman密码；所有基于公钥的密钥交换机制现在都提供前向保密性。
- ServerHello之后的所有握手消息现在都已加密。新引入EncryptedExtensions消息允许以前在服务器hello中以明文形式发送的各种扩展也享受保密保护。
- 重新设计了密钥派生函数。新的设计由于其改进的密钥分离特性，使得密码学家可以更容易地进行分析。基于HMAC的提取和扩展密钥派生函数（HKDF）被用作底层原语。
- 握手状态机已经被显著地重新构造为更加一致，并且删除了诸如ChangeCipherSpec之类的多余消息（除了在需要中间盒兼容性时）。
- 椭圆曲线算法现在是基本规范，新的签名算法，如EdDSA，包括在内。TLS 1.3删除了点格式协商，支持每条曲线的单点格式。
- 进行了其他加密改进，包括更改 RSA 填充以使用 RSA 概率签名方案 (RSASSA-PSS)，以及取消压缩、数字签名算法 (DSA) 和自定义临时 Diffie-Hellman (DHE) 组。
- TLS 1.2 版本协商机制已被弃用，以支持扩展中的版本列表。 这增加了与错误实施版本协商的现有服务器的兼容性。
- 带有和不带有服务器端状态的会话恢复以及早期 TLS 版本的基于 PSK 的密码套件已被一个新的 PSK 交换所取代。
### 技术
### 简化与改进
* 其他还包括新的密钥派生函数，删除多余的报文消息（ChangeCipherSpec，但我抓包测试时还是有）
* 全面使用ECC密码算法，删除不具有前向安全的密码套件。废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法
* 不再允许对加密报文进行压缩、不再允许双方发起重协商
* DSA 证书不再允许在 TLS 1.3 中使用
* TLS 1.3 的握手不再支持静态的 RSA 密钥交换，这意味着必须使用带有前向安全的 Diffie-Hellman 进行全面握手。
* ServerHello之后的所有握手消息都被加密，引入了加密扩展EncryptedExtension。ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少
## 5 加密套件的变迁
### TLS1.0
```
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
@@ -43,23 +144,8 @@ CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
```
## 2 TSL1.1
### 特点
相对之前版本的变化
- 隐式初始化向量（IV）被显式IV替换以防止CBC攻击[CBCATT]。
### TLS1.1
- 填充错误的处理被更改为使用坏的\u记录\u mac警报，而不是解密失败的警报，以防止CBC攻击。
- IANA注册表是为协议参数定义的。
- 过早关闭不再导致会话不可恢复。
- 为TLS上的各种新攻击添加了其他信息注释。
### 技术
* 密码套件
```
//RSA 加密、认证套件
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
@@ -85,42 +171,7 @@ CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
```
## 3 TSL1.2
### 特点
本文件是TLS 1.1[TLS1.1]协议的修订版，其中包含改进的灵活性，特别是对于密码算法的协商。主要变化是：
- 伪随机函数（PRF）中的MD5/SHA-1组合已被密码套件指定的PRF所取代。本文档中的所有密码套件都使用P_SHA256。
- MD5/SHA-1组合在数字电视中的应用.签名元素已被替换为单个哈希。有符号元素现在包含一个字段，该字段显式指定所使用的哈希算法。
- 增加了对附加数据模式的认证加密的支持。
- TLS扩展定义和AES密码套件由外部[TLSEXT]和[TLSAES]合并而成。
- 更严格地检查加密的premastersecret版本号。
- 验证数据的长度现在取决于密码套件（默认值仍然是12）。
- 在许多情况下，现在必须发送警报。
- 在证书请求之后，如果没有可用的证书，客户端现在必须发送一个空的证书列表。
- TLS_RSA_WITH_AES_128_CBC_SHA现在是实现密码套件的必备工具。
- 添加HMAC-SHA256密码套件。
- 删除IDEA和DES密码套件。它们现在已被弃用，并将记录在一个单独的文档中。
- 支持SSLv2
### 技术
* 密码套件
### TLS1.2
```
//RSA 加密、认证套件
@@ -166,32 +217,8 @@ CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
```
## 4 TSL1.3
### 特点
- 受支持的对称加密算法列表已从所有被认为是遗留的算法中删去。剩下的都是使用关联数据（AEAD）算法进行身份验证的加密。密码套件的概念已经改变，将身份验证和密钥交换机制与记录保护算法（包括密钥长度）分开，并将哈希与密钥派生函数和握手消息身份验证码（MAC）一起使用。
- 添加了零往返时间（0-RTT）模式，节省了一些应用程序数据在连接设置时的往返时间，但牺牲了某些安全属性。
- 删除了静态RSA和Diffie-Hellman密码；所有基于公钥的密钥交换机制现在都提供前向保密性。
- ServerHello之后的所有握手消息现在都已加密。新引入EncryptedExtensions消息允许以前在服务器hello中以明文形式发送的各种扩展也享受保密保护。
- 重新设计了密钥派生函数。新的设计由于其改进的密钥分离特性，使得密码学家可以更容易地进行分析。基于HMAC的提取和扩展密钥派生函数（HKDF）被用作底层原语。
- 握手状态机已经被显著地重新构造为更加一致，并且删除了诸如ChangeCipherSpec之类的多余消息（除了在需要中间盒兼容性时）。
- 椭圆曲线算法现在是基本规范，新的签名算法，如EdDSA，包括在内。TLS 1.3删除了点格式协商，支持每条曲线的单点格式。
- 进行了其他加密改进，包括更改 RSA 填充以使用 RSA 概率签名方案 (RSASSA-PSS)，以及取消压缩、数字签名算法 (DSA) 和自定义临时 Diffie-Hellman (DHE) 组。
- TLS 1.2 版本协商机制已被弃用，以支持扩展中的版本列表。 这增加了与错误实施版本协商的现有服务器的兼容性。
- 带有和不带有服务器端状态的会话恢复以及早期 TLS 版本的基于 PSK 的密码套件已被一个新的 PSK 交换所取代。
### 技术
### TLS1.3
* 新增的加密套件套件
```
+------------------------------+-------------+

80
加密/4 TLS1.3特性.md
View File

@@ -1,80 +0,0 @@
## 1 TSL1.2---->1.3变化
### 密钥协商机制改变
密钥协商机制改变，TLS1.3借助扩展进行密钥交换，TLS1.3只需要三次握手交互，TLS1.2则需要四次握手。相比过去的的版本，引入了新的密钥协商机制 — PSK
* TLS1.2，它通过KeyExchange进行密钥协商，即ServerKeyExchange和ClientKeyExchange，那么密钥交换本身就需要一个交互来回，所以总共有四次握手交互。
![](image/2021-06-17-13-42-45.png)
![](image/2021-06-17-15-16-54.png)
* TLS1.2 通过会话重建来加速完成密钥协商过程。
![](image/2021-06-17-15-16-35.png)
* TLS1.3，通过ClientHello和ServerHello的扩展进行密钥交换，那么就省去了1.2版本中KeyExchange的过程，也就省去了一次握手。
![](image/2021-06-17-13-44-32.png)
![](image/2021-06-17-15-18-48.png)
* TLS1.3 0-RTT模式密钥交换。以某些安全属性为代价。当client和server共享一个预共享密钥PSK（从外部获得或通过一个以前的握手获得）时，TLS 1.3允许client在第一个发送出去的消息的early data中携带数据，client使用这个PSK来认证server并加密early data。即在握手之前就有了PSK时，在第一次发送ClientHello时就可以发送加密数据，达到0-RTT数据传输的目的。
![](image/2021-06-17-13-45-46.png)
![](image/2021-06-17-15-15-49.png)
### 简化与改进
* 其他还包括新的密钥派生函数，删除多余的报文消息（ChangeCipherSpec，但我抓包测试时还是有）
* 全面使用ECC密码算法，删除不具有前向安全的密码套件。废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法
* 不再允许对加密报文进行压缩、不再允许双方发起重协商
* DSA 证书不再允许在 TLS 1.3 中使用
* TLS 1.3 的握手不再支持静态的 RSA 密钥交换，这意味着必须使用带有前向安全的 Diffie-Hellman 进行全面握手。
* ServerHello之后的所有握手消息都被加密，引入了加密扩展EncryptedExtension。ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少
## 2 密钥交换机制(握手协议)
### RSA 秘钥交换（TSL1.2）
1. client 发起请求（Client Hello）
2. server 回复 certificate
3. client使用证书中的公钥，加密预主秘钥，发给 server（Client Key Exchange）
4. server 提取出 预主秘钥，计算主秘钥，然后发送对称秘钥加密的finished。
5. client 计算主秘钥，验证 finished，验证成功后，就可以发送Application Data了。
缺点：RSA秘钥交换不是前向安全算法（证书对应私钥泄漏后，之前抓包的报文都能被解密）。所以在 TLS 1.3中 RSA 已经废弃了。
### ECDHE秘钥交换（TSL1.3）
1. client 发送请求（Client Hello），extension携带支持的椭圆曲线类型。
2. server 回复 Server Hello和certificate等；server选择的椭圆曲线参数，然后 生成私钥（BIGNUM），乘以椭圆曲线的base point得到公钥（POINT），顺便签个名表示自己拥有证书，然后将报文发给client，报文就是Server Key Exchange，其包含了server选择的椭圆曲线参数、自己根据这个参数计算的公钥、自己用证书的私钥对当前报文的签名。
3. client 收到 Server Key Exchange，获得椭圆曲线参数，生成私钥（BIGNUM）后计算公钥（POINT），然后把公钥发出去Client Key Exchange。client使用自己的私钥（BIGNUM）和server的公钥（POINT）计算出主秘钥。
4. server 收到 client的公钥（POINT），使用自己的私钥（BIGNUM），计算主秘钥。两端主秘钥是一致。
### 1-RTT模式密钥交换（TSL1.3）
TLS 1.3 中是这样优化握手的：
1. client 发送请求（Client Hello），extension携带支持的椭圆曲线类型。且对每个自己支持的椭圆曲线类型计算公钥（POINT）。公钥放在extension中的keyshare中。
1. 支持的加密套件（该作用和之前一样）。
2. supproted_versions 拓展。包含自己支持的TLS协议版本号。（之前协议没有）
3. supproted_groups 拓展，表示自己支持的椭圆曲线类型。
4. key_share拓展。包含supprot_groups中各椭圆曲线对应的public key。（当然可以发送空的，然后server会回复hello request，其中会包含server的key_share，可以用来探测，这里不讨论）。key_share中的椭圆曲线类型必须出现在supproted_groups中。（之前协议没有）
2. server 回复 Server Hello和certificate等；server选择的椭圆曲线参数，然后乘以椭圆曲线的base point得到公钥（POINT）。然后提取Client Hello中的key_share拓展中对应的公钥，计算主秘钥。公钥（POINT）不再和之前的以协议一样放在Server Key Exchange中，而是放在Server Hello的key_share拓展中。client收到server的公钥（POINT）后计算主秘钥。
1. （1）：supproted_versions 拓展。包含自己从client的supproted_versions中选择的TLS协议版本号。（之前协议没有）
2. （2）：key_share拓展。包含自己选中的椭圆曲线，以及自己计算出来的公钥。（之前协议没有）
3. server 发送Change Cipher Spec。（允许不发送）
4. server发送Encrypted Extension。（加密的）ServerHello之后必须立刻发送Encrypted Extension。这是第一个被加密的数据数据。显然，放在这里的拓展，是和秘钥协商没关系的拓展。（之前协议没有）
5. server发送Certificate（加密的）。这个报文和之前的协议没有太大区别，，在证书链中的每个证书后面，都有一个extension。（双向认证时也会有区别，有机会再说）。这个extension目前只能是OCSP Status extension和SignedCertificateTimestamps。
6. server发送Certificate Verify（加密的）这个报文并不陌生，但是以前只出现在双向认证（客户端认证）中，以前Certificate Verify生成的逻辑是将当前所有的握手报文解析解析签名（简单的md+非对称加密）。
7. server回复Finished（加密的）这个报文的目的和之前协议一样，检验握手报文的完整性。但是计算方法有变化。
### 0-RTT模式密钥交换
* 以某些安全属性为代价。当client和server共享一个预共享密钥PSK（从外部获得或通过一个以前的握手获得）时，TLS 1.3允许client在第一个发送出去的消息的early data中携带数据，client使用这个PSK来认证server并加密early data。即在握手之前就有了PSK时，在第一次发送ClientHello时就可以发送加密数据，达到0-RTT数据传输的目的。
![](image/2021-06-17-13-45-46.png)
## 3 椭圆曲线
然后我们来看下ECDH的秘钥协商过程，首先EC的意思是椭圆曲线，这个EC提供了一个很厉害的性质，你在曲线上找一个点P，给定一个整数K，求解Q=KP很容易，给定一个点P,Q，知道Q =KP，求K却是个难题。在这个背景下，给定一个大家都知道的大数G，client在每次需要和server协商秘钥时，生成一段随机数a，然后发送A=a*G给server，server收到这段消息（a*G）后，生成一段随机数b，然后发送B=b*G给client，然后server端计算(a*G)*b作为对称秘钥，client端收到后b*G后计算a*(G*b)，因为(a*G)*b = a*(G*b)，所以对称秘钥就是a*G*b啦，攻击者只能截获A=a*G和B=b*G，由于椭圆曲线难题，知道A和G是很难计算a和b的，也就无法计算a*G*b了
## 4 中间人攻击
中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。

600
加密/4 TLS密钥协商.md Normal file
View File

@@ -0,0 +1,600 @@
> 握手协议主要包括：**密钥协商机制**和**密钥交换算法**。基本的密钥协商机制是一样的，只是在不同的步骤交换的内容不一样。
> 握手是为了协商出一个client和server端都认可的一个**对称秘钥**，典型的秘钥协商算法有两种，RSA和ECDH，简明介绍下这两种算法会让你对这个过程更加清晰。
## 0 TLS1.1
### 协议构成
```
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
```
### 密钥交换算法
```
Key Exchange Algorithm Certificate Key Type
RSA RSA public key; the certificate MUST
allow the key to be used for encryption.
DHE_DSS DSS public key.
DHE_RSA RSA public key that can be used for
signing.
DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate MUST be DSS.
DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate MUST be RSA.
```
## 1 TLS1.2密钥协商机制
### 协议构成
* This protocol is used to negotiate the secure attributes of a session.
```
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
```
### FULL Handshake密钥协商机制
* TLS1.2，它通过KeyExchange进行密钥协商，即ServerKeyExchange和ClientKeyExchange，那么密钥交换本身就需要一个交互来回，所以总共有四次握手交互。
```
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Fig. 1. Message flow for a full handshake
```
### Session ID Handshake密钥协商机制
* TLS1.2 通过会话重建来加速完成密钥协商过程。
* 如果找到匹配项，并且服务器愿意重新建立指定会话状态下的连接，它将发送一个具有相同会话 ID 值的 ServerHello。此时，双方客户端和服务器必须发送更改密码规范消息并继续直接到完成的消息。一旦重新建立完成，客户端和服务器可以开始交换应用程序层数据。（请参见下面的流程图。）如果会话 ID 不匹配，服务器生成一个新的会话 ID， TLS 客户端和服务器执行完整的握手。
```
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Fig. 2. Message flow for an abbreviated handshake
```
### key-exchange-algorithm密钥交换算法
```
Key Exchange Alg. Certificate Key Type
RSA RSA public key; the certificate MUST allow the
RSA_PSK key to be used for encryption (the
keyEncipherment bit MUST be set if the key
usage extension is present).
Note: RSA_PSK is defined in [TLSPSK].
DHE_RSA RSA public key; the certificate MUST allow the
ECDHE_RSA key to be used for signing (the
digitalSignature bit MUST be set if the key
usage extension is present) with the signature
scheme and hash algorithm that will be employed
in the server key exchange message.
Note: ECDHE_RSA is defined in [TLSECC].
DHE_DSS DSA public key; the certificate MUST allow the
key to be used for signing with the hash
algorithm that will be employed in the server
key exchange message.
DH_DSS Diffie-Hellman public key; the keyAgreement bit
DH_RSA MUST be set if the key usage extension is
present.
ECDH_ECDSA ECDH-capable public key; the public key MUST
ECDH_RSA use a curve and point format supported by the
client, as described in [TLSECC].
ECDHE_ECDSA ECDSA-capable public key; the certificate MUST
allow the key to be used for signing with the
hash algorithm that will be employed in the
server key exchange message. The public key
MUST use a curve and point format supported by
the client, as described in [TLSECC].
```
### RSA key-exchange-algorithm密钥交换算法
![](image/2021-06-17-11-43-17.png)
RSA 秘钥交换
1. client 发起请求（Client Hello）
2. server 回复 certificate
3. client使用证书中的公钥，加密预主秘钥，发给 server（Client Key Exchange）
4. server 提取出 预主秘钥，计算主秘钥，然后发送对称秘钥加密的finished。
5. client 计算主秘钥，验证 finished，验证成功后，就可以发送Application Data了。
缺点：RSA秘钥交换不是前向安全算法（证书对应私钥泄漏后，之前抓包的报文都能被解密）。所以在 TLS 1.3中 RSA 已经废弃了。
### DH key-exchange-algorithm密钥交换算法
![](image/2021-06-17-11-46-08.png)
## 2 TLS1.3
### 协议构成
* The handshake protocol is used to negotiate the security parameters of a connection.
```
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* remaining bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
```
### 密钥协商机制+密钥交换算法
- Full Handshake
- (EC)DHE (Diffie-Hellman over either finite fields or elliptic
curves)
- PSK-only
- PSK with (EC)DHE
- 0-RTT Handshake
### FULL Handshake密钥协商机制
* TLS1.3，通过ClientHello和ServerHello的扩展进行密钥交换，那么就省去了1.2版本中KeyExchange的过程，也就省去了一次握手。
```
Figure 1 below shows the basic full TLS handshake:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
Figure 1: Message Flow for Full TLS Handshake
```
1. client 发送请求（Client Hello），extension携带支持的椭圆曲线类型。且对每个自己支持的椭圆曲线类型计算公钥（POINT）。公钥放在extension中的keyshare中。
1. 支持的加密套件（该作用和之前一样）。
2. supproted_versions 拓展。包含自己支持的TLS协议版本号。（之前协议没有）
3. supproted_groups 拓展，表示自己支持的椭圆曲线类型。
4. key_share拓展。包含supprot_groups中各椭圆曲线对应的public key。（当然可以发送空的，然后server会回复hello request，其中会包含server的key_share，可以用来探测，这里不讨论）。key_share中的椭圆曲线类型必须出现在supproted_groups中。（之前协议没有）
2. server 回复 Server Hello和certificate等；server选择的椭圆曲线参数，然后乘以椭圆曲线的base point得到公钥（POINT）。然后提取Client Hello中的key_share拓展中对应的公钥，计算主秘钥。公钥（POINT）不再和之前的以协议一样放在Server Key Exchange中，而是放在Server Hello的key_share拓展中。client收到server的公钥（POINT）后计算主秘钥。
1. （1）：supproted_versions 拓展。包含自己从client的supproted_versions中选择的TLS协议版本号。（之前协议没有）
2. （2）：key_share拓展。包含自己选中的椭圆曲线，以及自己计算出来的公钥。（之前协议没有）
3. server 发送Change Cipher Spec。（允许不发送）
4. server发送Encrypted Extension。（加密的）ServerHello之后必须立刻发送Encrypted Extension。这是第一个被加密的数据数据。显然，放在这里的拓展，是和秘钥协商没关系的拓展。（之前协议没有）
5. server发送Certificate（加密的）。这个报文和之前的协议没有太大区别，，在证书链中的每个证书后面，都有一个extension。（双向认证时也会有区别，有机会再说）。这个extension目前只能是OCSP Status extension和SignedCertificateTimestamps。
6. server发送Certificate Verify（加密的）这个报文并不陌生，但是以前只出现在双向认证（客户端认证）中，以前Certificate Verify生成的逻辑是将当前所有的握手报文解析解析签名（简单的md+非对称加密）。
7. server回复Finished（加密的）这个报文的目的和之前协议一样，检验握手报文的完整性。但是计算方法有变化。
### DHE share Handshake
* If the client has not provided a sufficient **"key_share"** extension(e.g., it includes only DHE or ECDHE groups)
```
Client Server
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: Message Flow for a Full Handshake with
Mismatched Parameters
```
1. client 发送请求（Client Hello），extension携带支持的椭圆曲线类型。
2. server 回复 Server Hello和certificate等；server选择的椭圆曲线参数，然后 生成私钥（BIGNUM），乘以椭圆曲线的base point得到公钥（POINT），顺便签个名表示自己拥有证书，然后将报文发给client，报文就是Server Key Exchange，其包含了server选择的椭圆曲线参数、自己根据这个参数计算的公钥、自己用证书的私钥对当前报文的签名。
3. client 收到 Server Key Exchange，获得椭圆曲线参数，生成私钥（BIGNUM）后计算公钥（POINT），然后把公钥发出去Client Key Exchange。client使用自己的私钥（BIGNUM）和server的公钥（POINT）计算出主秘钥。
4. server 收到 client的公钥（POINT），使用自己的私钥（BIGNUM），计算主秘钥。两端主秘钥是一致。
### PSK Handshake
* Resumption and Pre-Shared Key (PSK)
* 由于服务器通过 PSK 进行身份验证，因此它不会发送证书或 CertificateVerify 消息。
* 当客户提供通过 PSK 恢复，它还应该提供“key_share”扩展名到服务器允许服务器拒绝恢复，而是使用正常的full handshake过程。
* 服务器响应一个“pre_shared_key”扩展来协商使用 PSK 密钥。可以使用“key_share”响应扩展做（EC）DHE密钥建立。
```
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: Message Flow for Resumption and PSK
```
### 0-RTT Handshake
* TLS1.3 0-RTT模式密钥交换。以某些安全属性为代价。当client和server共享一个预共享密钥PSK（从外部获得或通过一个以前的握手获得）时，TLS 1.3允许client在第一个发送出去的消息的early data中携带数据，client使用这个PSK来认证server并加密early data。即在握手之前就有了PSK时，在第一次发送ClientHello时就可以发送加密数据，达到0-RTT数据传输的目的。
* This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK.
```
Client Server
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 4: Message Flow for a 0-RTT Handshake
```
## 3 椭圆曲线原理
* ECDH的秘钥协商过程，首先EC的意思是椭圆曲线，这个EC提供了一个很厉害的性质，你在曲线上找一个点P，给定一个整数K，求解Q=KP很容易，给定一个点P,Q，知道Q =KP，求K却是个难题。
* 在这个背景下，给定一个大家都知道的大数G，client在每次需要和server协商秘钥时，生成一段随机数a，然后发送A=a\*G给server。
* server收到这段消息（a\*G）后，生成一段随机数b，然后发送B=b\*G给client。
* server端计算(a\*G)\*b作为对称秘钥，client端收到后b\*G后计算a*(G\*b)，因为(a\*G)\*b = a\*(G\*b)，所以对称秘钥就是a\*G\*b啦。
* 攻击者只能截获A=a\*G和B=b\*G，由于椭圆曲线难题，知道A和G是很难计算a和b的，也就无法计算a*G*b了

91
加密/5 TLS实验.md
View File

@@ -1,7 +1,7 @@
![](image/2021-06-17-14-34-10.png)
<!-- ![](image/2021-06-17-14-34-10.png) -->
# TLS实验
# TLS1.3实验
> 主要包括两部分实验
> * TLS协议数据内容
@@ -10,15 +10,84 @@
## TLS1.3数据内容
### 实验截图
* client hello
![](image/2021-06-21-08-16-16.png)
* server hello
![](image/2021-06-21-08-17-38.png)
* client change cipher spec & client data
![](image/2021-06-21-09-23-51.png)
![](image/2021-06-21-08-19-08.png)
* server data
![](image/2021-06-21-08-18-44.png)
* 证书实例
![](image/2021-06-21-08-31-56.png)
### client hello
* TLSrecordlayer包括content type,TLS version,length。包裹的TLS handshake protocol
* Handshake protocol包括
* handshake type
* length
* version
* random
* session id length
* session id(通过session ID判断是否是同一个会话)
* cipher suits length
* cipher suits
* compress method length
* compress method ![](image/2021-06-21-08-29-36.png)
* extensions & extension length
* extension reserved
* extension server_name ![](image/2021-06-21-08-34-29.png)包含了服务器的名称
* extension extended_master_secrete
* extension renegotiation info
* extension support_groups ![](image/2021-06-21-08-49-04.png) client发送clientHello(extension)消息,extension中的support_groups中携带client支持的椭圆曲线的类型,并且在扩展key_share中计算出了相对应的公钥,一起发送给server
* extension ec_point_format ![](image/2021-06-21-08-45-31.png) 椭圆曲线算法的选择
* extension session_ticket
* extension application_layer_protocol_negotiation(ALPN)ALPN (Application Layer Protocol Negotiation)是TLS的扩展，允许在安全连接的基础上进行应用层协议的协商。 ![](image/2021-06-21-08-42-45.png)
* extension signature algorithm ![](image/2021-06-21-08-40-15.png)包含了一些列签名算法
* extension signed_certifage_timestamp
* extension key_share “key_share”带上曲线对应的客户端公钥参数，![](image/2021-06-21-08-54-22.png)
* extension psk_key_exchange_mode ![](image/2021-06-21-08-55-10.png)
* extension support versions 向前兼容![](image/2021-06-21-08-58-44.png)
* extension compress_certificate
* extension pre_share_key pre_shared_key（对称秘钥）是预共享秘钥认证机制PSK生成的对称秘钥，PSK是一种身份认证机制。![](image/2021-06-21-09-02-50.png)
### server hello
* TLSrecordlayer包括content type,TLS version,length。包裹的TLS handshake protocol
* Handshake protocol包括
* handshake type
* length
* version
* random
* session id length
* session id(通过session ID判断是否是同一个会话)
* cipher suits length
* cipher suits
* compress method length
* compress method
* extensions length
* support version支持的版本
* key share 椭圆曲线算法的公钥
* pre_share_key PSK算法的密钥
* change cipher spec protocol
* ![](image/2021-06-21-09-09-55.png)
* 加密内容，不会显示
* Server端发送 Encrypted Extension （加密）ServerHello 之后必须立刻发送 Encryption Extension ,这是第一个被加密的数据，和秘钥协商没有关系（之前TLS1.2没有）
* Server端发送 Certificate（加密）这个报文和之前的协议没有太大的差别，唯一的是证书链中的每个证书后面都有一个 extension（双向认证）
* server端发送certificate verify（加密）certificate verify 生成的额逻辑是当前所有的握手报文解析签名
* Server端回复Finished （加密）
### client change cipher spec & client data
* Change Cipher Spec
* Client发送加密的Finished
* client加密发送数据
### server data
* server 发送加密数据
## TLS1.3协议交互过程
### 原理
握手是为了协商出一个client和server端都认可的一个对称秘钥，典型的秘钥协商算法有两种，RSA和ECDH，简明介绍下这两种算法会让你对这个过程更加清晰。
## TLS1.3协议交互过程
###
## TLS1.3协议交互过程
![](image/2021-06-21-08-33-35.png)

BIN
加密/image/2021-06-21-08-16-16.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 98 KiB

BIN
加密/image/2021-06-21-08-17-38.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
加密/image/2021-06-21-08-18-44.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
加密/image/2021-06-21-08-18-52.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
加密/image/2021-06-21-08-19-08.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 92 KiB

BIN
加密/image/2021-06-21-08-29-36.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
加密/image/2021-06-21-08-31-56.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
加密/image/2021-06-21-08-33-35.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 394 KiB

BIN
加密/image/2021-06-21-08-34-29.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.2 KiB

BIN
加密/image/2021-06-21-08-40-15.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
加密/image/2021-06-21-08-42-45.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
加密/image/2021-06-21-08-45-31.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.7 KiB

BIN
加密/image/2021-06-21-08-49-04.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
加密/image/2021-06-21-08-54-22.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
加密/image/2021-06-21-08-55-10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.6 KiB

BIN
加密/image/2021-06-21-08-58-44.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
加密/image/2021-06-21-09-02-50.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.8 KiB

BIN
加密/image/2021-06-21-09-09-55.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.4 KiB

BIN
加密/image/2021-06-21-09-23-51.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 110 KiB