问题缘由
有一天我正在兴致勃勃的上网冲浪，突然我的好朋友给我发了一个网址abcd.com，并告诉我这是他发现的好看的东西。我迫不及待地复制粘贴到我的浏览器里，但不幸的是，浏览器当场给我打开失败了。不死心的我去问朋友这是怎么回事，他告诉我说复制粘贴时在前面加上http试试，我如法炮制，但依旧不太行，随后朋友又和我说那就试试加入https，发现居然成了！这不由引起了我深深的沉思：https到底是个什么东西？它是怎样发挥作用的？
其实本质上https是一种加密协议，为了理解它我们需要一步步先去理解一些小的问题。
✦
✦ 我们之所以需要加密，是因为http的内容是明文传输的，在互联网上的信息交换是公开的，这就意味着在你的信息从你的计算机传送到服务器的过程中可能被其他人截取。如果这些信息是敏感的，例如你的密码、信用卡号等私人信息，那么就可能会被恶意使用。 为了保护这些信息的安全，我们就需要对其进行加密处理。这就是我们需要HTTPS加密的原因。其中最容易理解的是对称加密。
✦ 对称加密是一种常见的加密方法，其原理是使用同一个密钥进行数据的加密和解密。这种加密方法的优点是加密和解密的速度都很快，适用于大量数据的加密。 ✦ 如果通信双方都各自持有同一个密钥，且没有别人知道，如果这个密钥没有被破解，这两方的通信安全当然是可以被保证的。 然而最大的问题：就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手之后，他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。 换种思路，试想一下，如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行了！这么做显然也不现实。 怎么办？所以我们就需要非对称加密。
✦ 非对称加密是一种加密方法，它使用两个密钥：公钥和私钥。公钥是公开的，任何人都可以使用公钥来加密信息，但只有使用与之配对的私钥才能解密。这样，即使别人知道公钥，也无法解密信息。 简单来说就是有两把钥匙，我们常常把一把叫做私钥一把叫做公钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
✦ 使用非对称加密技术是可以的，它解决了对称加密中密钥传输的问题。在HTTPS通信中，服务器将其公钥发送给浏览器，浏览器使用这个公钥加密信息，然后发送给服务器，服务器再用自己的私钥解密。但是，反过来由服务器到浏览器的这条路怎么保障安全呢？ 如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性。
✦ 我们已经理解通过一组公钥私钥，可以保证单个方向传输的安全性，那用两组公钥私钥，是否就能保证双向传输都安全了？请看下面的过程： 1.某网站服务器拥有公钥A与对应的私钥Aʼ；浏览器拥有公钥B与对应的私钥Bʼ。 2.浏览器把公钥B明文传输给服务器。 3.服务器把公钥A明文给传输浏览器。 4.之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥Aʼ解密。由于只有服务器拥有私钥Aʼ，所以能保证这条数据的安全。 5.同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后用私钥Bʼ解密。同上也可以保证这条数据的安全。 这样的确可以！抛开这里面仍有的漏洞不谈，HTTPS的加密却没使用这种方案，为什么？很重要的原因是非对称加密算法非常耗时，而对称加密快很多。那我们能不能运用非对称加密的特性解决前面提到的对称加密的漏洞？
✦ 既然非对称加密耗时，那非对称加密+对称加密结合可以吗？而且得尽量减少非对称加密的次数。 当然是可以的，且非对称加密、解密各只需用一次即可。 请看一下这个过程： 1.某网站拥有用于非对称加密的公钥A、私钥Aʼ； 2.浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器； 3.浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器； 4.服务器拿到后用私钥Aʼ解密得到密钥X； 5.这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。 HTTPS协议就是这样做的。在HTTPS握手阶段，浏览器和服务器采用非对称加密来交换一个对称加密的密钥，然后在实际的数据传输过程中使用这个对称加密的密钥来进行加密和解密，样既保证了数据传输的安全性，又大大提高了加密和解密的效率。 这样就完美了？其实还是有漏洞的——
✦ 请看，如果出现了下面的过程： 1.某网站有用于非对称加密的公钥A、私钥Aʼ； 2.浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器； 3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥Bʼ) ； 4.浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器； 5.中间人劫持后用私钥Bʼ解密得到密钥X，再用公钥A加密后传给服务器； 6.服务器拿到后用私钥Aʼ解密得到密钥X。 在上面非对称加上对称加密方案的过程中，虽然我们已经保证了数据传输的安全性 ，但还存在一个问题，那就是中间人攻击。所谓中间人攻击，就是攻击者插入到通信双方之间，截取双方的通信内容，然后将修改过的信息传送给接收方。而由于HTTPS协议的公钥是明文传输的，攻击者可以在服务器传输公钥到浏览器的过程中，将公钥替换为自己的公钥，这样就可以截取并修改通信内容了，这样子中间人却完全不需要拿到私钥Aʼ就能干坏事了。 那么，我们如何解决这个问题呢？这就需要用到数字证书。
✦ 数字证书是一个由权威的第三方机构颁发的，包含了公钥所有者的一些信息以及该公钥的一个文件。这个权威第三方机构，我们一般称之为CA（Certificate Authority，证书颁发机构）。数字证书里含有证书持有者信息、公钥信息等，当服务器把公钥发送给浏览器时，同时也会发送这个数字证书。证书就如身份证，证明“该公钥对应该网站ˮ, 浏览器会通过数字证书验证公钥的真实性，就像身份证可以表示一个人的身份那样，这样就可以防止中间人攻击了。 而这里又有一个显而易见的问题：“证书本身的传输过程中，如何防止被篡改？ˮ，即“如何证明证书本身的真实性？”。身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！
✦ 数字证书的真实性是由证书颁发机构（CA）来保证的。CA会使用自己的私钥对证书内容进行签名，得到一个签名值，然后把这个签名值附在证书上一起发送给浏览器。当浏览器收到证书后，会用CA的公钥对这个签名值进行解密，得到一个值，然后浏览器自己对证书内容进行一次签名计算，比较这两个值是否相等，来验证证书的真实性。由于CA的私钥只有CA自己知道，所以只有CA才能生成一个能通过验证的签名值，这样就可以保证证书的真实性，防止证书被篡改。 这份“签名”就叫做数字签名。
✦ 数字签名是一种类似于手写签名或者印章的技术，用于鉴别数字信息的真实性。它包含两部分：签名和验证。签名过程是，通过对信息使用私钥进行加密，生成独特的信息摘要，作为签名。验证过程则是，通过使用相应的公钥解密签名，对比信息摘要，以确认信息的完整性和发送者的身份。这样，即使信息在传输过程中被篡改，由于篡改后的摘要和原签名不匹配，也能被接收者发现。 数字签名的制作过程： 1.CA机构拥有非对称加密的私钥和公钥。 2.CA机构对证书明文数据T进行hash。 3.对hash后的值用私钥加密，得到数字签名S。 明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。 那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包） 浏览器验证过程： 1.拿到证书，得到明文T，签名S。 2.用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S’。 3.用证书里指明的hash算法对明文T进行hash得到T’。 4.显然通过以上步骤，T’应当等于S’，除非明文或签名被篡改。所以此时⽐较S’是否等于T’，等于则表明证书可信。
✦ 假设有另⼀个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对⼀下就知道有没有被掉包了。
参考文献 知乎：彻底搞懂HTTPS的加密原理 https://zhuanlan.zhihu.com/p/43789231?utm_medium=social&utm_psn=1768198603011665920&utm_source=qq
原创文章，作者：速盾高防cdn，如若转载，请注明出处：https://www.sudun.com/ask/58705.html
