SSL/TLS概述

标签：解密   域名   href   算法   事先   切换   sage   jpg   访问   

TLS协议分为两层

• 底层(Record Layer)
• 上层(ChangeCipherSpec Protocol<20>, Alert Protocol<21>, Handshake Protocol<22>, Application Data Protocol<23>)

Record Layer处于TLS协议最底层，为TLS协议提供安全可靠的连接，为高层协议提供数据封装，压缩，加密等基本功能支持，指定了数据类型，SSL版本以及数据长度(Byte)。由于TLS版本众多，客户端和服务端协商ssl版本时，存在一定的兼容性，具体参照TLS 兼容性问题。比如当客户端需要兼容ssl老版本服务端时，会把recordLayer的ssl version设置为{03,XX}(即SSL3.0，TLS 1.0，1.1，1.2)中的任意值，通常是客户端支持的最低版本。

Handshake Protocol位于Record Layer之上，为Record Layer的负载，类似TCP层为IP层负载。HandShake Protocol层用于传输加密数据前，客户端与服务端的握手协商

协商过程

1. 客户端发出请求（Client Hello）

客户端向服务端发送的Client Hello报文中包含以下信息：

(1) Version。支持的协议版本，比如TLS 1.2版

(2) Random。一个客户端生成的随机数，稍后与服务端产生的随机数生成对话密钥(Master Secret)

(3) Cipher Suites。支持的加密方法，比如RSA公钥加密

Cipher Suite格式：认证算法_密钥协商交换算法_加密算法_摘要算法（TLS, ECDHE_RSA, AES_256_GCM, SHA256）

(4) Compression Method。支持的压缩方法，null表示不压缩

(5) Session ID。如果之前连过该服务端，可以复用会话，而无需重新进行TLS握手

(6) Extension。server_name(请求的服务端域名)，sinature_algorithms等

2. 服务端回应

从Server Hello到Server Hello Done，有些服务端是每条单独发送，有的服务端是合并一起发送。

2.1 Server Hello

(1) Version。服务端确认使用的SSL版本，比如TLS 1.2版本。如果浏览器与服务器支持的版本不一致，会进行协商双方都兼容的版本，如果没有则关闭连接。TLS 兼容性问题

(2) Random。一个服务端生成的随机数，稍后用于生成对话密钥

(3) Cipher Suite。服务端从client hello提供的Cipher Suites列表中选取要使用的加密套件

(4) Compression Method。服务端从client hello提供的Compression Method列表中选取要使用的压缩方法

(5) Session ID。若服务端允许客户端在以后通信中重用本次会话，则服务端会为本次会话分配Session ID

(6) Extension。

2.2 Certificate

服务端在收到客户端的Client Hello之后，将服务端的X.509证书发送给客户端，最下层证书在前（用户证书在前，上级证书在后）。发送的证书是二进制格式，并非base64之后的格式。

2.3 Server key Exchange(可选)

DHE_DSS,DHE_RSA,DH_anon,
对于使用DHE/ECDHE非对称密钥协商算法的SSL握手，将发送该类型握手。
RSA算法不会继续该握手流程（DH、ECDH也不会发送server key exchange）
客户端在收到Server Key Exchange后，首先使用服务端证书中的公钥对签名进行RSA解密并校验散列值。如果解密校验通过，则基于ECDH参数中的Pubkey，通过一定算法算出Pre-Master Secret

2.4 Certificate Request(可选)

对于重要的保密数据，服务端还需要对客户端进行验证，服务端可以向客户端发出Certificate Request消息，要求客户端发送证书进行合法性验证

2.5 Server Hello Done

通知客户端Server Hello消息结束

3. 客户端回应

客户端收到服务端的Server Hello Done后，首先验证服务端证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。

（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。

（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

至于为什么一定要用三个随机数，来生成"会话密钥"

3.1. Certificate(可选)

将客户端证书发送给服务端做合法性校验

3.2. Client Key Exchange

客户端密钥交换并通过随机数生成Master-Key

3.3. Certificate Verify

客户端发送这个类型报文需要满足两个条件：

• 服务端请求了客户端证书
• 客户端发送了非0长度的证书

3.4. Change Cipher Spec

告知服务端，客户端已经切换到协商好的的加密套件（Cipher Suite），表示随后的信息都将用双方商定的加密方法和密钥发送。

3.5 Encrypted Handshake Message

客户端使用协商好的对称密钥进行加密的第一个报文，目的一个是告诉服务端整个握手过程收到了什么数据，发送了什么数据，保证中间没人篡改报文，二是确认密钥的正确性，如果这个报文加解密校验成功，那么对称密钥就是正确的

4. 服务端最后回应

4.1 Change Cipher Spec

编码改变通知，告知客户端，服务端已经切换到选定的加密套件（Cipher Suite），表示随后的信息都将用双方商定的加密方法和密钥发送。

4.2 Encrypted Handshake Message

服务端使用协商好的对称密钥进行加密的第一个报文，目的一个是告诉客户端整个握手过程收到了什么数据，发送了什么数据，保证中间没人篡改报文，二是确认密钥的正确性，如果这个报文加解密校验成功，那么对称密钥就是正确的

5. Application Data

SSL/TLS概述

标签：解密   域名   href   算法   事先   切换   sage   jpg   访问   

原文地址：https://www.cnblogs.com/eightzero/p/9452516.html