本篇先理解HTTPS逻辑，后续再讲讲HTTPS优化的细节。
把TLS/SSL先放一边，换个方式理解HTTPS。
解决信息传递的安全性
假如这个世界上还没有HTTPS，你来设计一个机制，来确保信息传输的安全，你会怎么做？
怎么保证 Client的内容不被中间人截获？
把信息加密，只有接收方和发送方能识别内容，像下面这样，只要保证密钥的安全，不让第三者知道，信息安全的问题就解决了。
Web服务模型如何解决密钥的传递？
Web服务模型是 1 v N, 这种模式想让密文安全可不容易。一个秘密只要告诉另外一个人，就已经不是秘密。下面这种就等同没有加密。
可以继续改进，每个客户端使用不同的算法。
客户端服务端之间怎么确定加密算法呢？当然是通过协商 (handshake)。
问题又来了，协商过程都是明文，被中间人截获又没办法保证安全了。
对协商过程加密
有一种加密算法非对称解密。它有两个密钥：公钥、私钥。私钥加密的密文只能公钥解，公钥加密的密文只能私钥解。
再来一个问题，为什么上面不直接用非对称加密呢？
非对称加密大量的乘、模运算相比对称加密位移类运算太慢了。HTTP这种服务，我们设计目标是既要安全，又要效率。
在协商流程中，通过随机数确定一个加密算法，然后使用公钥加密算法、密文等，服务器用私钥解密。
Client -> Server信息可以保证安全了。
公钥怎么给客户端呢？
在既要..又要...的条件下，只能服务端发给客户端，但直接发给客户端又会被中间人截获。
没办法了，两者之间解决不了信息安全的问题。只能引入第三方。
可信任的第三方机构CA Certificate Authority。
如果选择服务端直接给客户端发送公钥证书，无论用什么方式中间被掉包的问题无法解决。
用可信任三方的私钥对服务器公钥加密传给客户端。
客户端用第三方公钥解密。这样做只要解决第三方的公钥就可以了。
但如果中间人也向机构申请一个证书，然后替换你的证书怎么办？
规范数字证书
证书肯定要验证真伪，怎么验证呢？ 既然不能再请求远端，证书就要实现本地验证的功能。
客户端计算一些公开的信息生成摘要，然后用本地的第三方公钥解密，判断数字签名是否一致，如果不一致，那么证书已经不合法了。
如果是浏览器，会有更多安全保护，比如判断域名的合法性。。。
出现证书不一致，浏览器就出现了这样的错误。
本地怎么获取第三方的公钥？
操作系统、浏览器预装一些它们信任的根证书，
证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任使客户端证书的持有者可以获得转授的信任。
结束
本来是准备写HTTPS的性能优化，这样先解释一下HTTPS流程，是不是会更好理解优化的逻辑?
本文由 GY 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为:
2022/07/22 14:10