TLS通信过程

握手与密钥协商过程

基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程

sequenceDiagram
client->>server: client_hello  
server->>client: server_hello
client->>client: 证书校验
client->>server: client_key_exchange 
 change_cipher_spec 
 encrypted_handshake_message
server->>client: change_cipher_spec 
 encrypted_handshake_message 
loop application data  
client->server: application data
end

client_hello
version
cipher suites
compression methods
random_C
extensions

server_hello
version
cipher suite
compression method
random_S
extensions

证书校验
trusted CA
revocation
date
domain

client_key_exchange
Pre-master

时序图

sequenceDiagram
client->>server: client hello(随机数，支持的加密算法)
server->>client: server hello(随机数，选择一个client支持的算法)
server->>client: server 证书
client->>client: 验证证书
client->>server: client key exchange(用server公钥加密pre-master key)
client->>server: change cipher sped(通知server参数协商完成)  
client->>server: finsh hand shake(encrypt handshake message)
server->>client: cipher spec + finsh handshake

client_hello

客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
支持的最高TSL协议版本version，从低到高依次SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于TLSv1的版本；
客户端支持的加密套件cipher suites列表，每个加密套件对应前面TLS原理中的四个功能的组合：认证算法(身份验证)、密钥交换算法KeyExchange(密钥协商)、对称加密算法Enc(信息加密)和信息摘要Mac(完整性校验)；
支持的压缩算法compression methods列表，用于后续的信息压缩传输；
随机数random_C，用于后续的密钥的生成；
扩展字段extensions,支持协议与算法相关参数以及其它辅助信息等，常见的SNI就属于扩展字段。

server_hello+server_certificate+server_hello_done

server_hello,服务端返回墒的信息结果，包括选择使用的协议版本version,选择的加密套件cipher suite,选择的压缩算法compression method、随机数random_S等，其中随机数用于后续的密钥协商；
server_certificates,服务器端配置对应的证书链，用于身份认证与密钥交换；
server_hello_done,通知客户端server_hello信息发送结束；

证书校验
客户端验证证书的合法性，如果验证通过才会进行后续的通信，否则根据错误情况做出不同提示和操作，合法性验证包括如下：

证书链的可信性trusted catificate path；
证书是否吊销revocation,有两类方式离线CRL与在线OCSP，不同的客户端行为会不同；
有效期expiry date,证书是否在有效时间范围；
域名domain,核查证书域名是否与当前的访问域名匹配，匹配规则后续分析；

client_key_exchange+change_cipher_spec+encrypted_handshake_message

client_key_exchange，合法性校验通过之后，客户端计算产生随机数字Pre-master，并用证书公钥加密，发送给服务器；
此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数random_C和random_S与自己计算产生的Pre-master，计算得到协商密钥；
enc_key=Fuc(random_C,random_S,Pre-Master)
change_cipher_spec,客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信；
encrypted_handshake_message,结合之前所有通信参数的hash值与其它相关信息生成一段数据，采用协商密钥session secret与算法进行加密，然后发送给服务器用于数据与握手验证；

change_cipher_spec+encrypted_handshake_message

服务器用私钥解密加密的Pre-master数据，基于之前交换的两个明文随机数random_C和random_S，计算得到协商密钥：enc_key=Fuc(random_C,random_S,Pre-Master)；
计算之前所有接收信息的hash值，然后解密客户端发送的encrypted_hadshake_message，验证数据和密钥的正确性；
change_cipher_spec，验证通过之后，服务器同样发送change_cipher_spec以告知客户端后续的通信都采用协商的密钥与算法进行通信；
encrypted_handshake_message,服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥session secret与算法加密并发送到客户端；

握手结束
客户端计算所有接收信息的hash值，并采用协商密钥解密encrypted_handshake_message,验证服务器发送的数据和密钥，验证通过则握手完成；
加密通信
开始使用协商密钥与算法进行加密通信。

会话缓存握手过程

为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS协议有两类会话缓存机制：会话标识session ID与会话记录session ticket。
session ID由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx中1M内存约可以保存4000个session ID机器相关信息，战用服务器资源较多；
session ticket需要服务器和客户端都支持，属于一个扩展字段，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，战胜服务资源很少。
二者对比，主要是保存协议信息的位置与方式不同，类似与http的sessin与cookie。
二者都存在的情况下,(nginx实现)优先使用session_ticket。
握手过程如下图：

sequenceDiagram
client->server: full handshake
client->>server: client_hello
server->>client: server_hello 
 change_cipher_spec 
 encrypted_handshake_message
client->>server: change_cipher_spec 
 encrypted_handshake_message
loop 应用程序数据
client->server: application data
end

client_hello
version
cipher suites
compression methods
random_C
extensions
Session ID
(session ticket)

会话标识session ID

如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回session ID，并保存对应的通信参数在服务器中；
如果客户端再次需要和该服务器建立连接，则在client_hello中session ID中携带记录的信息，发送给服务器；
服务器根据收到的session ID检索缓存记录，如果没有检索到缓存过期，则按正常的握手过程进行；
如果检索到对应的缓存记录，则返回change_cipher_spec与encrypted_handshake_message信息，两个信息作用类似，encrypted_handshake_message是到当前的通信参数与master_secret的hash值；
如果客户端能够验证通过服务器加密数据，则客户端同样发送change_cipher_spec与encrypted_handshake_message信息；
服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信；

会话记录session ticket

如果客户端和服务器之间曾经建立了连接，服务器会在new_session_ticket数据中携带加密的session_ticket信息，客户端保存；
如果客户端再次需要和该服务器建立连接，则在client_hello中扩展字段session_ticket中携带加密信息，一起发送给服务器；
服务器解密session_ticket数据，如果能够解密失败，则按照正常的握手过程进行；
如果解密成功，则返回change_cipher_spec与encrypted_handshake_message信息，两个信息作用与session ID中类似；
如果客户端能够验证通过服务器加密数据，则客户端同样发送change_cipher_spec与encrypted_handshake_message信息；
服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信；

重建连接

重建连接renegotiation即放弃正在使用的TLS连接，重新进行身份认证和密钥协商过程，特点是不需要断开当前的数据传输就可以重新身份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程，当前windows 2000和XP与SSL 2.0不支持。

服务器重建连接

sequenceDiagram
client->server: full handshake
loop 应用程序数据
client->server: application data
end
client->>server: access protected data
server->>client: hello_request 
client->server: full handshake
loop 应用程序数据
client->server: application data
end

服务器端重建连接一般情况是客户端访问受保护的数据时发生。基本过程如下：

客户端和服务器之间建立了有效TLS连接并通信；
客户端访问受保护的信息；
服务器端返回hello_request信息；
客户端收到hello_request信息之后发送client_hello信息，开始重新建立连接。

客户端重建连接

sequenceDiagram
client->server: full handshake
loop 应用程序数据
client->server: application data
end
client->>server: client_hello
server-->>client: application data
server->>client: server_hello
client->server: next handshake processes
client->server: application data

客户端重建连接一般是为了更新通信密钥。

客户端和服务器之间建立了有效TLS连接并通信；
客户端需要更新密钥，主动发出client_hello信息；
服务器端收到client_hello信息之后无法立即识别出该信息非应用数据，因此会提交给下一步处理，处理完之后会返回通知该信息为要求重建连接；
在确定重建连接之前，服务器不会立即停止向客户端发送数据，可能恰好同时有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器；
服务器识别出重建连接请求之后，发送server_hello信息至客户端；
客户端也同样无法立即判断出该信息非应用数据，同样提交给下一步处理，处理之后会返回通知该信息为要求重建连接；
客户端和服务器开始新的重建连接的过程。

密钥计算

上节提取两个明文传输的随机数random_C和random_S与通过加密在服务器和客户端之间交换的Pre-master，三个参数作为密钥协商的基础。

计算key
涉及参数random client和random server,Pre-master,Master secret ,key material,计算密钥时，服务器和客户端都具有这些基本信息，计算流程如下：

graph TB
RSA/Diffie-Hellman-->Pre-master
Pre-master-->MasterSecret
MasterSecret-->keyMaterial
RandomClient-->MasterSecret
RandomServer-->MasterSecret

客户端采用RS或Diffie-Hellman等加密算法生成Pre-master;
Pre-master结合random client和random server两个随机数通过PsedoRandomFunction(PRF)计算得到Master secret;
Master secret结合random client和random server两个随机数通过迭代计算得到key material;
PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来握手数据的版本号，因为在Client Hello阶段客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者可能篡改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解，所以服务端需要对密文中解密出来的PreMaster版本号跟之前 Client Hello阶段的版本号进行对比，如果版本号变低，则说明被篡改，则立即停止发送任何消息。
不管是客户端还是服务器，都要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十人有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RS密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不任何每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机数，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机数就十分接近随机数了，每增加一个自由度，随机性增加的不止一。

密钥使用
Key经过12轮迭代计算会获取到12个hash值，分组成为6个元素，列表如下：

client Mac key
server Mac key
client encryption key
server encryption key
client IV
server IV

mac key、encryption key、和IV是一组加密元素，分别被客户端和服务器使用，但是这两组元素都被两边同时获取；
客户端使用client组元素加密数据，服务器使用client元素解密，服务器使用server元素加密，client使用server元素解密；
双向通信的不同方向使用的密钥不同，破解通信至少需要破解两次；
encryption key用于对称加密数据；
IV作为很多加密算法的初始化向量使用，具体可以研究对称加密算法；
Mac key用于数据的完整性校验；

数据加密通信过程

对应用层数据进行分片成合适的block；
为分片数据编号，防止重放攻击；
使用协商的压缩算法压缩数据；
计算MAC值和压缩数据组成传输数据；
使用client encryption key加密数据，发送给服务器server；
server收到数据之后使用client encryption key密钥，校验数据，解压缩数据，重新组装。

参考链接：https://www.cnblogs.com/huanxiyun/articles/6554085.html