# https是如何保证安全的？
# 介绍
HTTPS（Hypertext Transfer Protocol Secure）之所以安全，是因为它在 HTTP 的基础上加入了一个加密安全层——SSL/TLS 协议。
通俗来说，传统的 HTTP 就像是寄明信片，内容在传输过程中所有人都能看到；而 HTTPS 则是把信件装进了带密码锁的保险箱，只有收件人和寄件人才能打开。
HTTPS 主要通过防窃听、防篡改和防冒充三个维度来保证安全，其核心机制可以拆解为以下三个部分：
# 混合加密（防窃听）
如果全程使用复杂的加密方式，网络传输会变得非常慢。因此，HTTPS 巧妙地结合了非对称加密和对称加密，形成“混合加密”机制
非对称加密（用于握手阶段）： 浏览器和服务器建立连接时，服务器会提供一个公钥，自己留着私钥。公钥加密的数据只能用私钥解密。浏览器生成一个随机数（未来的“对称密钥”），用服务器的公钥加密后传给服务器。这个阶段虽然慢，但保证了密钥传输的安全
对称加密（用于数据传输阶段）： 一旦双方安全地交换了那个随机数，双方就拥有了相同的对称密钥。后续所有的网页内容、密码、交易数据，都用这个密钥进行快速的对称加密传输
# 数字证书与数字签名（防冒充）
既然公钥是公开的，黑客完全可以伪造一个假网站，并把自己的公钥发给浏览器（即“中间人攻击”）。为了解决“如何证明服务器是真正的服务器”这一问题，HTTPS 引入了 CA（数字证书认证机构）
数字证书： 网站运营者需要向权威的 CA 机构申请证书，证书里包含网站的域名、服务器的公钥以及证书有效期等信息
数字签名： CA 机构会用自己的私钥对证书内容进行哈希（Hash）并加密，生成一个“数字签名”附在证书上
浏览器验证： 操作系统和浏览器中预装了各大权威 CA 机构的公钥。当浏览器访问网站时，服务器会先发来证书。浏览器用 CA 的公钥解密签名，并核对证书内容。如果匹配，说明证书真实有效，网站没有被冒充
# 摘要算法 / MAC（防篡改）
即便数据被加密了，黑客如果在中途故意破坏或修改了部分密文（虽然他看不懂），也会导致信息失效或出错。
HTTPS 使用了摘要算法（如 SHA-256）和哈希消息认证码（HMAC）。
发送方在发送数据前，会针对内容计算出一个唯一的“指纹”（哈希值）并随数据一起发送
接收方收到后，用同样的算法对内容再计算一次“指纹”，如果两个指纹完全一致，说明数据在传输过程中完整无缺，没有被任何人篡改过
# 总结：HTTPS 建立连接的完整流程
- 客户端发起请求：浏览器向服务器索要数字证书
- 服务器回应证书：服务器发送包含服务器公钥的 CA 证书
- 客户端验证证书：浏览器利用内置的 CA 公钥验证证书的真实性，并确认域名是否匹配
- 生成并传输对称密钥：验证通过后，浏览器在内存中生成一个随机的对称密钥，用服务器的公钥加密后发送给服务器
- 服务器解密密钥：服务器用自己的私钥解密，得到对称密钥。
- 开始安全通信：此后，双方所有的通信都使用这个对称密钥进行加密传输
# 附录
我们可以通过一个“安全机制演进史”的故事，来理解为什么 HTTPS 最终会变得这么复杂
如果把浏览器和服务器看作小明和小红，他们想在布满监听者的网络中悄悄写信，HTTPS 的每一步，其实都是为了补上上一步被黑客攻破的“漏洞”
# 第一阶段：明文传输（原始的 HTTP）
做法： 小明和小红直接用白纸写信，邮差（路由器、运营商、黑客）在传输过程中一览无余。
漏洞（被偷看）： 毫无隐私，密码、银行卡号直接暴露
# 第二阶段：引入对称加密（开始穿防弹衣）
为了不让邮差看懂，小明和小红商量：我们用“对称加密”吧！
做法： 双方约定一个只有他们知道的密码本（密钥）。小明用密码本把信件变成乱码，小红收到后用同一个密码本解密
新漏洞（密钥怎么给对方？）： 既然是第一次通信，小明必须把“密码本”先寄给小红。在寄送密码本的途中，邮差直接把密码本复印了一份。 之后所有的加密信件，邮差依然能轻松解密
# 第三阶段：引入非对称加密（解决密钥传输问题）
既然“送密码本”在路上会被偷看，小明和小红决定采用高级的“非对称加密”。
做法： 小红做出了一把“锁（公钥）”和唯一的一把“钥匙（私钥）”。小红把公开的“锁”寄给小明。小明写好信，用这把“锁”把信箱锁上，寄给小红。
新问题（性能太差）： 这招很绝，因为只有小红有钥匙，路上谁也打不开。但非对称加密的数学计算太复杂了，如果整封信、甚至几百兆的网页数据都这么搞，网页打开速度会慢成老牛拉车。另外这个阶段也存在中间人攻击的问题
# 第四阶段：混合加密（兼顾安全与速度）
为了解决性能问题，小明和小红决定各退一步，把两种加密结合起来：
做法：
- 小红还是把“锁（公钥）”寄给小明
- 小明在家里自己编了一个临时的小密码本（对称密钥）
- 小明把这个小密码本放进盒子里，用小红的“锁”锁上，寄给小红
- 小红用自己的“钥匙（私钥）”打开锁，拿到了小密码本
- 此后，两人抛弃非对称加密，全部用这个小密码本（对称加密）来写信
新漏洞（中间人攻击 / 冒充）： 这看起来完美无缺，但黑客（邮差）想出了一个更绝的招数——冒充
当小红把“锁”寄给小明时，黑客在半路把小红的“锁”拦截并扣下，换成了黑客自己的“锁”寄给小明。小明以为这是小红的锁，把对称密钥放进去锁好寄回。黑客用自己的钥匙解密拿到密钥，再用小红真正的锁加密传给小红。此时，小明和小红都以为在和对方安全通信，但其实所有流量都在黑客那里变成了大白话
# 第五阶段：数字证书与 CA（解决“你是谁”的问题）
小明糊涂了：我怎么知道寄给我的那把“锁”，到底是不是小红的？于是，他们引入了权威的第三方公证处——CA 机构。
做法： 小红不能直接把“锁（公钥）”寄给小明。小红得拿着自己的身份证和“锁”，去公证处（CA）办理一张“数字证书”。证书上写着：这是小红的锁，公证处盖章（数字签名）。
如何防伪： 小明的操作系统和浏览器里，早就默认信任了这些权威公证处，并保存了公证处的签名防伪特征。当小明收到带有公证处盖章的证书时，一验章就知道这确实是小红的锁，黑客根本伪造不了这个章
# 最终阶段：摘要算法（防止内容被坏蛋篡改）
现在身份确认了，密钥也安全传过去了。但黑客最后使坏：虽然我看不懂你们在聊什么，但我在你们的密信上乱涂乱画，或者故意删掉几行，让你们产生误会
做法： 于是小明在每封信的结尾，都附带一个用信件内容算出来的“数字指纹”（哈希值）。小红收到后重新算一遍指纹，对得上了，说明信件在路上连一个标点符号都没被动过
← 加密算法有哪些？