用十个问题归纳Https通讯机制

前言

以前一直对Https方面的知识似懂非懂，这两天抽空进行了一次较深刻的学习，为了加深巩固，特地总结出一些问题，已验证是否真正理解，文中若有错误，欢迎指正~

问题

1.Http有哪些缺点？

1. 通讯使用明文传输，不加密，可能被监听
2. 没法验证通讯方的身份（Http不具有验证机制），可能伪造
3. 内容完整性没法保证，可能被篡改

2.如何解决明文传输问题？

加密，对通讯加密（TLS）、对内容加密（SSL）

3.如何验证通讯方身份？

采用认证机制，经过验证通讯方的证书来确认身份，证书由可信任的第三方数字证书机构签发

4.如何保证内容完整性？

通讯和内容获得了加密，而且加密所用的密钥是安全不泄露的，那么就能保证内容的完整性，由于其余人没法解密

5.内容加密都有哪些加密方式？

1. 共享密钥加密，又称对称密钥加密，加解密使用同一个密钥，而且密钥采用明文方式跟随内容传输，因此很容易被中间人获取，从而破解内容，安全性较低，可是处理速度快，效率高
2. 公开密钥加密，又称非对称密钥加密，一对密钥（公钥&私钥），使用私钥加密的内容，只有公钥才能解密，反之亦然；公钥能够给任何人，私钥由服务端本身保存好；虽然安全性较高，但处理速度慢，效率低，并且公钥使用明文传输，容易被中间人获取并篡改，也就是所谓的*”中间人攻击“*。

6.Https采用哪一种加密方式？

混合加密方式：先使用公开密钥加密方式来传递公钥，公钥加密生成密钥，而后再使用这个密钥以共享密钥加密的方式进行后续的内容传输。那么这种所谓的混合加密方式安全吗？答案是：不安全，容易遭到中间人攻击。

7.何为中间人攻击？

中间人攻击，即客户端与服务端通讯时，中间的代理服务器、运营商、网关等都有可能对通讯进行监听、拦截和篡改，具体过程大体以下：

1. 客户端向服务端发起创建安全通讯的请求
2. 服务端将公钥以明文方式发送给客户端
3. 中间人将公钥保存下来，并生成一个假的公钥给客户端
4. 客户端使用假的公钥生成随机数发送给服务端
5. 中间人使用假的公钥解密获得随机数，而后再生成一个假的随机数，并使用那个真的服务端公钥加密，而后发送给服务端，使用真的公钥加密假的随机数目的是确保服务端可以用私钥解密，不然服务端会解密失败
6. 服务端使用私钥解密获得随机数，并用这个随机数推导出密钥，推到方式是公开的，也就是说只要有了随机数也就有了密钥，那么此时除了客户端、服务端有这个随机数，中间人也有，因此在后续的通讯中，中间人就能够拿这个密钥解密数据包，从而篡改内容

归纳起来就是：中间人用假公钥替换了服务端发送给客户端的真公钥，致使客户端使用假的公钥加密随机数并发给服务端，中间人从中解密获得随机数，这样就能推导出后续加密数据包所用到的密钥，以后客户端与服务端的通讯就再无秘密可言

8.如何防止中间人攻击？

其实只要在服务端发送公钥这个阶段，公钥不被中间人获取篡改，那么问题就解决了，因此如何才能保证公钥不被中间人获取呢，方法就是用数字证书对公钥进行加密

9.证书如何加密公钥？以及如何证实证书不是伪造的？

首先，颁发数字证书的是可信任的第三方机构（简称CA），这是前提；服务端得到的证书包含服务端本身的公钥，而且是用CA的私钥加密过的，这个证书只能由CA的公钥进行解密验证。

目前市场上的浏览器都会事先内置一些CA的公钥，目的就是避免公钥在传输过程当中泄露，因此与其就不传输，直接内置

当浏览器接收到服务端的证书时，先进行验证，而不是直接使用；浏览器使用CA的公钥验证证书是否有效，若是验证经过，就证实证书中的公钥也是真实有效的，而后就可使用这个公钥了；在这个过程当中，中间人没法解密（由于CA的公钥是内置在浏览器中的，并无在通讯中携带），也就没法获得公钥，进而即便生成假公钥也是多余的，由于即便生成了，给到客户端也是验证不经过的

10.还有哪些要补充的？

1. 服务端也能够要求验证客户端的证书，可是客户端要想获得证书，须要付费购买，而且要求每一个用户都安装，这是不现实的，存在学习成本
2. 生成共享密钥加密方式使用的密钥时，不管是采用DH算法，仍是RSA算法，目的都只有一个，那就是生成复杂的安全性高的密钥

参考

1. 《图解Http》第7章：确保Web安全的Https
2. HTTPS能够防止中间人篡改内容吗？ - 知乎

原文地址：guoyunfeng.com/2019/08/22/…