TLS通讯过程

TLS通讯过程

握手与密钥协商过程

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

sequenceDiagram
client->>server: client_hello  
server->>client: server_hello
client->>client: 证书校验
client->>server: client_key_exchange \n change_cipher_spec \n encrypted_handshake_message
server->>client: change_cipher_spec \n 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

1. client_hello
   

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

1. server_hello+server_certificate+server_hello_done
   

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

1. 证书校验
   客户端验证证书的合法性，若是验证经过才会进行后续的通讯，不然根据错误状况作出不一样提示和操做，合法性验证包括以下：
   

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

1. 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与算法进行加密，而后发送给服务器用于数据与握手验证；

1. 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与算法加密并发送到客户端；

1. 握手结束
   客户端计算全部接收信息的hash值，并采用协商密钥解密encrypted_handshake_message,验证服务器发送的数据和密钥，验证经过则握手完成；

2. 加密通讯
   开始使用协商密钥与算法进行加密通讯。

   会话缓存握手过程

   为了加快创建握手的速度，减小协议带来的性能下降和资源消耗，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 \n change_cipher_spec \n encrypted_handshake_message
client->>server: change_cipher_spec \n encrypted_handshake_message
loop 应用程序数据
client->server: application data
end

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

1. 会话标识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信息；
  
• 服务器验证数据经过，则握手创建成功，开始进行正常的加密数据通讯；

1. 会话记录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，三个参数做为密钥协商的基础。
  

1. 计算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三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能彻底不随机，但是三个伪随机数就十分接近随机数了，每增长一个自由度，随机性增长的不止一。
  

1. 密钥使用
   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用于数据的完整性校验；

1. 数据加密通讯过程
   

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

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