前言：为什么借 HTTPS#

如果是大部分入门密码学的人，看到诸如对称、非对称加密、密钥管理与分发、数字签名、CA 证书、密码协议等等很多概念肯定都会一头雾水。因为密码学是一个高度体系化的领域，往往是好不容易弄清了一个概念，却发现到了实际情况还要去学其他很多概念，并且还非得弄清楚不同概念之间的联系（别问我为什么知道，因为自己其实已经被这个问题困扰很久了，直到最近才勉强理清一点点）。所以此次想要借助 https 辅助一下，看看能不能稍微融会贯通一点。

HTTPS 是什么#

对于 https，各位肯定很熟悉，也就是浏览器里面最前面的那几个字符，最典型的就是 https://www+域名 这种。而 https 也就是所谓的密码学协议，全称 Hypertext Transfer Protocol Secure。但是至于这个协议如何起作用的，这里面涉及的东西就比较多了。由于 https 主管通信侧，所以核心问题是如何在互联网这个开放性的虚拟世界里面，建立两个人之间的可信通信信道。以下是具体过程。

第一步：TCP 三次握手#

当我们在浏览器输入并回车后，浏览器会自动把输入解析成对应 ip 地址，也就是对应网页服务器所在的 ip。此时本地设备会先通过庞大的路由节点，与 ip 建立连接，也就是找到对方的位置。这个过程俗称 TCP 三次握手，为的是先确保能够建立通信链路（这个过程和密码学关系其实不大）。

第二步：TLS 身份验证#

建立通信链路之后，要怎么确保对方一定是正确的服务器呢？这就是 TLS 加密的开端，需要用数字签名 + CA 证书 + 哈希函数（通常为 SHA-384）进行操作。

1. 首先，服务器会把自己的公钥、域名等信息，提前拿去给 CA 机构。CA 机构用自己的私钥对这些信息进行签名，生成一个数字证书。所以，服务器的 CA 证书里包含了自己的公钥，以及 CA 对这份公钥的签名。
2. 当本地设备访问网站时，服务器会把自己的 CA 证书发送过来。
3. 本地设备（浏览器或操作系统）内置了信任的 CA 根证书（即 CA 的公钥），它会用 CA 的公钥去解密证书里的数字签名，得到一份消息摘要（Hash 值 1）。同时，本地设备自己也会用同样的哈希函数对证书内容重新计算，得到另一份消息摘要（Hash 值 2）。
4. 如果 Hash 值 1 和 Hash 值 2 完全一致，就说明证书内容没有被篡改，且确实是由那个权威 CA 签发的。
5. 最后，再检查证书里的域名和自己正在访问的域名是否一致，就能确认对方的身份了。

第三步：协商对称密钥#

确认对方身份无误后，接下来要做的就是生成对称密钥了（因为高效传输海量信息一般用对称加密，而对称加密的密钥必须双方共享）。至于如何生成私钥，就是要用非对称加密了：

• 这里一般是用 ECC，也就是椭圆曲线离散对数困难型问题为基础，用 ECDHE 协议来协商出共享秘密。
• 具体来说，AES 的会话密钥，是基于这个共享秘密、加上客户端和服务器的随机数，通过 HKDF 等等密钥派生函数进一步生成的。
• 当然此处私钥都是在本地，用于后续的加密。

到这里 TLS 加密就结束了。

第四步：AES 加密传输#

这个时候已经有了会话密钥了，然后就可以进行加密了。一般来说，明文数据都是在物理设备本地进行相关的加密（也就是在操作系统的 sys 程序里面），然后经过网卡包装，加上设备 ip、mac 等等信息生成数据包，最后通过已经建立好的通道发送出去。而加密的过程就是用对称加密，一般是 AES——安全性高而且效率也高。

一般来说，此时发送出去的数据为密文，就算被劫持也没有大碍，因为第三方既没有你的本地私钥，也没有你的具体加密手段。但是数据到达服务器之后，就会被自动解密成明文，存储在服务器的后端数据库里面——因为之前在本地生成的私钥是本地和服务器共享的，所以说服务器是完全可以解密的。此时想要从 web 的后端数据库获得明文，就是另外一码事了。

此处说个题外话：如果直接 ping 任意网页的话，是直接向对应服务器发送 icmp 数据包，是不涉及 TCP 三次握手和 TLS 加密的。

总之，以上只是我个人关于密码学在 https 当中实际应用的一些思考，内容深度比较浅，同时也难免有细节有误的地方，欢迎各位老师积极进行指正，同时有好的建议也欢迎指出！我将不吝感激！

原文发布于知乎（2026-05-18），收录于《桂电密码学本科生的密码学学习笔记》系列，作者：亦梦。