TLS1.2握手流程分析（RSA，ECDHE），和TLS1.3区别

一、加密算法简介
- 1.2 RSA简要流程
- 1.1 ECDHE简要流程
二、TLS1.2 握手消息简介
三、TLS1.2 RSA流程
四、TLS1.2 ECDHE流程
五、TLS1.2和TLS1.3区别
- 5.1 更快的访问速度
- 5.2 更强的安全性
六、wareshark抓包验证TLS1.2流程
七、参考

一、加密算法简介

HTTPS常用的密钥交换算法有两种，分别是RSA和ECDHE算法。
其中，RSA是比较传统的密钥交换算法，它不具备前向安全（指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏）的性质，因此现在很少服务器使用它。而ECDHE算法具有前向安全，所以被广泛使用。

1.2 RSA简要流程

a生成公钥pk跟私钥sk，公钥公开任何人都可以获得，私钥保密
b获取a的公钥，然后用a的公钥进行信息加密
a得到加密后的信息，用自己的私钥解密

公钥加密的信息只有私钥解得开，那么只要私钥不泄漏，通信就是安全的
总结：双方交换公钥，即可对传输的数据进行加解密

1.1 ECDHE简要流程

算法演变：DH算法 -- > DHE算法 -- > ECDHE算法（相对于DH做了效率的优化）

总体的思想为
对于公式

A = G ^ a % P
B = G ^ b % P

其中G，P为公开的常数。当已知a时，可以推算出A；反之，当已知A时，几乎无法推算出a。
映射到加密算法中，a为私钥，A为公钥
并且以下两个表达式的计算结果相等

B ^ a % P = A ^ b % P

流程为：

双方确定好算法的公共参数G，P
服务端生成随机私钥a，算出公钥A （G ^ a % P）。客户端生成随机私钥b，算出公钥B （G ^ b % P）
双方交换公钥，服务端计算B ^ a % P，客户端计算A ^ b % P，由上述结论可知二者相等，实现了共享密钥

此过程双方的私钥都是随机、临时生成的，不公开的
总结：双方约定公共参数，然后各自生成临时的公私钥对，双方交换公钥。于是可以用各自的私钥和对方的公钥，算出共享密钥

二、TLS1.2 握手消息简介

总体流程如下图所示：

1、客户端发送

ClientHello
用于初始化会话消息，该消息主要包含如下信息：
- Version Number: 客户端发送它所支持的最高 SSL/TLS 版本
- Randomly Generated Data：一个 32 字节的客户端随机数，该随机数被服务端生成通信用的对称密钥（master secret）
- Session Identification ：session ID 被客户端用于恢复之前的会话
- Cipher Suite: 客户端发送它所支持的加密套件列表

2、服务端发送

ServerHello
该消息主要包含如下信息：
- Version Number：服务端发送双发所支持的最高的 SSL/TLS 版本
- Randomly Generated Data：一个 32 字节的服务端随机数，被客户端用于生成通信用的对称密钥（master secret）
- Session Identification：用于会话恢复
- Cipher Suite: 服务端发送双发支持的最安全的加密套件
ServerCertificate：服务端下发SSL证书，客户端用该证书验证服务端的身份
ServerKeyExchange：这个消息是可选的，该消息主要用来传递双方协商密钥的参数
ClientCertificateRequest：这个消息也是可选的，只有当服务端也需要验证客户端身份会用到
ServerHelloDone：告知客户端服务端这边握手相关的消息发送完毕，等待客户端响应

3、客户端发送

ClientCertificate：如果服务端发送了ClientCertificateRequest消息，那么客户端会发送该消息给服务端，包含自己的证书信息，供服务端进行客户端身份认证
ClientKeyExchange：根据协商的密钥算法不同，该消息的内容会不同，该消息主要包含密钥协商的参数
CertificateVerify：该消息只有在ClientCertificate消息发送时才发送。客户端通过自己的私钥签名从开始到现在的所有发送过的消息，然后服务端会用客户端的公钥验证这个签名
ChangeCipherSpec：通知对方此消息以后会以之前协商的密钥加密发送数据
Finished：客户端计算生成对称密钥，然后使用该对称密钥加密之前所有收发握手消息的 Hash 值，发送给服务器，服务器将用相同的会话密钥（使用相同方法生成）解密此消息，校验其中的Hash 值。该消息是 SSL 握手协议记录层加密的第一条消息

4、服务端发送

ChangeCipherSpec：通知对方此消息以后会以之前协商的密钥加密发送数据
Finished：服务器使用对称密钥加密（生成方式与客户端相同）之前所发送的所有握手消息的hash值，发送给客户端去校验

三、TLS1.2 RSA流程

客户端向服务器发送随机数client random，TLS版本，支持的加密套件列表
服务器响应随机数server random，确认好双方都支持的加密套件。同时下发服务器证书
客户端证书验证通过后，生成另一个随机数premaster secret，通过服务器证书公钥加密，传给服务器
服务器用私钥解密，获取到premaster secret

至此，客户端和服务器都有3个相同的凭证：client_random，server_random，premaster_secret，两者使用约定好的算法，通过这3个随机数生成最终的密钥，之后数据传输就通过该密钥加密

四、TLS1.2 ECDHE流程

客户端向服务器发送随机数client random，TLS版本，支持的加密套件列表
服务器响应随机数server random，确认好双方都支持的加密套件，同时下发服务器证书。同时会生成随机数作为私钥，保留在本地。公开DH算法的参数，根据DH算法参数和临时生成的私钥，算出公钥，下发给客户端。为了保证不被篡改，同时会生成签名下发给客户端
客户端验证通过后，生成自己私钥，然后根据服务器公开的DH算法参数，算出公钥，发送给服务器
服务器得到客户端的临时公钥

至此，对方的公钥，自己的私钥，DH算法的公共参数都已经得到，即可算出共享密钥。最终的加密密钥，通过client_random，server_random，共享密钥，3者一起确定

五、TLS1.2和TLS1.3区别

5.1 更快的访问速度

使用 TLS 1.2 需要两次往返（ 2-RTT ）才能完成握手，然后才能发送请求。
TLS 1.3 的握手不再支持静态的 RSA 密钥交换，这意味着必须使用带有前向安全的 Diffie-Hellman 进行全面握手。使用 TLS 1.3 协议只需要一次往返（ 1-RTT ）就可以完成握手。如下图所示：
TLS1.3握手
客户端发送Client Hello时，附带了DH算法的公共参数和公钥，服务器返回Server Hello时，附带了DH算法生成的服务器公钥，即一次传输就完成了密钥交换

5.2 更强的安全性

TLS 1.3 在之前版本的基础上删除了那些不安全的加密算法，这些加密算法包括：

RSA 密钥传输 —— 不支持前向安全性
CBC 模式密码 —— 易受 BEAST 和 Lucky 13 攻击
RC4 流密码 —— 在 HTTPS 中使用并不安全
SHA-1 哈希函数 —— 建议以 SHA-2 取而代之
任意 Diffie-Hellman 组—— CVE-2016-0701 漏洞
输出密码 —— 易受 FREAK 和 LogJam 攻击

六、wareshark抓包验证TLS1.2流程

6.1 搭建https server（springboot）

生成自签名证书
使用jdk的keytool生成证书

keytool -genkey -alias wxl -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore wxl-ssl-key.p12 -validity 3650

-genkey：表示要创建一个新的密钥
-alias：keystore别名
-keyalg：加密算法
-keysize：密钥长度
-storetype：密钥类型
-keystore：文件存放位置
-validity：密钥有效期，单位为天

springboot配置https

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:wxl-ssl-key.p12
    key-store-password: 123456
    key-store-type: PKCS12
    enabled-protocols:
      - TLSv1.2

enabled-protocols表示支持启用的TLS版本，这里配置仅TLS1.2