HTTPS 原理讲透了，面试官却说太浅？真相比想象复杂。
我有个朋友，最近去面字节的后端岗，被问到“说说 HTTPS 原理”。这题看着挺基础，网上文章也一大堆，但他一上来就按老思路答：HTTPS 是 HTTP 加了 SSL/TLS 加密层。面试官点点头，让他继续。他接着讲对称加密、非对称加密，还说了数字证书的作用。本来觉得稳了，结果面试官突然问：“如果中间人拿到了 CA 的公钥，能不能伪造一个假证书？”他一下子卡住，支吾了几句，最后承认没细想过。
其实不怪他。很多人学 HTTPS，都是从“HTTP 不安全，所以加个加密”开始的。确实，HTTP 明文传数据，你发个密码，抓包工具一截，谁都能看。就像寄信不封口，路上谁都翻得。所以直接传明文肯定不行，得加密。
后来就想，用对称加密行不行？比如双方都拿一把同样的钥匙，你加密我解密。速度是快，但问题来了：这把钥匙怎么安全送到对方手里？第一次通信你总得告诉对方钥匙是什么吧？可只要在网络上传，就可能被截获。等于你把保险柜钥匙贴在快递盒上寄出去，还指望别人打不开？
那就换非对称加密。搞两把钥匙，一把公钥一把私钥。公钥可以随便发，谁要都行；私钥自己死死攥着。别人用公钥加密，只有你能用私钥解开。这样看起来安全了。但新问题又来了——这玩意儿太慢。RSA 加密解密一次，耗时可能是对称加密的几百倍。要是每个网页数据都这么搞，你等三秒才加载出一个按钮，谁能受得了？
于是聪明人想了个办法：用非对称加密来传对称加密的钥匙。流程是这样：你先连服务器，它把公钥发给你。你本地生成一个随机的对称密钥，用它的公钥加密后再发回去。服务器用自己的私钥解开，拿到这个对称密钥。接下来，大家都用这个对称密钥来加密通信。速度快了，密钥也安全传过去了。听起来完美，对吧？
可现实没那么简单。问题出在——你怎么确定你拿到的公钥，真是服务器发的？万一半路有个中间人，把你请求的公钥截了，换成他自己的一对公钥私钥，再冒充服务器发给你呢？你用了他的公钥加密你生成的对称密钥，他就能用他的私钥解开，看到你的密钥，然后他再用真正的服务器公钥加密转发过去。整个过程你完全不知道，他就在中间当“透明代理”，啥都能看，还能改内容。
这个叫中间人攻击。光有加密还不行，你还得确认身份。这就引出了数字证书。服务器的公钥不能光秃秃地发，得找个权威机构“盖章”。这个机构叫 CA，比如 DigiCert、Let's Encrypt。你申请证书的时候，把你的域名、公钥这些信息打包，让 CA 用它的私钥签名。这个签名就是“章”。
你收到证书后，怎么验证？用 CA 的公钥去解那个签名，得到一份数字摘要。你自己也用同样的算法算一遍证书内容的摘要，两个一对比，一样就说明没被改过。因为中间人没法伪造 CA 的签名，除非他偷了 CA 的私钥——那事情就大了，整个信任体系崩了。
但这又带出一个问题：你怎么确定你手里的 CA 公钥是对的？难道不会也被篡改吗？答案是，操作系统和浏览器出厂就自带一堆可信 CA 的公钥，叫“根证书”。这些是硬编码进来的，你默认就得信。除非你的设备被入侵，或者你自己手贱装了恶意根证书。
所以完整的 HTTPS 握手流程是：TCP 连接建立之后，客户端发请求，服务器回证书；客户端验证证书合法性，包括域名对不对、有没有过期、签发机构是不是可信；验证通过后，生成随机的对称密钥，用证书里的公钥加密，发给服务器；服务器用自己的私钥解出对称密钥；后续通信都用这个对称密钥加密。
整个过程下来，解决了三件事：机密性——数据加密了；完整性——传输中被改能发现；身份真实性——你连的确实是你要连的网站。但也不是绝对安全。比如证书本身可能被错误签发，CA 可能被攻破，或者企业内网用透明代理强制装根证书监控流量。所以浏览器看到风险证书时会弹警告，不能直接点“继续访问”就完事。
现在回头看，我那朋友答得不算错，但太表面。面试官想听的可能不只是“流程”，而是你有没有意识到这些细节里的坑。技术这东西，看起来一层窗户纸，捅破了才发现后面还有墙。
