数字签名、证书与 TLS

上一课留下了一个悬而未决的问题:非对称加密让你能把一个秘密发送给一个你拿到了其公钥的人——但你怎么知道那把公钥真的属于他,而不是属于中间的某个攻击者?数字签名和证书正是用来回答这个问题的,而它们合在一起,让 TLS——每一个 https:// 地址背后的协议——成为可能。

数字签名:证明来源,而不是保密

数字签名把非对称加密反过来用。发送者不是用对方的公钥加密一条消息以便只有对方能读到它,而是用自己的私钥对消息进行签名,任何人都可以用发送者的公钥来验证这个签名。如果验证通过,就有两件事为真:这条消息确实来自持有那把私钥的人,并且之后没有被改动过——上一课讨论哈希时提到的那种抗碰撞性,正是让篡改能被察觉的原因。签名证明的是真实性和完整性;它本身并不能为消息保密。

证书:为一把公钥背书的签名

数字证书解决的是“这到底是谁的公钥”这个问题。正如 Cloudflare 学习中心所解释的,一份 SSL/TLS 证书是“托管在网站源服务器上的一个数据文件”,其中包含域名、公钥、到期日期,以及关键的一点——“证书颁发机构的数字签名”。证书颁发机构(CA)是一个受信任的第三方,它会核实某个网站确实控制着它申请证书所对应的域名,然后用自己的私钥为这份证书签名。你的浏览器内置了一份它信任的 CA 清单,所以当它收到一份由其中某个 CA 签名的证书时,它就可以信任其中的公钥,而完全不需要曾经与该网站的运营者打过交道。自签名证书——网站自己签发而不是从 CA 那里获得的证书——没有这种来自外部的背书,这也是浏览器默认不信任自签名证书的原因。

TLS:让两者协同发挥作用

RFC 8446,也就是 TLS 1.3 的规范文档,把握手过程描述为几个阶段:密钥交换,双方在这一阶段建立共享的秘密材料;然后是身份验证,用该 RFC 的话说,“通道的服务器一侧总是会被验证身份;客户端一侧则是可选的身份验证”——通常只有网站一方证明自己的身份,访问者并不需要。服务器用它的证书,以及只有它才能用私钥生成的签名,来证明自己是谁。一旦双方都信任了这条连接,它们就会派生出速度更快的对称密钥(通常就是上一课讲到的 AES),用于实际数据的传输。RFC 8446 直白地说明了这带来了什么:交换数据的机密性与完整性,以及对服务器的身份验证。它同样直白地指出了一个限度:“TLS 不隐藏它所传输数据的长度”,而诸如你连接到了哪个服务器、以及在什么时间连接这样的元数据,对任何能观察到这条连接的人来说仍然是可见的。

挂锁图标意味着什么,又不意味着什么

一个建立在仿冒域名上的钓鱼网站,完全可能拥有一份合法有效的证书:TLS 验证的是域名,而不是注册这个域名的人的意图。这也是为什么本大学前面讲“攻击是如何展开的”那一课,把一个带着挂锁图标的假登录页面当作真实存在的威胁,而不是一种自相矛盾的说法。