HTTPS如何保证数据传输过程中的安全性？

就是在三次握手的基础上加了一个ssl/tls安全检验

这是个对称+非对称加密结合的混合加密算法

首先考虑一个最简单的加密算法 对称加密

即客户端和服务端都用同一个秘钥对数据进行加密，这个秘钥由服务端保管，由服务端发送给客户端，或者在握手过程中生成，然后客户端和服务端的双工通信都用这个秘钥进行加密和解密，使得http不再使用明文传输

但是问题的关键在于 怎么告诉客户端这个秘钥

明文传输？ 那非常容易被中间人获取到，并且窃取我们的数据或者发送一些不安全的数据

所以单单是对称加密肯定是不行的

所以引入了非对称加密

在非对称加密的算法中，一共有一公一私两队秘钥，假如有数据A 则可以用公钥加密为数据B

若是要解密必须要用私钥，若是没有私钥，无法解密出数据！

服务端给客户端的只有公钥，私钥保存在自己这边，客户端发送数据时用公钥加密，到客户端这边再用私钥解密，这样就安全许多

但是仅仅这样的还可能被中间人攻击

中间人拦截公钥，把公钥替换成自己的，这样客户端用这个公钥加密 很容易就被中间人破译出来 这样的话就裸奔了,

而且我疑惑的是，这样确实客户端可以向服务器发数据了 但是服务器怎么想客户端发数据呢？客户端又没有私钥，也许客户端也可以搞一个自己的私钥+公钥

总的来说无论如何都要把公钥明文传输，这样就给了中间人可乘之机，所以非对称加密也并非完全安全

终极方案:对称加密+非对称加密

核心是使用非对称加密的方式传输"公钥”， 客户端生成一个随机数，用服务端传过来的公钥加密后传给服务端，服务端收到后用自己的私钥解密，这样两边就都获得了这个最终的对称加密的公钥，而中间人即使拿到了加密后的数据，没有私钥也无法解密

那还是有一个问题，如何确定这个公钥确确实实是服务端发过来的，而非中间人

所以数字证书就派上用场了，服务器并非直接发公钥，而是发一个数字证书，这个证书是经过权威机构(CA)认证的,而且客户端也可以检验这个证书是真是假，是真之后才进行通信

最后还有一个问题，就是数据篡改和完整性问题

这是通过数字签名+摘要算法实现的，简单说就是每次加密消息都有一个消息认证码，是通过秘钥+消息内容计算出来的哈希值，服务端收到后在计算一次，不一致则丢弃