分布式架构的基础-HTTPS协议

HTTPS简介

由于 HTTP 协议通信的不安全性，所以人们为了防止信息在传输过程中遭到泄漏或者篡改，就想出来对传输通道进行加密的方式 HTTPS。
HTTPS是一种加密的超文本传输协议，它与 HTTP 在协议差异在于对数据传输的过程中，HTTPS 对数据做了完全加密。
由于 HTTP 协议或者 HTTPS 协议都是处于 TCP 传输层之上，同时网络协议又是一个分层的结构，所以在 tcp 协议层之上增加了一层 SSL(Secure Socket Layer，安全层) 或者 TLS(Transport Layer Security) 安全层传输协议组合使用用于构造加密通道;

HTTPS/HTTPS协议.jpg

HTTPS的安全通信演进过程

1. 无加密的HTTP传输过程

无加密的HTTP传输过程.jpg

因为HTTP是明文的，在无加密的情况下，客户端很容易就可以拦截窃取，并且更改客户端传给服务端的内容

2. 对称加密

解释：
为了解决HTTP是明文的问题，我们可以对称加密的方式来解决。
对称加密即客户端和服务端同时持有不公开秘钥。

对称加密.jpg
缺点：
因为每一个客户端所带的秘钥都是一样的，所以非常有可能被不法份子获取到，获取到后不法份子就可拦截破解更改传输的内容。所以对称加密也不是一种可取的手段。
对称加密的漏洞.png

进一步优化：
在对称加密不可用的情况下，我们引入每个客户端使用的秘钥不一样。因为每个客户端的秘钥都不一致，所以直接通过客户端拿到秘钥并破解的可能性大大的降低。

缺点：
但是也引起另一个问题，服务端如何告诉客户端使用哪一种加密算法？，如果还是使用HTTP请求获取，那也还是会被不法分子获取到的。
因此单纯使用每个客户端使用的秘钥不一样也不是一种可取的手段。

每个客户端使用的秘钥不一样.png

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

解释：
所谓的公钥/私钥就是，使用公钥可以解密私钥的内容，使用私钥也可以解密公钥的内容。
公钥是所有客户端都知道的，然而私钥就只能服务器知道，不能被别人知道的。
客户端使用公钥对内容加密，服务端使用私钥对我们加密过的内容进行解密，返回给客户端信息也使用秘钥进行加密，客户端拿到数据后，使用公钥进行解密。

非对称加密（公钥/私钥）.png

缺点：
非对称加密 比 对称加密优化方法好的一点是不需要防止客户端的公钥被获取到。
看起来完美无瑕，可是还有对称加密中的优化方法问题：客户端如何拿到公钥？，我们获取到的公钥必须是安全的公钥，没有被不法分子篡改过的。

非对称加密缺陷.png

3. 引用第三方机构（数字证书CA）

解释：
对称加密和非对称加密，存在的问题就是不可信任。我们服务端不知道客户端传过来的数据是否被不法分子修改过。客户端获取服务端的数据也不知道是否被不法分子修改过。
所以我们引用第三方机构去保证客户端和服务端所获取的数据都是原始的，没有被修改过和篡改过的。

原理：
我们通过第三方机构使用非对称加密方法，加密公钥，得到数字证书（用私钥加密公钥）返回给客户端。
这样不法分子，截取到数字证书，可由于数字证书是经过加密的，不法分子没办法解密我们的数字证书，从而保证了信息不会泄露和不会被篡改。

简易版CA原理.png

存在问题：

1. 客户端如何去解密第三方机构使用私钥加密的证书？

2. 第三方机构可以颁发证书给任何一个服务端，如果机构颁发给了不法分子，不法分子可以拦截请求，并且把数字证书给替换掉，客户端如何确认数字证书的有效性？

   
   简易版CA存在问题

解决问题思路
在我们日常生活中也是有各式各样的证书，比如毕业证书，买的数码产品等等.....
这些证书上都会带有条形码或者编号，条形码或编号是唯一能够确认证书有效性，和对应信息的。

因此客户端如果能验证服务器返回来的数字证书的编号，那么我们就能够确定该数字证书是否安全有效的。
服务器向第三方机构申请数字证书时，第三方生成的数字证书会带有证书编号。证书编号是由MD5生成，只要文件发生更改，所产生的MD5值都会不同的。也因为是加密证书，所以不法分子是无法查看和修改的。

image.png

验证证书机制
浏览器内置第三方机构的公钥（如果没有则需要安装），对数字证书进行解密，解密之后获取摘要信息。
然后根据数字签名的算法，进行运算得出来的结果和服务端返回的数字证书签名一致，那么就可认为没有被篡改过。

浏览器自带的简书数字证书

总结

1. 客户端发起请求(Client Hello 包)
   a) 三次握手，建立 TCP 连接
   b) 支持的协议版本(TLS/SSL)
   c) 客户端生成的随机数 client.random，后续用于生成“对话密钥”
   d) 客户端支持的加密算法
   e) sessionid，用于保持同一个会话(如果客户端与服务器费尽周折 建立了一个 HTTPS 链接，刚建完就断了，也太可惜)

2. 服务端收到请求，然后响应(Server Hello)
   a) 确认加密通道协议版本
   b) 服务端生成的随机数 ser ver.random，后续用于生成“对话密钥”
   c) 确认使用的加密算法(用于后续的握手消息进行签名防止篡改)
   d) 服务器证书(CA机构颁发给服务端的证书)

3. 客户端收到证书进行验证
   a) 验证证书是否是上级 CA 签发的, 在验证证书的时候，浏览器会 调用系统的证书管理器接口对证书路径中的所有证书一级一级 的进行验证，只有路径中所有的证书都是受信的，整个验证的结 果才是受信
   b) 服务端返回的证书中会包含证书的有效期，可以通过失效日期来 验证 证书是否过期
   c) 验证证书是否被吊销了
   d) 前面我们知道CA机构在签发证书的时候，都会使用自己的私钥
   对证书进行签名
   证书里的签名算法字段 sha256RSA 表示 CA 机构使用 sha256 对证书进行摘要，然后使用 RSA 算法对摘要进行私钥签名，而 我们也知道 RSA 算法中，使用私钥签名之后，只有公钥才能进 行验签。
   e) 浏览器使用内置在操作系统上的 CA 机构的公钥对服务器的证书 进行验签。确定这个证书是不是由正规的机构颁发。验签之后得 知 CA 机构使用 sha256 进行证书摘要，然后客户端再使用 sha256 对证书内容进行一次摘要，如果得到的值和服务端返回 的证书验签之后的摘要相同，表示证书没有被修改过
   f) 验证通过后，就会显示绿色的安全字样
   g) 客户端生成随机数，验证通过之后，客户端会生成一个随机数pre-master secret，客户端根据之前的:Client.random + sever.random + pre-master 生成对称密钥然后使用证书中的公 钥进行加密，同时利用前面协商好的加密算法，将握手消息取 HASH 值，然后用“随机数加密“握手消息+握手消息 HASH 值(签 名)”然后传递给服务器端;(在这里之所以要取握手消息的 HASH 值，主要是把握手消息做一个签名，用于验证握手消息在传输过 程中没有被篡改过。)

4. 服务端接收随机数
   a) 服务端收到客户端的加密数据以后，用自己的私钥对密文进行解
   密。然后得到 client.random/server.random/pre-master secret. , 再用随机数密码 解密 握手消息与 HASH 值，并与传过来的 HASH 值做对比确认是否一致。
   b) 然后用随机密码加密一段握手消息(握手消息+握手消息的 HASH 值 )给客户端

5. 客户端接收消息
   a) 客户端用随机数解密并计算握手消息的 HASH，如果与服务端发
   来的 HASH 一致，此时握手过程结束，
   b) 之后所有的通信数据将由之前交互过程中生成的 pre master
   secret / client.random/server.random 通过算法得出 session Key，作为后续交互过程中的对称密钥