HTTPS如何保证完整性和真实性？

zijian1984

网络安全三属性：

• 机密性：要加密，不要明文
• 真实性：通信双方身份要确认
• 完整性：通信数据没有被第三方篡改过，即被修改、删除、添加
  

首先为什么不用HTTP？因为他缺少机密性、真实性和完整性。那用HTTPS就完全解决这个问题了吗？我个人不能理解，我觉得HTTPS只是用混合加密实现了机密性，真实性和完整性它是如何保障的呢？在TLS四次握手后，通信的数据会使用对称密钥来加密，这个可以理解，但是只是实现了机密性，也就是不是明文了。但是这个时候要是有第三方截取了请求，然后随便加了点东西进去，然后在模拟成客户端的样子，假装没有被截取过，再发给服务端，服务端是怎么校验数据被篡改过了呢？

---

对于这个目前有两个猜想：1. 对称加密具有完整性性客户端发送的数据如果被截取然后篡改了，那么服务端收到被篡改的消息后，如果使用密钥无法解密，那么说明数据出问题了2. 实际上传输的加密数据里面含有一个消息摘要客户端发送的数据里面，真正形式是——对称加密【真正数据A+消息摘要B】，服务端收到消息后解密后得到数据A和摘要B，然后对数据A进行同样一个散列得到一个摘要C，对B和C进行一个比对，如果一样说明数据没有被篡改过。 学习TLS最权威的文献应该是TLS1.2 (RFC5246)、TLS1.3（RFC8446）。当然带着你的疑问去看这些文献会更有针对性、效率也会更高。这些文献都有100多页，要想将所有知识点浓缩在几千字的文字里是不可能的。但是我还是尽自己最大的可能将关键的知识点罗列出来，最大限度突出数据的完整性与机密性。TLS安全通信，至少需要通信的一方提供合法的数字证书你访问知乎的网站（APP），这就是典型的TLS安全通信。你有证书吗？没有。还能TLS安全通信吗？可以。因为知乎的服务器有合法的证书。什么是合法的证书？知乎服务器TLS安全协商阶段，会甩给你三张证书：

• 知乎服务器的证书，由二傻签名
• 二傻的证书，由大傻签名
• 大傻的证书，由大傻自签名
  

知乎服务器的证书之所以合法，是因为大傻的自签名证书，已经提前预装并信任在你的手机、iPAD、电脑的操作系统里了。证书链的签名关系由于你的电脑终端信任大傻的证书（公钥），间接信任大傻的私钥。那么用大傻的钥签名的任何证书是值得信任的，其中包括用大傻私钥签名的二傻的证书（二傻公钥）、间接信任二傻的私钥。那么二傻私钥签名的证书都是可以信任的，其中包括二傻签名的知乎服务器证书（知乎公钥）。被终端信任的知乎服务器公钥，在接下来安全通信中扮演最最关键的要素，只有充分理解这一点，才能继续阅读下去，否则还是回到开头循环阅读。现在你正准备打开知乎的首页，在TCP完成三次握手，就开始TLS安全协商。你的电脑终端发送了Client Hello，其中包含终端支持的安全组件、Nonce。并请求对方展示证书。问题来了，客户端发送的Client Hello报文，有密钥保护吗？有签名保护吗？都没有！既然没有签名保护，第三方是否有可能篡改？非常有可能！既然有可能被篡改，谈何数据完整性呢？这是一个非常好的问题，但是聪明的TLS专家们，已经提前想好了对策，这个对策就是秋后算总账，这里先不展开。知乎服务器收到Client Hello之后，默认它是没有被篡改的。挑选出客户端、自己都支持的安全组件，其中最最重要的安全组件是密钥交换算法（Key Exchange）、以及数据加密算法（AES）、数据完整性校验算法（HMAC）。知乎服务器密钥交换算法选择的是ECDHE，并动态生成了自己的EC私钥、EC公钥。并将EC公钥、Nonce、以及文章开头三张证书甩给客户端。通过Server Hello报文发出。问题又出现了，客户端收到Server Hello报文，如何确定Server Hello没有被第三方篡改？可以用知乎服务器的私钥加密签名啊。由于客户端信任知乎服务器的公钥，那么就信任知乎私钥签名，任何的篡改都是可以被发现的。可是并不这么实现。因为Server Hello报文通常几千个字节，签名太耗费计算资源了。通常知乎服务器只对最最核心的EC公钥进行签名，使用知乎服务器的私钥签名。为何EC公钥那么重要？因为客户端、服务器，会使用EC公钥来推导Master Session Key。而Master Key被用来推导用于数据加密的Session Key（AES算法）、以及数据完整性HMAC Key。至于其他部分虽然没有使用签名保护，但是一样会秋后算总账，如果有第三方篡改，一样可以被发现。客户端收到服务器的Server Hello报文，通过证书校验，信任为知乎合法证书，并使用证书里的公钥，验证了知乎服务器EC公钥签名没有问题，确实是使用知乎服务器的私钥签名的，这个世界上拥有知乎服务器私钥的，只有知乎服务器本人。客户端动态生成自己的EC公钥、EC私钥，并将EC公钥发送给服务器。至此，客户端已经拥有了以下信息：

• 客户端的EC公钥
• 客户端的EC私钥
• 服务器的EC公钥（有服务器私钥签名保护）
• 客户端Nonce
• 服务器Nonce
  

服务器收到客户端的EC公钥之后，也拥有了以上五元组：

• 服务器的EC公钥
• 服务器的EC私钥
• 客户端的EC公钥
• 客户端Nonce
• 服务器Nonce
  

双方按照事先约定的算法，分别推导出Master Key。如果没有被第三方篡改以上在网络上传输的元素，那么理论上这两个Master Key是一模一样的。验证是不是一模一样，最好的办法就是发送一个测试报文。用什么报文来测试呢？记得上文提到的秋后算总账吧？就是通信双方把此前所有本地发出的、以及从对方收到的所有字节，按照时间的先后次序，放在一起。比如客户端一共发出5000个字节、服务器发出8000字节，那么双方只要将这13000个字节生成一个Hash，然后用Session Key加密发给对方。对方用Session Key解密，得到的明文，其实就是对方计算的Hash值。如果与本地计算的Hash值相同，那么说明两件事：

• 双方的Session Key是一样的，间接说明双方的Master Key是一样的，因为Session Key是由Master Key推导出来的。
• 此前双方的所有交互报文，没有被篡改、删除、添加，否则双方计算的Hash值不可能相等。
  
  

双方Hash值相同，那么一次成功的TLS安全协商就宣告结束了。双方就可以使用Session Key、HMAC Key对数据进行加密/解密操作，以及完整性校验了。由于Session Key、HMAC Key只有通信双方知晓，任何第三方单位或个人都无从解密报文，这就满足了数据的机密性要求。任何第三方的篡改、添加、删除数据的行为，也会被接收方发现，因为第三方没有HMAC Key。一旦发现数据被污染，接收方二话不说，不是将数据一扔了事，而是直接将TLS连接断开。最后一个问题，上文中测试报文，如果双方计算得到的Hash值不相同，会如何处理？很简单，直接将TLS连接断开，压根不会传输任何数据，这样就保护了数据的安全。