文章目录
首先放一张整个流程的截图
SSL/TLS握手是为了安全的协商出一份对称加密的密钥，过程如下
上图可以大概描述整个握手过程
Client Hello
握手的第一步是客户端向服务端发送Client Hello消息，内容如下：
- 客户端支持的最高版本号
- 一个用于生成主密钥的32字节随机数（28字节随机数+4字节时间戳）
- 会话ID（SeesionID）
- 密码套件(Cipher Suit)
- 压缩方法
Server Hello
第二步是服务端向客户端发送 Server Hello 消息，这个消息根据客户端的Client Hello选择合适的加密套件、压缩算法等，具体如下：
- SSL版本号，取客户端、服务端支持的最高版本的协议版本中相对低的那一个
- 一个用于生成主密钥的32字节随机数（28字节随机数+4字节时间戳）
- 会话ID（SeessionID）
- 从客户端的密码套件中选择一个
- 从压缩算法中选择一个
Certificate, Server Key Exchange, Certificate Request, Server Hello Done
Certificate
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
Server Key Exchange
这里使用的是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。
Certificate Request
这里是双向认证，服务端也要认证客户端的身份，所以回向客户端发送证书请求，以验证客户端的身份
Server Hello Done
这里发送一个空包，意思是Server Hello Done
Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
Certicicate
因为是双向认证，服务端要验证客户端的合法性，所以这里客户端需要发送客户端的证书供服务端验证身份
Client Key Exchange
上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。
Certificate Verify
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。
Change Cipher Spec
这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。
Encrypted Handshake Message
这步为止一共产生了三个随机数，这三个随机数可以生成会话密钥，用来加密消息,客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
Change Cipher Spec, Encrypted Handshake Message
Change Cipher Spec
这一步和客户端的Change Cipher Spec作用一样，是告诉客户端，接下来的消息都会经过加密传输，也是一个事件消息
Encrypted Handshake Message
服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。
Application Data
经过上面步骤，已经能够确认双方协商除了一个合法的密钥，接下来传输的消息，都会经过加密之后经过传输层进行传输
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/13177.html
