GoLang：你真的了解 HTTPS 吗？

在数据通信阶段，SSL/TLS 会对原始消息(message)做一次哈希，得到该消息 message 的摘要，称为消息摘要(Message Digest)。对端接受到消息后，使用协商出来的对称加密密钥解密数据包，得到原始消息 message;接着也做一次相同的哈希算法得到摘要，对比发送过来的消息摘要和计算出的消息摘要是否一致，可以判断通信数据是否被篡改。

五、HTTPS 通信流程

到此，HTTPS 涉及到的关键问题基本都覆盖了。本章总结整个 HTTPS 的通信过程：

补充说明几点：

1. 协商密钥：客户端/服务端随机数、Client/Server Key

在加密一章节介绍的 ECDH 是停留在原理层面，实际中密钥协商除了 PreMaster-Secret(即 Client/Server Key)之外，还有客户端和服务端随机数参与，参考文章《Https：TLS 握手协议》，引用文中的图来自展示实际 ECDH 秘钥协商的做法：

2. Change Cipher Spec

Change Cipher Spec是通知对方需要加密参数。文章《TLSde 改变密码标准协议(Change Cipher Spec Protocol)》指出：

SSL 修改密文协议是使用 SSL 记录协议服务的 SSL 高层协议的 3 个特定协议之一，也是其中最简单的一个。协议由单个消息组成，该消息只包含一个值为 1 的单个字节。该消息的唯一作用就是使未决状态复制为当前状态，更新用于当前连接的密码组。为了保障 SSL 传输过程的安全性，双方应该每隔一段时间改变加密规范。

3. Encrypted Handshake Message

Encrypted Handshake Message作用就是确认协商出来的对称加密密钥 SK 的正确性，在客户端和服务端协商得到对称加密密钥 SK 之后，互相给对方发了一条用 SK 加密的消息，如果这个加密的消息被解密校验成功，那么就说明对称加密密钥 SK 是正确的。

4. 单向验证和双向验证

本章全部所探讨的案例都是基于单向验证，即客户端向服务端请求证书、验证服务端身份。在一些实际场景中，对安全性的要求更高，有服务端要求验证客户端的身份，即双向验证。双向验证在单向验证基础上，增加“在服务端发送证书之后，向客户端发送‘请求证书’请求，接着验证客户端身份”这个步骤。参考下图(图片出处不查)：

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!