HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版。即 HTTP 下加入 SSL (Secure socket layer) 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL
- 建立一个信息安全通道，来保证数据传输的安全
- 确认网站的真实性，防止钓鱼网站
场景模拟
张三在中国，Tom 在美国，两人在网上聊的很投缘，聊了很多敏感话题
对称加密
加解密用同一个密钥，加解密算法是公开的，密钥是保密的
有一天，Tom 意识到：坏了，我们的通信是明文的，简直就是在网上裸奔。
张三：我们进行个数据加密，我把消息加密给你，你拿到后再解密。
Tom：好，你生成一个密钥发给我
张三：但如果真有人盯着我们，发密钥给你，密钥也被截取，岂不白费功夫
非对称加密
RSA 非对称加密，两把钥匙，公钥和私钥，用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据， 只有对应的私钥才能解密
张三和 Tom 开始查找更合适的方案，终于找到了 RSA 非对称加密。
张三和 Tom 知道该特性后，分别生成自己的公钥私钥，私钥保留，公钥全世界都可以知道。
张三给 Tom 发消息，先用 Tom 的公钥加密，Tom 接收后，用自己的私钥解密
反之亦然
非对称加密 + 对称加密
实验了几次后，两人发现 RSA 加解密太慢了，比对称加密慢百倍，两人决定结合对称与非对称的优点。
张三：第一步，我生成一个对称加密的密钥，通过 RSA 发给你，第二步，我们随后不用 RSA，只用这个密钥通信
Tom：同意，既解决了密钥的传递问题，又解决了 RSA 速度慢的问题
中间人攻击
通信多次后，张三想到，如果有个中间人在我给 Tom 发公钥时截取了我的公钥，然后把自己的公钥发给了 Tom，这样 Tom 发的消息就用了中间人的公钥加了密，那中间人就可以看到消息了。反之亦然。
详细步骤：
- 中间人截取张三和 Tom 的公钥
- 将自己的公钥发给双方
- 张三用中间人的公钥发消息给 Tom
- 中间人截取后用自己的私钥解密读取消息内容
- 中间人用 Tom 的公钥加密，再发送给 Tom
- Tom 用自己的私钥解密
- Tom 和张三都没有意识到自己的内容已经被偷窥
所以问题还是出在公钥上，虽然这个东西是公开的， 但是在别有用心的人看来，截取以后还可以干坏事
如何确认公钥属于目标对象
张三想到现实中有公证处，网络世界也可以建立一个具备公信力的认证中心（CA），可以将个人信息与公钥放到公证中心，认证中心办法一个证书，用于证明一个人的身份，这个证书还包含最关键的公钥。但是证书怎么安全传输，证书传递过程中被篡改了怎么办，好像进入了套娃。
转机就在于数字签名，张三可以把原始信息（包含张三的个人信息和张三的公钥）通过 Hash 算法生成一个消息摘要，认证中心用自己的私钥（CA 的私钥）对消息摘要加密，形成数字签名。
将原始信息和数字签名合并，形成一个全新的东西，叫数字证书。
张三将自己的数字证书发给 Tom，Tom 用同样的 Hash 算法再次生成消息摘要，然后用 CA 的公钥对数字签名解密得到 CA 创建的消息摘要，两者一对比，就知道有没有被篡改了。如果没有被篡改，Tom 拿到张三的公钥，即可进行后续的加密工作。
那么中间人有没有可能伪装为 CA？CA 本身有证书证明自己的身份，CA 的信用是像树一样，高层的 CA 给底层的 CA 做信用背书，操作系统/浏览器会内置一些顶层的 CA 证书，相当于自动信任了他们。
现实场景
前面介绍了 https 的原理，将张三当成服务器，Tom 当成浏览器即可
