HTTPS公私钥加密过程

HTTPS公私钥加密演变过程

http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。

加密方式大体可以分为两种：

• 对称加密
• 非对称加密

1 对称加密（私钥加密）

加密解密都是用相同的密钥
原数据：A
密钥：B
加密后数据：A + B = C
解密后数据：C - B = A

2 非对称加密（公私钥加密）

加密解密使用不同的密钥
原数据：A
公钥：B
私钥：D
公钥加密后数据：A + B = C
私钥解密后数据：C - D = A

非对称加密作用：
①公钥加密，私钥解密
②私钥签名，公钥验签

私钥和公钥是一对，谁都可以加解密，只是谁加密谁解密是看情景来用的：
第一种情景是签名,使用私钥加密,公钥解密,用于让所有公钥所有者验证私钥所有者的身份并且用来防止私钥所有者发布的内容被篡改.但是不用来保证内容不被他人获得。
第二种情景是加密,用公钥加密,私钥解密,用于向公钥所有者发布信息,这个信息可能被他人篡改,但是无法被他人获得。

非对称加密，公私钥谁加密谁解密
公私钥应用及Token加密

3 HTTPS加密演变过程

使用对称加密来加密HTTPS可行吗？
显然是不现实的，因为对称加密使用的是相同的密钥来进行加密与解密，一旦被中间人截取到，那么他就可以直接查看里面的数据

3.1 非对称加密

使用非对称加密：服务器先把公钥以明文的形式传输给浏览器，然后浏览器向服务器传输数据之前都先使用这个公钥加密好之后再传输，这样这个数据的安全性似乎得到了保证，因为只有服务器才存在对应的私钥来解开被公钥加密过的数据。

问题：但是这样的方式无法保证服务器到浏览器这条路线的安全。比如：服务器给浏览器传输的公钥一开始就是明文的，那么如果这个公钥被中间人劫持了，中间人就可以把自己的公钥发送给浏览器，让浏览器误以为是服务的公钥，同时，浏览器也可以通过之前劫持到的公钥给服务器发送数据。【只能保证浏览器向服务器传输数据的安全性】

3.2 两次非对称

既然通过一组公私钥可以保证单个方向的传输安全，那么我们使用两组公私钥，是否就可以保证双向的传输安全呢？

1. 某服务器网站拥有公钥A与对应的私钥A’；浏览器拥有公钥B与对应的私钥B’
2. 浏览器把公钥B明文传输给服务器
3. 服务器把公钥A明文传输给浏览器
4. 之后浏览器向服务器传输的内容都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有私钥A’，所以可以保证这条数据的安全。
5. 同理，服务器向浏览器传输的内容都用公钥B加密，浏览器收到后都用私钥B’解密，也可以保证这条数据的安全。

可以实现双向的数据传输安全，但是非对称加密非常的耗时。而对称加密会快很多，我们就想能不能运用非对称加密来解决对称加密的漏洞呢？

3.3 非对称+对称

既然非对称加密耗时，对称加密不安全，那么结合起来会怎样呢？

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

HTTPS基本就是采用的这种方案

3.4 中间人攻击

如果在数据传输过程中，中间人劫持到了数据，虽然此时他无法得到浏览器生成的密钥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。根据原因是因为浏览器无法确认收到的公钥是不是服务器网站自己的。

3.5 证书机制

CA机构，它是互联网正常运作的前提，CA机构会给每个合法的使用HTTPS的网站颁发数字证书。

• 数字证书

网站在使用HTTPS之前，需要向CA机构申领一份数字证书，证书里面包含证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明该公钥对应该网站。但是我们如何证明证书本身的真实性呢？

• 如何防止数字证书被篡改？

我们把证书原本的内容生成一份签名，对比证书内容和签名是否一致就可以判别是否被篡改，这就是数字证书的防伪技术，这里的签名就是数字签名。

数字签名的生辰与验证：

• 数字签名的制作过程

1. CA机构拥有非对称加密的私钥和公钥
2. CA机构对证书明文数据T进行hash
3. 对hash之后的值用私钥加密，得到数字签名S

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那么浏览器拿到服务器传来的数字证书之后，如何验证它是不是真的？（有没有被掉包、篡改等）

• 浏览器验证过程

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

中间人还能破坏吗：

• 篡改证书[x]

就算改了证书的原文，但因为没有CA机构的私钥，所以无法得到此时加密后签名，也就无法篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，说明证书被篡改，证书不可信

• 证书掉包[x]

假如有一个网站B拿到了CA机构认证的证书，它想成为中间人拦截浏览器发送给网站A的信息。
但是会因为证书里包含了网站A的信息，包含域名，浏览器只需要把证书里的域名与自己请求的域名对比一样就知道有没有掉包了。

3.6 Q/A

①为什么制作签名的时候需要hash一次？

hash之后会得到固定长度的值，加解密快，并且安全性不低

crypto.stackexchange.com/a/12780

②如何证明CA机构的公钥是可信的？

安装OS、浏览器的时候会预装一些它们信任的证书，并且证书之间的信任链可以传递，A信任B，B信任C（信任链、数字证书链）。
但是我们始终无法安装所有网站的可信的证书，假如遇到了网站访问不了，提示我们需要安装证书的话，我们安装的就是根证书，说明浏览器不认识给这个网站颁发证书的机构，那么就需要我们手动下载安装该机构的根证书（自行承担风险），安装证书之后，我们就有了它的公钥，就可以用它来验证服务器发来的证书是否可信了。

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

不需要，服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

SSL/TSL属于会话层
SSL：安全套接字
TLS：安全传输层协议

4 拓展 PKI

PKI：Public Key Infrastructure，公钥基础设施

1. PKI概述
   作用：通过加密技术和数字签名保证信息的安全
   组成：公钥加密技术、数字证书、CA、RA

2. 信息安全三要素

• 机密性
• 完整性
• 身份验证/操作的不可否性

3. 哪些IT领域用到了PKI
   1）SSL/HTTPS
   2）IPsecVPN
   3）部分远程访问VPN

4. 公钥加密技术

• 作用：实现对信息加密、数据签名等安全保障
• 加密算法：
  • 对称加密算法

  加密解密的密钥一致【DES、3DES、AES】

  • 非对称加密算法

  通信双方各自产生一对公私钥
  双方各自交换公钥
  公钥和私钥为互相加解密关系

5. 证书

• 用于保证密钥的合法性
• 数字证书包含信息：
  使用者的公钥值
  使用者标识信息（如：名称和电子邮件地址）
  有效期
  颁发者标识信息
  颁发者的数字签名
  数字证书由权威公正的第三方机构（CA）签发

参考文章：
https://zhuanlan.zhihu.com/p/43789231
https://www.cnblogs.com/shijingjing07/p/5965792.html
https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/