为什么你的浏览器会提示“不安全”？
为什么你的浏览器会提示“不安全”？
浅草丶纳凉为什么你的浏览器会提示“不安全”？一文带你揭秘 HTTPS 的爱恨情仇
在过去的十多年里，你一定遇到过各种各样“不安全”的网页提示。每当这时，是选择“小心驶得万年船”默默退出，还是“猛击”一下继续访问？
但无论你怎么选，有没有想过：这些烦人的提示到底是怎么来的？ 如果我硬要访问，提示里说的风险真的会发生吗？
你可能简单搜了一下，了解到这和 HTTPS 有关。可惜搜到的结果里夹杂着一些难懂的名词，比如 SSL、CA 机构等等，让人头大。甚至还有一些“大聪明”的帖子，教你如何手动关掉这些提示。但是去除了提示，可不等于去除了风险，这跟掩耳盗铃没啥区别。
要想真正提升网上冲浪的体验和安全感，就有必要搞懂 HTTPS 是如何保护我们的，以及数字证书在其中扮演了什么角色。更有趣的是，深挖下去，你会发现这与区块链技术也颇有渊源。
HTTP：那个在互联网上“裸奔”的协议
访问一个网站很简单，在浏览器输入网址，回车，搞定。但你想过吗？数据在你和网站服务器之间，经历了几十上百次的路由跳发。
比如，一个上海的用户访问北京的服务器，数据包中间可能要经过好多个路由器节点。在这么大的地理跨度下，谁能保证中间会不会有黑客在窃听，甚至篡改你的数据呢？
这就好比你给远方的朋友寄快递，路上谁都可能偷看一眼，甚至把你买的手办换成一块板砖。
图片来源：gemini Banana 模型生成，仅供参考
这背后的根本原因，是 HTTP 协议本身就是“裸奔”的——它压根没考虑安全问题，所有数据都以明文的形式传来传去。这让攻击者几乎不费吹灰之力就能监听和篡改。
更有甚者，早些年一些不讲武德的网络运营商，还会利用职务之便搞数据劫持，在你访问的网页里强行插入广告弹窗。所以那几年我们经常会看到，不管打开哪个网站，右下角总有那么些“狗皮膏药”广告。
HTTPS：给数据穿上“金钟罩”
上世纪 90 年代中期，互联网的价值越来越大，大家终于意识到，得给 HTTP 这个“裸奔”的协议加点安全保障了。
第一个吃螃蟹的是当时的大佬——网景公司（Netscape）。他们在 1994 年率先在自家浏览器里实现了 HTTPS 协议，这个 S 就代表 安全（Secure）。
实现方法也很直接：加密。先对数据加密再传输，对方收到后解密再用。这样一来，数据虽然还是要走过千山万水，但攻击者看到的只是一堆乱码，无可奈何。
加密的烦恼：密钥怎么悄悄给？
我们知道的加密算法有很多，从凯撒密码到二战时期的恩尼格玛机，再到现代的 DES 算法。但它们都有一个棘手的问题：都需要密钥。
加密和解密必须用同一个密钥，这叫对称加密。
问题来了：浏览器和服务器怎么才能安全地商量出一个只有他俩知道的密钥呢？如果一方生成了密钥，直接明文发给对方，那中间的攻击者不就也轻松截获了吗？这加密不就成了个寂寞？
总不能每次上网，都坐火车去和网站站长线下接头对暗号吧？这显然不现实。
神来之笔：非对称加密
更实际的办法是非对称加密。
跟对称加密用同一个密钥不同，非对称加密的密钥总是成对出现的，一个叫公钥，一个叫私钥。
它们的规则是：
- 用公钥加密的数据，只能用对应的私钥解密。
- 用私钥加密的数据，只能用对应的公钥解密。
这个过程是不对称的，非常奇妙！
有了这个神器，密钥交换问题就迎刃而解了：
- 服务器先把自己的公钥发给浏览器（公钥是公开的，谁拿到都无所谓）。
- 浏览器随机生成一个用于对称加密的密钥（我们叫它“会话密钥”）。
- 浏览器用服务器的公钥，把这个“会话密钥”加密，再发给服务器。
- 服务器收到后，用自己的私钥解密，就得到了“会话密钥”。
这样，浏览器和服务器就有了一个共同的、谁也偷不走的密钥。在这个过程中，就算攻击者截获了服务器的公钥和被加密后的会话密钥，也白搭，因为他没有服务器的私钥，根本解不开！
用非对称加密来协商出一个对称加密的密钥，然后再用这个密钥进行真正的数据传输，这就是 HTTPS 协议里那个 S 的大致实现原理。这套独立于 HTTP 的流程，也被称为 SSL（安全套接字层），而这个密钥协商的过程，就是大名鼎鼎的 SSL 握手。
小插曲：从 SSL 到 TLS
从 1994 年到 1996 年，
SSL经历了 1.0 到 3.0 的升级。后来，互联网工程任务组（IETF）决定把它标准化，于 1999 年发布了一个新名字TLS。所以很多人也把TLS 1.0看作是SSL 3.1。这两个名字后来也经常混用。顺便一说，改名也让当时和网景打得不可开交的微软显得不那么 loser 了（笑）。后来
TLS也一路升级到 1.3，主要是修补安全细节，比如在TLS 1.2中淘汰了逐渐不安全的MD5和SHA-1哈希算法，换上了更强的SHA-256。
道高一尺，魔高一丈：中间人攻击
问题似乎完美解决了，但仅仅是“似乎”。
这里面还有一个致命的漏洞：如果在第一步，服务器给浏览器发公钥的时候，攻击者就把它拦截下来，换成自己的公钥，再发给浏览器，会怎么样？
浏览器并不知道公钥被掉了包，于是开心地用攻击者的公钥加密了会话密钥。攻击者截获后，用自己的私钥轻松解密，就拿到了会话密钥！然后，他再用之前截获的服务器的真公钥，把会话密钥加密一遍发给服务器。
在这个过程中，浏览器和服务器都以为自己在和对方安全通信，但其实他俩的密钥，攻击者也一清二楚。后续所有的加密，都成了皇帝的新衣。
网站的“身份证”：数字证书与 CA 机构
这个问题的根本在于，一个公钥本身，并不能证明它属于谁。
解决方案是引入一个权威的第三方。现在，服务器不直接给公钥了，而是把自己的公钥、域名、公司信息等打包，去找一个叫 CA（Certificate Authority，证书颁发机构）的第三方。
CA 机构在严格核实了服务器的身份后，会用自己的私钥对这份数据包进行加密（这个过程叫签名）。最后，这个“被签了名的数据包”就是数字证书。
现在，服务器传递给浏览器的，就是这份能证明自己身份的证书。
浏览器拿到证书后，不会直接相信，而是要先验证：
- 浏览器内置了所有受信任的
CA机构的公钥。 - 浏览器找到证书里写的那个
CA机构，用它对应的公钥去解密证书里的签名。 - 如果解密后的数据和证书里的明文数据对得上，并且证书里的域名和当前访问的域名也一致，验证通过！
这样一来，浏览器就能百分百确定，证书里的公钥确实是这个网站的，而不是攻击者伪造的。中间人攻击的“偷天换日”大戏就演不下去了。
谁是 CA？我们为什么信它？
能成为 CA 机构的，都是像微软、谷歌、Symantec、DigiCert 这样有影响力的权威机构或专业的安全公司。原则上，它们没有动机去颁发假证书，因为这会砸了自己的金字招牌。
你的操作系统和浏览器出厂时，就已经内置了一份“受信任的根证书颁发机构”列表。只有这个列表里的 CA 签发的证书，才会被承认。前些年有些网站自己给自己发证书（自签名证书），浏览器压根不认，就会弹出安全警告。
中心化的软肋：当权威不再权威
到这里，事情好像真的解决了。但你有没有发现，CA 机构的权力和责任实在太大了，导致整个安全体系都建立在对它的信任之上，这其实很脆弱。
达摩克里斯之剑并未消失，只是向旁边挪了几寸。
证书的颁发最终还是要靠人来判断，是人就可能犯错，也可能被收买。
- 2015 年，谷歌 vs 赛门铁克：谷歌发现
CA巨头赛门铁克偷偷给谷歌的域名签发了错误的测试证书。虽然赛门铁克解释说是内部测试，但谁能保证这种证书不会泄露出去呢？ - 2017 年，信任危机：谷歌在调查后，宣称赛门铁克错误地颁发了至少 3 万个证书，并最终在 Chrome 浏览器中全面“拉黑”了赛门铁克的证书。
- 棱镜门：虽然没有直接证据，但人们有理由担心，政府机构可以利用权力强迫
CA机构颁发假证书，以用于监控。
这些事件暴露了中心化 CA 机制的困境：利益、人为因素，都是无法根除的问题。
终极方案？证书透明度（CT）
正是在这样的背景下，证书透明度（Certificate Transparency, CT）方案应运而生。
这个机制的核心逻辑，一句话概括就是：引入公开的、可审计的、去中心化的日志。
- 现在，
CA机构每次颁发一个证书，都必须强制性地向一个公开的日志服务器提交证书信息。 - 日志服务器记录下来，并返回给
CA一个SCT（Signed Certificate Timestamp，签名证书时间戳）。 CA必须把这个SCT也打包进最终的证书里。- 当浏览器收到证书后，除了验证
CA的签名，还要拿着SCT去日志服务器验证，确认这份证书确实被公开记录过。
你可能会问，这不就是套娃吗？CA 会出错，日志服务器就不会吗？
这就是 CT 机制最妙的地方：去中心化和防篡改，而这背后用到的正是类似区块链的技术——默克尔树（Merkle Tree）。
简单来说，日志服务器把所有证书记录通过哈希运算，构建成一棵“哈希树”。任何一条记录的微小改动，都会像蝴蝶效应一样，层层传导，最终导致树顶的根哈希值发生巨大变化。
这个账本是只能添加、无法篡改的，而且完全公开。任何人，包括域名所有者（可以扮演“监视者”的角色），都可以随时查询这个公开账本，检查有没有人背着自己，给自己的域名申请了可疑的证书。
从 2018 年开始，Chrome 和 Safari 等主流浏览器已经强制要求证书必须包含 SCT 信息，否则一律标为不安全。这样，所有 CA 机构都被纳入了这个公开的监管体系，再也不能“暗箱操作”了。
结语：永不消失的达摩克里斯之剑
至此，HTTPS 的安全机制，在加入了 CT 之后，基本上算是最接近完美的方案了。
但和所有安全问题一样，完美就像一个极限，只能无限趋近，却无法真正到达。CT 机制本身也存在一些理论上的风险，比如日志服务器作恶、监视者失职等等。
网络安全就是一场永无止境的攻防博弈。或许，那把悬在头顶的达摩克里斯之剑永远无法彻底消失，但经过这么多年的努力，一代代技术先驱们，已经成功地将它安放到了一个相对安全的距离之外。
而我们作为用户，下一次再看到“不安全”的提示时，或许能多一份理解和从容。
参考文献
[1] Wikipedia. Transport Layer Security [EB/OL]. [2023-03-05]. https://en.wikipedia.org/wiki/Transport_Layer_Security.
[2] transparency.dev. How CT fits into the wider WebPKI ecosystem [EB/OL]. [2023-03-12]. https://certificate.transparency.dev/howctworks/.
[3] Google. How CT Works [EB/OL]. [2023-03-10]. https://sites.google.com/site/certificatetransparency/how-ct-works.
[4] 张婕, 王伟, 马迪, 等. 数字证书透明性 CT 机制安全威胁研究[J]. 计算机系统应用, 2018(10).
