倒推法理解Https

对称加密

密钥同时扮演加密和解密的角色，只要这个密钥不公开给第三者，对称加密足够安全

对称加密

通义解释：电动车的U型锁，锁车时必须用钥匙上锁，这相当于是一个加密的过程；解锁时也必须用钥匙去开锁，这相当于是解密的过程；钥匙等同于密钥，在加密、解密中都需要用到。

非对称加密

一对钥匙，私钥只有一个人有，公钥可以发给任何人。私钥加密后的密文，只要是公钥，都可以解密；但是公钥加密后的密文，只有私钥可以解密

非对称加密

通义解释：任何一个三位数乘以1001，结果的末三位仍不变。 1001=91*11，可以把三位数当成需传递的信息，把91当成公钥，11当成密钥，传递信息时用公钥（91）加密（三位数乘以91），收到消息后用私钥（11）解密（再乘以11，结果的末三位就是要传递的三位数），完成非对称加密

HTTPS原理

Q：要保证通信的安全
A： 可以采用对称加密或非对称加密两种方式进行数据传输，两种方式的区别是：
1、对称加密需要保证加解密的密钥不被窃取和篡改；
2、非对称加密可以完成通信的加密，但是通信速度过慢
综上所述，我们还是采取对称加密的加密算法

Q：采取对称加密的算法，需要保证密钥不被窃取和篡改，这个密钥该如何去传输？

密钥s该如何传递

A： 采取非对称加密的方法，客户端拥有服务器公钥，用服务器公钥加密对称加密的密钥，然后服务器再用其私钥解密出来

A、B向服务器端是安全的

Q：客户端如何获取服务器的公钥（服务器的公钥如何传递给客户端）？如果服务器直接传递公钥给客户端，很容易被中间人窃取、篡改！

篡改公钥

A： 貌似进入了一个鸡生蛋、蛋生鸡的问题，如果我们选择直接将公钥传递给客户端的方案，我们始终无法解决公钥传递被中间人调包的问题，这其实就是密码学中的身份认证。
  要解决身份认证的问题，必须引入一个有公信力的第三方机构做信用背书，服务器将它的公钥托管给第三方机构，第三方机构将服务器的信息、服务器公钥等信息合成一张数字证书，并且用第三方机构的私钥加密。当客户端请求服务器的公钥时，服务器就将第三方机构颁发的数字证书发给客户端，客户端用第三方机构的公钥去解密数字证书，获取公钥。

数字证书传递

  只要客户端的公钥能够解密传递过来的数字证书，就说明数字证书没有被篡改，因为数字证书是通过第三方机构的私钥加密的，如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。
  这里解释一个小的疑问：客户端如何获取第三方机构的公钥？现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。

Q：数字证书在传递的过程中，还是可以被篡改的，如果黑客也去第三方机构申请一张自己的数字证书，然后将客户端与服务器之间传递的数字证书替换成自己申请的证书，客户端还是可以用第三方机构的公钥解密的？

证书篡改

A： 要辨别同一机构下不同的证书，只能交给客户端自己去辨别了。第三方机构在生成证书时，还会新生成一个数字签名，至此证书主要包含服务器信息、服务器公钥、加密算法、数字签名。数字签名是将证书的内容，用一定的加密算法（如：MD5）生成的一串编号，然后第三方机构再用自己的私钥去加密这串编号，这样数字签名也不会被篡改了。

证书内容

  客户端接收到数字证书之后，会用证书中的加密方法去加密服务器信息，然后用第三方机构的公钥解密数字签名（证书编号），比对解密出来的编号和自己生成的编号，即可判断证书的真伪。

证书辨别真伪

Q：感觉数字签名没有起到作用，因为数字证书 = 数字签名 + 证书内容，由于数字证书里面的证书内容和数字签名是一套的（证书内容生成数字签名），即使中间人换成自己的数字证书，那也是根据中间人证书内容生成的数字签名，客户端也分辨不出来？
A： 猜测生成数字签名的方法是：证书内容 + 访问的服务器IP（客户端可知）。客户端拿到证书之后，将证书内容和DNS解析出来的IP，去生成数字签名，再进行比对。如果中间人换成了自己的证书， 客户端拿到之后，结合请求的IP，数字签名比对是通过不了的。另外就算中间人知道真实请求的服务器IP，那也不可能篡改数字签名，因为数字签名必须得由第三方认证机构的私钥加密。
   其实只要在生成证书的时候，加上一个真实服务器独有的信息，这样黑客的那一套数字签名只符合自己的服务器，证书是不能被篡改的

参考博客

也许，这样理解HTTPS更容易
一个故事讲完HTTPS