为了避免这类消息发生，我们需要给摘要也通过会话密钥进行加密，这样就看不到摘要明文信息了，能更好的保证信息的安全性了。
可见，离开了机密性，完整性也就无从说起了。
5.3.5、数字签名到目前为止，我们还有一个问题没有解决，那就是：怎么知道我们要连接的网站不是伪造的呢，如果是伪造的，即使他给了我们他的公钥，也是可以成功进行加解密的，因为他给的公钥给他自己的私钥本身就是一对。
如下图，客户端的请求被中间人截获了，中间人给了客户端自己的公钥，最终客户端把消息发给了中间人，中间人这个时候是可以解密密文拿到原始数据的。然后中间人请求实际的服务器，拿到了实际服务器的公钥，再把消息转发给实际的服务器。这样就窃取了客户端的信息了。
中间人攻击为了避免拿到假的公钥，所以我们需要一个权威机构帮忙验证这个公钥是不是真的。
通过CA机构生成数字证书这个时候我们请来了权威的机构，来帮忙我们生成网站公钥的数字证书：
如上图，服务器和CA机构分别有一对密钥，服务器请求CA机构把服务器公钥生成一个数字证书，生成流程：
CA机构通过摘要算法生成公钥的摘要；
CA机构通过自己的CA私钥以及特定的签名算法加密摘要，生成签名；
把签名、服务器公钥，以及其他基本信息打包放入数字证书中。
最后，CA机构把生成的数字证书返回给服务器。
服务器配置好生成的证书，以后客户端连接服务器，都先把这个证书返回给客户端，让客户端验证并获取服务器的公钥。
服务器公钥验证流程客户端接收到服务器发送的数字证书和CA机构的公钥，通过CA机构的公钥对数字证书上的签名进行验证。
验证过程：
使用CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器公钥的摘要内容；
拿到证书里面的服务器公钥，用摘要算法生成摘要内容，与第一步的结果对比，如果一致，则说该证书就是合法的，里面的公钥是正确的，否则证书就是非法的。
谁来保证CA的公钥的正确性?
服务器验证的时候，需要拿到数字证书发布机构的CA公钥，但是怎么证明这个CA公钥是正确的呢？这个时候就需要有更大的CA帮小的CA的公钥做认证了，一层一层的背书，最顶层的CA，Root CA，称为根证书，作为信任链的根，是全球皆知的的极大著名CA，这些根证书一般会内置到操作系统中。
大家可以到操作系统的证书目录下，或者浏览器，看看证书文件里面都有什么内容。
思考题：
即使证书验证通过了，这样就能够保证安全了么，想想还有没有其他原因导致请求的网站身份不可信的；
有了CA机构，就没法进行中间人攻击了吗？
5.3.6、算法总结我们来总结一下上面提到的各种算法的作用：
签名算法：通过数字证书，和CA公钥，验证获取到的服务器公钥的可靠性，保证了认证性；
密钥交换算法 + 对称加密算法：通过交换的密钥，进行加密通信，保证了机密性和不可否认性；
摘要算法：保证完整性。
本文首次发表于: HTTPS：网络安全攻坚战 以及公众号 Java架构杂谈，未经许可，不得转载。
5.4、HTTPS连接过程HTTS连接访问比HTTP多了一步TLS连接：DNS解析，TCP连接、TLS连接。
最关键的就是TLS连接，这里我们重点来分析。
其中TLS连接认证分为单向认证和双向认证：
单向认证 ：服务器提供证书，客户端验证服务器证书；
双向认证 ：服务器客户端分别提供证书给对方，并互相验证对方的证书。