- 明白 HTTPS 到底解决了什么问题
- 理解对称加密与非对称加密的原理和使用场景
- 明白 CA 机构和根证书到底起了什么作用
Why HTTPS
HTTP（Hypertext Transfer Protocol）超文本传输协议，是一种用于分布式、协作式和超媒体信息系统的应用层协议，可以说 HTTP 是当代互联网通信的基础。
但是，HTTP 有着一个致命的缺陷，那就是内容是明文传输的，没有经过任何加密。
而这些明文数据会经过 WiFi、路由器、运营商、机房等多个物理设备节点，如果在这中间任意一个节点被监听，传输的内容就会完全暴露。
这一攻击手法叫做 MITM（Man In The Middle）中间人攻击。
不要连陌生的 WiFi，恶意 WiFi 的控制者可以看到和篡改 HTTP 明文传输的信息。
HTTPS（HyperText Transfer Protocol Secure）超文本传输安全协议，数据通信仍然是 HTTP，但利用 SSL/TLS 加密数据包
HTTPS实现原理
SSL（Secure Sockets Layer）安全套接层和 TLS（Transport Layer Security）传输层安全协议其实是一套东西。
工作流程
HTTPS 加解密流程如下：
- 用户在浏览器发起 HTTPS 请求（如 https://www.mogu.com/），默认使用服务端的 443 端口进行连接。
- HTTPS 需要使用一套 CA 数字证书，证书内会附带一个公钥 Pub，而与之对应的私钥 Private 保留在服务端不公开。
- 服务端收到请求，返回配置好的包含公钥 Pub 的证书给客户端。
- 客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示 HTTPS 警告信息，如果通过则继续。
- 客户端生成一个用于对称加密的随机 Key，并用证书内的公钥 Pub 进行加密，发送给服务端。
- 服务端收到随机 Key 的密文，使用与公钥 Pub 配对的私钥 Private 进行解密，得到客户端真正想发送的随机 Key。
- 服务端使用客户端发送过来的随机 Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端。
- 客户端使用随机 Key 对称解密密文，得到 HTTP 数据明文。
- 后续 HTTPS 请求使用之前交换好的随机 Key 进行对称加解密。
对称加密与非对称加密
对称加密是指有一个密钥，用它可以对一段明文加密，加密之后也只能用这个密钥来解密得到明文。
如果通信双方都持有密钥，且天知地知你知我知，绝对不会有别的人知道，那么通信安全自然是可以得到保证的（在密钥足够强的情况下）。
非对称加密有两个密钥
一个是公钥，另一个是私钥。一般来说，公钥用来加密，这时密文只能用私钥才能解开。
非对称加密+对称加密的方案
- 服务端有非对称加密的公钥 A1，私钥 A2。
- 客户端发起请求，服务端将公钥 A1 返回给客户端。
- 客户端随机生成一个对称加密的密钥 K，用公钥 A1 加密后发送给服务端。
- 服务端收到密文后用自己的私钥 A2 解密，得到对称密钥 K，此时完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题。
- 之后双方通信都使用密钥 K 进行对称加解密。
CA 颁发机构
私钥：解密和数字签名(一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败)
具体过程如下：
- CA 机构拥有自己的一对公钥和私钥。
- CA 机构在颁发证书时对证书明文信息进行哈希。
- 将哈希值用私钥进行加签，得到数字签名。
明文数据和数字签名组成证书，传递给客户端：
- 客户端得到证书，分解成明文部分 Text 和数字签名 Sig1。
- 用 CA 机构的公钥进行解签，得到 Sig2（由于 CA 机构是一种公信身份，因此在系统或浏览器中会内置 CA 机构的证书和公钥信息）。
- 用证书里声明的哈希算法对明文 Text 部分进行哈希得到 H。
- 当自己计算得到的哈希值 T 与解签后的 Sig2 相等，表示证书可信，没有被篡改。
HTTPS 的出发点是解决 HTTP 明文传输时信息被篡改和监听的问题：
- 为了兼顾性能和安全性，使用了非对称加密+对称加密的方案。
- 为了保证公钥传输中不被篡改，又使用了非对称加密的数字签名功能，借助 CA 机构和系统根证书的机制保证了 HTTPS 证书的公信力。
推荐
14道关于计算机网络的面试题，助你查漏补缺
https://mp.weixin.qq.com/s/qlQ7MKAvJegzauN-H8iYzw
483
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
