这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天
今天学习了https中的s代表的TLS加密协议，了解了具体四次握手中传递的数据相关
为什么公钥可以用来加密但是不能用来解密
-
对称加密和非对称加密
- 对称加密：加密和解密用的都是同一个秘钥的加密形式
- 非对称加密：公钥负责加密，私钥负责解密。公钥人人可得，私钥永远不泄露，这里的公钥和私钥是可以互换的
-
-
具体的四次握手
-
第一次握手：
Client Hello：是客户端告诉服务端，它支持什么样的加密协议版本，比如TLS1.2，使用什么样的加密套件，比如最常见的RSA，同时还给出一个客户端随机数。
第二次握手：
Server Hello：服务端告诉客户端，服务器随机数 + 服务器证书 + 确定的加密协议版本（比如就是TLS1.2）。
第三次握手：
Client Key Exchange: 此时客户端再生成一个随机数，叫pre_master_key。从第二次握手的服务器证书里取出服务器公钥，用公钥加密pre_master_key，发给服务器。Change Cipher Spec: 客户端这边已经拥有三个随机数： 客户端随机数，服务器随机数和pre_master_key，用这三个随机数进行计算得到一个"会话秘钥"。此时客户端通知服务端，后面会用这个会话秘钥进行对称机密通信。Encrypted Handshake Message：客户端会把迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给服务器做校验，此时客户端这边的握手流程就结束了，因此也叫Finished报文。
第四次握手：
Change Cipher Spec：服务端此时拿到客户端传来的pre_master_key（虽然被服务器公钥加密过，但服务器有私钥，能解密获得原文），集齐三个随机数，跟客户端一样，用这三个随机数通过同样的算法获得一个"会话秘钥"。此时服务器告诉客户端，后面会用这个"会话秘钥"进行加密通信。Encrypted Handshake Message：跟客户端的操作一样，将迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给客户端做校验，到这里，服务端的握手流程也结束了，因此这也叫Finished报文。
-
-
TLS实际上对称密钥和非对称密钥都使用到了，握手之后使用对称密钥相对的性能更好
-
第二次握手为什么服务器端需要使用CA私钥加密再发送，即为什么不能直接把公钥直接发出去
反过来想想，如果只传公钥，公钥就有可能会在传输的过程中就被黑客替换掉。然后第三次握手时客户端会拿着假公钥来加密第三个随机数
pre_master_key，黑客解密后自然就知道了最为关键的pre_master_key。又因为第一和第二个随机数是公开的，因此就可以计算出"会话秘钥"。所以需要有个办法证明客户端拿到的公钥是真正的服务器公钥，于是就拿CA的私钥去做一次加密变成服务器证书，这样客户端拿CA的公钥去解密，就能验证是不是真正的服务器公钥。
-
CA的公钥获取方式
- 最容易想到的是请求CA的官网，获取公钥。但全世界要上网的人那么多，都用去请求CA官网的话，官网肯定顶不住。
- 考虑到能颁发证书的CA机构可不多，因此对应的CA公钥也不多，把他们直接作为配置放到操作系统或者浏览器里，这就完美解决了上面的问题。
-
三个随机数是否都能获取
-
这三个随机数，两个来自客户端，一个来自服务端。第一次和第二次握手里的客户端随机数和服务端随机数，都是明文的。只要有心，大家都能拿到。
但第三个随机数
pre_master_key则不行，因为它在客户端生成后，发给服务器之前，被服务器的公钥加密过，因此只有服务器本器才能用私钥进行解密。就算被别人拿到了，没有服务器的私钥，也无法解密出原文。
-
-
看上去第三个随机数
pre_master_key才是关键，另外两个看起来可有可无？确实，就算没有另外两个，也并不影响加密功能。之所以还要两个随机数，是因为只有单个
pre_master_key随机性不足，多次随机的情况下有可能出来的秘钥是一样的。但如果再引入两个随机数，就能大大增加"会话秘钥"的随机程度，从而保证每次HTTPS通信用的会话秘钥都是不同的 -
为什么最后一次握手需要附带摘要？
-
摘要，说白了就是对一大段文本进行一次hash操作。目的是为了确认通信过程中数据没被篡改过。
第三次握手，客户端生成摘要，服务端验证，如果验证通过，说明客户端生成的数据没被篡改过，服务端后面才能放心跟客户端通信。
第四次握手，则是反过来，由服务端生成摘要，客户端来验证，验证通过了，说明服务端是可信任的
-
-
加密过程中涉及到的密钥对数？
-
两对。
服务器本身的公钥和私钥：在第二次握手中，服务器将自己的公钥（藏在数字证书里）发给客户端。第三次握手中用这个服务器公钥来加密第三个随机数
pre_master_key。服务器拿到后用自己的私钥去做解密。CA的公钥和私钥：第二次握手中，传的数字证书里，包含了被CA的私钥加密过的服务器公钥。客户端拿到后，会用实现内置在操作系统或浏览器里的CA公钥去进行解密
-
-
为什么黑客无法通过CA公钥来破解？
- 这里涉及到两组公私钥，用CA公钥的地方只有在验证由CA私钥签名过的服务器公钥的合法性时才用上，用CA公钥的目的只是用来验证服务器发送过来的证书中的服务器公钥的合法性，随后用这个服务器公钥加密第三个随机数，此时用CA公钥是无法解密的，因为是两组不同的公私钥。黑客拿到CA公钥后唯一能做的只是验证证书的合法性
