打开任何一个需要登录的网站，浏览器地址栏左侧都会出现一把小锁。多数人知道它代表 "安全"，但如果追问一句：这把锁到底锁住了什么？谁给它发的锁？为什么在咖啡馆连公共 Wi-Fi 时，旁边的人偷看不到你的密码？能答上来的人一下子少了很多。
这篇文章把那把锁拆开看清楚。先讲清它要对抗的三种攻击，再顺着 "两种加密方式各有什么短处" 这条线，推出 HTTPS 的整套设计------你会发现它不是某项天才发明，而是两个各有缺陷的零件互相补台的结果。最后用一条命令亲手验证书的信任链，把抽象概念落到眼前。
1 那把锁在保证什么
1.1 裸奔的 HTTP
HTTPS 里的 S 指的是 Secure（安全），它不是取代 HTTP，而是给 HTTP 套了一层保护壳。要看懂壳的价值，先看没有壳的 HTTP 是什么处境。
你登录一个网站时，浏览器向服务器发出的大致是这样一段文本：
bash
POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
username=li_ming&password=Ab123456用户名和密码以明文形式直接写在请求体里。这段文本从你的电脑出发，经过家里或咖啡馆的路由器、运营商的机房、若干骨干网络节点，最终到达服务器。这条路径上的任何一个环节，都能原封不动地读到这段明文------你的密码在旅途中至少被十几个设备经手过，其中任何一台被动手脚，密码就泄露了。
这还只是最温和的威胁。HTTP 面前敞开着三扇门：
- **窃听：**中间人读到你的通信内容，拿到账号、密码、聊天记录；
- **篡改：**中间人改掉通信内容，比如运营商在页面里插广告脚本、把下载链接换成别的文件；
- **冒充：**中间人伪装成目标网站，你以为是登录官网，实际上密码发给了钓鱼服务器。
HTTPS 要同时关掉这三扇门。它给出的三样武器分别叫加密、校验、认证，而支撑这三样武器的，是两套加密体系。
2 为什么需要两种加密
2.1 对称加密：快，但钥匙送不出去
对称加密的规则很直白：加密和解密用同一把钥匙。你用密钥把一段明文搅成一团乱码，对方拿同一把密钥就能还原。日常软件里广泛使用的 AES 算法就属于这一类，它的加解密速度极快，加密几百兆的数据也是眨眼的事，适合保护通信的全部内容。
问题出在钥匙本身。你和服务器得先拥有同一把密钥，加密才能开始------可你们此刻还没有安全通道，正是要靠这把钥匙来建立安全通道。这就陷入死循环：要把密钥安全地发给对方，需要一条安全通道；要建立安全通道，需要先安全地发密钥。术语上这叫 "密钥分发问题"，它困扰了密码学几十年。
更麻烦的是规模。一个网站有几百万用户，如果和每个用户用一把固定密钥，服务器要保管几百万把，任何一把泄露都波及一批用户。所以理想方案是：密钥不能预先存在，得在每次通信开始时现场商量出来，而且商量过程本身就得是安全的。
2.2 非对称加密：送钥匙没问题，但太慢
1970 年代出现了一类巧妙的设计：非对称加密。它用一对钥匙代替一把------公钥和私钥。公钥可以随便公开，任何人拿它加密一段内容，加密结果只有私钥能解开；反过来，私钥签的名，任何人拿公钥都能验证。
这个机制恰好绕开了密钥分发：服务器把公钥大大方方挂在门口，你想给它发秘密，用公钥加密就是，全世界只有握着私钥的服务器能读。
但非对称加密有一个致命短板：慢。同样一段数据，RSA 这类算法的运算速度比 AES 慢三个数量级左右------拿它加密整个网页的传输量，要花不可接受的时间。用它保护全部通信，等于给每辆卡车配一台蒸汽机：安全是安全了，路也走不动了。
2.3 各取所长的组合
于是现代安全通信的设计不言自明：用非对称加密解决 "送钥匙"，用对称加密保护 "正式通信"。握手阶段，双方借助公私钥机制商量出一把本次会话专用的对称密钥，也就是会话密钥；握手完成之后，所有数据都用这把会话密钥加解密，享受 AES 的速度。每个连接的密钥都是临时生成的、互不相同的，用完即弃，前一个连接泄露也牵连不到后面。
这个分工是理解 HTTPS 的钥匙。后面所有内容------握手流程、证书、信任链------都在为这一步的顺利执行保驾护航。
3 TLS 握手：两种加密的接力现场
HTTPS 里那层保护壳的标准名字是 TLS （Transport Layer Security，传输层安全）。建立连接时，浏览器和服务器先要跑一段握手流程，把会话密钥商量出来。以传统 TLS 1.2 的密钥交换方式为例，握手可以概括成四步：
- **客户端打招呼：**浏览器告诉服务器自己支持哪些加密算法，并附带一个随机数；
- **服务器回应并出示证书：**服务器选定一套算法、给出第二个随机数，同时发送自己的证书------里面有服务器的公钥和身份信息（证书是什么、谁签发的，下一节展开）；
- **客户端生成预主密钥：**浏览器验证证书无误后，生成第三段随机数（预主密钥），用服务器证书里的公钥加密，发给服务器。只有握有私钥的服务器能解开这段内容；
- **双方各自算出会话密钥：**两边都握有三段随机数，用同一套算法一算，得到完全相同的会话密钥。此后通信全部用这把密钥加密。
窃听者全程在线旁观，却始终拿不到密钥------他看得到三段随机数中的前两段，也看得到加密后的第三段，但没有私钥就解不开它，凑不齐原料，算不出会话密钥。这正是非对称加密的功劳：公钥可以随便给，加密结果只有私钥能解。
握手之后的数据除了加密，还附带用会话密钥算出的校验码。中间人哪怕只改动一个比特，校验立刻对不上，连接就会被丢弃------1.1 节里那扇叫 "篡改" 的门，是在这里一并关上的。
顺带一提，TLS 1.3 对握手做了两处升级：一是把密钥交换改成了协商制，双方各自出一半秘密、拼出共同密钥，谁也不传输加密的密钥，连服务器私钥将来泄露都无法追溯历史会话；二是把往返次数从两次压到一次，握手快了一截。原理层面的分工没有变化，仍是 "非对称建立信任，对称传输数据"。
4 中间人攻击：真公钥还是假公钥
4.1 上面那套流程有个缝
握手流程里，客户端是从服务器发来的证书里拿到公钥的。现在换到攻击者视角看这一步：如果攻击者把自己拦截在浏览器和服务器之间------比如你连上了他伪造的免费 Wi-Fi------他完全可以把服务器的证书换成自己的，让浏览器拿攻击者的公钥完成整个握手。后续所有 "加密" 通信，实际上都加密给了攻击者；他解密后偷看，再与真正的服务器另建一条连接，在里外两层之间转发，双方都毫无察觉。
这就是中间人攻击。仅仅依赖 "收到一个公钥" 的流程，挡不住公钥被调包。要堵上这道缝，浏览器需要一种办法回答一个问题：这个公钥，真的属于 www.example.com 吗？
4.2 证书：给公钥办一张身份证
答案是把公钥和域名绑在一起，再找一个权威机构担保。这份担保文件就是数字证书，它的核心内容大致是：
bash
证书
颁发给：www.example.com（含所属组织、所在国家等信息）
公钥：XX XX XX ......（服务器的公钥）
有效期：2026-01-01 至 2027-01-01
颁发者：某 CA
签名：（CA 用自己的私钥对以上全部内容的摘要所做的签名）关键在最后一行。证书颁发机构 （Certificate Authority，简称 CA）是一批被整个互联网共同信任的机构，网站向 CA 申请证书时，CA 会核实申请者确实控制着该域名，核实通过才签发。CA 用自己的私钥对证书内容签名------这份签名利用了非对称加密 "私钥签名、公钥验证" 的特性：任何人都能验证签名真伪，但除了 CA 本尊，没人能造出来。
于是中间人伪造证书的路被堵死了：他可以造一份证书，但伪造不了某 CA 的签名。而真证书里的公钥经过了 CA 担保，确实属于那个域名。
4.3 信任链：担保也需要担保
新问题随之而来：浏览器拿到证书、想验证 CA 签名时，需要 CA 的公钥。CA 的公钥又从哪来？总不能在握手时再向 CA 的服务器要一次------那 CA 自己也可能被冒充，套娃无尽头。
实际的解法很朴素：浏览器和操作系统出厂时预装了一批根 CA 的公钥，这份名单叫信任库。微软、苹果、Mozilla、谷歌各自维护自己的信任库，只收录经过长期审查的机构。你的电脑里就躺着几十张根证书，它们是整个信任体系的起点------所有验证最终都汇到这几个预置的公钥上。
现实中直接给网站签发证书的往往是中间 CA，根 CA 很少亲自下场。于是证书形成了一条链：
bash
网站证书 ← 中间 CA 签发
中间 CA 证书 ← 根 CA 签发
根 CA 证书 ← 预装在你的系统里，自签名，直接信任浏览器验证时逐级向上：用中间 CA 的公钥验网站证书的签名，再用根 CA 的公钥验中间证书的签名，最后发现根证书就在本机信任库里------链条闭合，验证通过。任何一环签名对不上、域名不符、证书过期，浏览器都会亮红警告拒绝连接。
这套体系的信任逻辑值得多看一眼：它不依赖服务器或客户端的诚实，而是把信任锚点放在几十家经年审查的机构加上操作系统厂商的预置名单上。攻击者要冒充一个网站，必须让浏览器相信自己拿到了合法签名------要么黑进某 CA 偷私钥（历史上发生过，涉事 CA 的根证书会立刻被浏览器厂商从信任库除名，机构等于倒闭），要么想办法改你电脑上的信任库（那时你已经中毒，HTTPS 管不了也管不着了）。
5 亲手验证一次
空讲理论容易虚，花一条命令就能把信任链摸到实物。在装了 openssl 的机器上（Linux、macOS 自带；Windows 可用 WSL）执行：
bash
openssl s_client -connect www.baidu.com:443 -showcerts命令会连上百度并输出完整的握手信息与证书链，节选关键部分：
bash
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Secure Site CA
depth=0 C = CN, ST = beijing, CN = www.baidu.com
---
Certificate chain
0 s:CN = www.baidu.com ← 网站证书：百度
i:CN = DigiCert Secure Site CA ← 由 DigiCert 的中间 CA 签发
1 s:CN = DigiCert Secure Site CA ← 中间 CA 证书
i:C = US, O = DigiCert Inc ← 由 DigiCert 根 CA 签发三行 depth 恰好对应一条三级信任链：最底层是百度的网站证书（depth 0），往上是 DigiCert 的中间 CA（depth 1），再往上是 DigiCert 根 CA（depth 2）。你可以换任何 HTTPS 网站试这条命令，观察它们的签发机构各不相同，但链条的顶端几乎总是那几十家耳熟能详的根 CA------正是 4.3 节预装在你系统里的那批。看完这个输出，"信任链" 三个字就不再是抽象概念。
6 几个常见疑问
**为什么访问某些网站时，浏览器弹出 "证书不受信任" 的警告？**最常见的原因有三种：证书过期了、证书上的域名和实际访问的域名对不上、或者证书的签发者不在浏览器信任库里。第三种里既有钓鱼网站自签证书的情况，也有公司内网用自建 CA 给内部系统发证书的情况------后者在员工电脑上安装公司根证书后警告即消除。无论哪种，看到警告时正确的反应是停下来核实，而不是点 "继续访问"，因为这个警告正是整套机制在拦截可疑连接。
**HTTPS 加密了 URL 和内容吗？**加密了请求体、Cookie、查询参数这些通信内容。但域名本身仍然要明文出现在建立连接的环节里------你在访问哪个网站，网络中间设备是知道的，这也是家长控制、公司审计能按域名拦截的原理。更准确的说法是：HTTPS 保护通信内容，不隐藏你在跟谁通信。
**HTTP 和 HTTPS 的性能差多少？**现代 CPU 上 AES 加密的开销几乎可以忽略，TLS 1.3 又把握手压到了一个往返，日常浏览感知不到差别。十年前 "全站 HTTPS 会拖慢网站" 的顾虑，今天基本可以放下------这也是各大网站近几年陆续默认全站 HTTPS 的原因。
回到开头那把锁，现在可以完整回答它锁住的是什么了：一把现场商量出来的会话密钥，锁住了内容不被窃听；一份随数据同行的校验码，锁住了内容不被篡改；一条通向系统信任库的证书链，锁住了对面那个人没有被冒充。三道锁全挂上之后，公共 Wi-Fi 旁边的人能看到的只剩一件事：有个人在跟某个网站加密通信。再想往里看一步，就得先破解 AES、或者攻破一家根 CA------前者在现有算力下不现实，后者会葬送一家经营几十年的机构。代价是浏览器地址栏的一把小图标，这笔交换做得很划算。