https的加解密流程_1

1. https的加解密流程

1.源由

​ 在2021的年底，公司老大悄咪咪的跑到我的身边来给我说，让我对x509证书研究一下，然后再给同事分享一下。我听到后，直接出去点了根宽子，对自己说，搞起，搞起，脑壳莫要打铁。
​ 要了解什么是x509证书，先要了解https的加解密机制，所以直接开干。

2.为什么加密？

​当我们坐在家里，需要通过http访问位于云服务器的web页面，数据需要通过路由器，光猫，ISP，电信等传输介质，如果数据被人劫持，那传输的内容就完全暴露，如果劫持者篡改传输信息而不被双方擦觉，这就是中间人攻击。为了数据传输安全，所以我们需要对数据进行加密。
​

3.加密的基础概念

​ 要弄懂如何加密，就要先弄懂加密的基本概念，比如加密，摘要算法，签名，对称加密，非对称加密。

1.加密

加密，是指对某个内容加密，加密后的内容还可以通过解密进行还原。 比如我们把一封邮件进行加密，加密后的内容在网络上进行传输，接收者在收到后，通过解密可以还原邮件的真实内容。

2.摘要算法

摘要算法又称哈希算法，它是对数据进行hash处理从而获取密文，这个算法是不可逆的，也就是只能根据数据生成密文，无法根据密文反推数据。当输入任意长度的数据，输出固定长度的数据，相同的输入数据始终得到相同的输出，不同的输入数据尽量得到不同的输出。

3.签名

A需要将数据传给B: A先将数据根据摘要算法生成摘要，再将摘要，原文，摘要算法一起发送给B；B接受数据后，再将原文经摘要算法加密后与发送的摘要进行对比，如果一致，则发送的文本数据合法，反之亦然。传输的时候本来只需要传输数据，但为了防止被篡改，需要在原文后面增加摘要和摘要算法，这新增的处理就是签名。这可以有效解决数据不被篡改，但无法解决数据传输层的中间层攻击。

4.对称加密

数据经算法和盐（salt）生成密文，密文也可以通过算法和盐（salt）进行解密。这个过程是可逆的。算法通常是固定的，但盐却不同，盐是一个保存的字符串，当盐被泄漏了，会存在很大的数据泄漏。加密和解密是使用同一套算法和盐。常用的算法有DES、AES等。

5.非对称加密

生成一个密钥对，分别是公钥和私钥，使用私钥对数据进行加密得到密文，再通过公钥对密文进行解密获取数据。也可以通过公钥对数据进行加密，再通过私钥对数据进行解密。常用的算法有RSA、DSA等。

4.探讨可行的加密方式

1.用对称加密可行？

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那在这个传输过程中密钥被别人劫持到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。

2.用非对称加密可行？

鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开公钥加密的数据。然而反过来由服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据的安全性，除此之外，非对称加密算法非常的耗时，而对称加密算法则会快很多。

3.对称加密 + 非对称加密？

• 既然非对称加密非常耗时，那么使用对称加密+非对称加密，减少非对称加密的次数，是否可以解决？

  1. 某网站拥有用于非对称加密的公钥A、私钥A’。
  2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
  3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
  4. 服务器拿到后用私钥A’解密得到密钥X。
  5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。
  

• 完美解决？中间人攻击，如果在数据传输过程中，中间人劫持到了数据，此时他的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开它，然而中间人却完全不需要拿到私钥A’就能干坏事了。请看：

  1. 某网站有用于非对称加密的公钥A、私钥A’。
  2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
  3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
  4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
  5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
  6. 服务器拿到后用私钥A’解密得到密钥X。
  

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是明文传输的，难道还得对公钥的传输进行加密？这似乎变成鸡生蛋、蛋生鸡的问题了。

• 具体办法是什么？

需要证明浏览器收到的公钥一定是该网站的公钥？其实所有证明的源头都来自于一条或多条的不证自明的“公理”，可以回想一下数学公式，比如现实生活中，如何证明某个身份证是张三的？则需要根据身份证进行证明，而身份证是由政府作证，这里的公理就是政府机构可信，同样的道理，如何给网站颁发一个身份证？它就是CA机构，CA机构颁发的身份证就是数字证书。

4. 数字证书

1.证书的内容

证书数据包括服务端的公钥，持有者信息，证书认证机构CA的信息，CA对这份数字签名以及使用的算法。

2.数字证书的制作和校验

• 数字证书的制作过程：

  1. CA机构拥有非对称加密的私钥和公钥。
  2. CA机构对证书数据(证书数据包括服务端的公钥，持有者信息，证书认证机构CA的信息，CA对这份数字签名以及使用的算法)进行hash。
  3. 对hash后的值用CA的私钥加密，得到数字签名证书S。
  

• 浏览器验证数字证书过程

  1. 浏览器拿到证书，得到明文T，签名S。
  2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。），得到S’。
  3. 用证书里指明的hash算法对明文T进行hash得到T’。
  4. 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。
  

3.问题点讨论

1.中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。既然不可能篡改，那整个证书被掉包呢？

2.中间人有可能把证书掉包吗？

假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

3.为什么制作数字签名时需要hash一次？

我初识HTTPS的时候就有这个疑问，因为似乎那里的hash有点多余，把hash过程去掉也能保证证书没有被篡改。最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多。当然也有安全上的原因，这部分内容相对深一些。

4.怎么证明CA机构的公钥是可信的？

安装操作系统时浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。另外，不知你们是否遇到过网站访问不了、提示需安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么你就得手动下载安装该机构的根证书（风险自己承担）。安装后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

5.每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？

这也是我当时的困惑之一，显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

6.单用数字证书解决的是什么问题？

数字证书解决的是防止中间人攻击，他必须配合对称加密和非对称加密一起使用，下一章节将通过抓包工具对流程进一步阐述。