TLS知识学习

TLS知识学习

前言

工作中接触TLS比较多,也是踩了很多的坑,虽然现在AI已经很方便了,知识完全没有门槛,但是还是记录一下做个总结。

TLS简介

TLS(Transport Layer Security)是建立在TCP之上的一层安全加密通道,主要用于实现会话过程中的加密、完整性保护、身份验证、防中间人攻击。

基于TLS的概念,还有以下扩展:

  1. HTTPS:在TLS之上跑http协议
  2. DTLS:在UDP之上提供加密通道

在一般的TCP/IP模型中,TLS位于传输层。

TLS解决了什么场景下的什么问题

从简介可以看到TLS在密码学领域主要提供了加密、完整性保护、身份验证、防中间人攻击的能里,结合一些场景展开一下,还有一些跟密码学无关的,比如防重放、会话复用等能力,就不过多展开了。

加密

Alice在课堂上想给Bob传纸条,怎么避免中间经手的人偷窥纸条的内容,就涉及到对纸条内信息的加密。

加密是一个很古老的课题,在古代有密码本、规则替换、位移算法,再到一二战时通过各种机械加密,再到计算机诞生后出现的DES/AES等算法,但它们都有一个巨大的问题——都属于对称加密,即加解密双方需要持有相同的秘钥,在我们这个例子中Alice和Bob想要加密通信,就必须提前通过带外的方式约定好一个秘钥,不然如果秘钥被中间经手人截获就毫无意义。

但在现在互联网的场景中,是不可能给每一对参与者都提前约定好秘钥的,这里就必须提到加密算法的里程碑——非对称加密诞生,在非对称加密中,有公钥和私钥两个概念,其中私钥自留,公钥可完全公开,使用公钥加密,使用私钥解密。

在这个例子中,Bob可以将自己的公钥传递给Alice,Alice通过公钥对纸条内容加密后传递给Bob,Bob使用私钥就可以完成解密,实现了一次0前置信息的加密纸条传递。

TLS中通过RSA和ECC两种非对称加密算法,来实现秘钥的协商,他们分别利用了数学上的大整数质因数分解难题与椭圆曲线离散对数难题,这里就不展开了,感兴趣可以自己搜下。

完整性保护

还是Alice和Bob传纸条的场景,加密解决了“别人看不懂内容”的问题,但又会出现新的漏洞:中间人就算无法破译纸条内容,也可以恶意涂改、删减、增加纸条上的密文内容。Bob收到被篡改的纸条,解密后会得到错误信息,但根本无法察觉内容被动过手脚,这就是数据完整性缺失的风险。

无论是早期的简单加密规则,还是传统的对称、非对称加密算法,核心作用都只局限于数据加解密,无法校验数据是否被篡改。在互联网传输场景中,数据包经过多个节点转发,极易出现网络丢包、链路干扰导致的内容错乱,或是恶意人员的篡改攻击,单纯的加密完全不足以保障通信安全。

为了解决这个问题,密码学中引入了摘要校验的思路。简单来说,就是Alice写完纸条后,根据纸条全文内容,生成一段独一无二的“校验指纹”,把指纹和纸条一起发给Bob。中间人一旦修改纸条的任何一个字、一个符号,重新生成的指纹就会和原指纹完全不符。Bob收到内容后,只需要根据收到的纸条内容重新计算指纹,和原始指纹对比,就能瞬间判断内容是否被篡改。

对应到密码学中,这个“校验指纹”就是哈希摘要。常见的MD5(已经不安全)、SHA-256等哈希算法,都能实现任意长度数据映射成固定长度摘要的效果,且具备极强的雪崩效应——数据微小改动,摘要完全变化,无法逆向推导、无法篡改伪造。

但普通哈希摘要仍有漏洞,中间人可以同时篡改数据和哈希值,绕过校验。因此TLS中采用了HMAC哈希消息认证码,结合密钥生成校验摘要,只有持有合法密钥的通信双方才能生成、校验有效指纹。即便中间人篡改了传输数据,也没有密钥生成匹配的摘要,篡改行为会被直接识别。TLS通过这套机制,全程保障传输数据的完整性,杜绝数据篡改、数据错乱问题。

身份验证

解决了数据被偷窥、被篡改的问题后,依然存在核心安全隐患:Bob根本无法确定发加密纸条的人,真的是Alice。

继续沿用传纸条的场景:中间人可以拦截Bob对外公开的公钥,伪装成Alice的身份,用Bob的公钥加密虚假信息,发送给Bob。Bob解密后看到加密内容,默认是Alice发送的,就会轻信虚假信息。同理,Alice也无法确认自己通信的对象是真实的Bob,有可能全程都在和伪装者通信,这就是通信双方身份不可信的问题。

单纯的公私钥加密体系,只能保证数据传输安全,无法对公钥持有者的身份做背书。公钥是公开传播的,任何人都可以生成一对公私钥冒充他人,在海量的互联网通信场景中,用户和服务器互不相识,没有身份校验机制,所有加密通信都可能是虚假对接。

针对这个问题,密码学引入了数字签名机制,实现身份唯一性校验。和加密逻辑相反,数字签名是私钥签名,公钥验签:通信方用自己专属的私钥对数据摘要进行签名,任何人都可以用对应的公钥验证签名有效性,但只有本人持有私钥,无法被他人伪造。

在TLS通信中,单纯的数字签名还不够,依旧存在公钥冒充风险,因此TLS引入了CA数字证书体系。服务器不会直接裸奔传输公钥,而是将自己的域名、公钥、身份信息提交给权威CA机构认证,由CA用根私钥签名生成合法证书。

客户端通信时,会先获取服务器证书,通过内置的CA根证书逐级校验证书签名合法性、有效期、域名匹配性。只要证书校验通过,就证明当前对接的服务器是真实可信的,而非伪装的中间人。通过这套证书+签名的机制,TLS完美实现了通信双方的身份验证,杜绝身份伪造问题。

防中间人攻击

中间人攻击是TLS通信中最隐蔽、危害最大的攻击方式,也是前面加密、完整性、身份校验机制需要联动防御的核心场景,我们依旧用传纸条的完整链路来梳理。

在没有任何防护的原始链路中,中间人可以全程介入Alice和Bob的通信:Bob公开公钥时,中间人拦截Bob的真实公钥,把自己伪造的公钥发给Alice;Alice用伪造公钥加密纸条内容发送后,中间人拦截数据,用自己的私钥解密查看、篡改内容,再用Bob的真实公钥重新加密,转发给Bob。

整个过程中,Alice和Bob全程无感知,双方都以为在和对方直接通信,数据加密、完整性校验看似正常,但所有数据都已被中间人窃取、篡改,这就是完整的中间人劫持攻击。

前面提到的非对称加密、普通哈希校验,都无法防御这种攻击。因为攻击的核心不是破解加密算法、篡改数据内容,而是篡改了公钥分发链路,伪造了通信身份,从源头劫持了通信链路。

而TLS的核心价值之一,就是通过成熟的证书信任体系彻底堵死这个漏洞。TLS不再依赖裸公钥传输,所有合法服务器的公钥都被权威CA证书绑定背书,证书具备不可伪造、不可篡改、可公开校验的特性。

当中间人尝试劫持公钥、替换证书时,客户端会发现对方提供的证书没有权威CA签名、域名不匹配、证书过期或非法,会直接判定通信不安全,终止本次连接,拒绝数据传输。同时,TLS握手过程中会完成完整的证书链校验、签名校验、会话密钥安全协商,确保整个通信链路的对接双方真实有效,没有中间劫持者。

除此之外,新版TLS协议还加入了OCSP Stapling、证书透明度等辅助机制,进一步防止证书伪造、吊销证书复用等风险,全方位防御中间人劫持攻击,保障整个通信链路的端到端安全。

但是换言之,如果中间人提供了“可信”的CA,就完全可以劫持链路,这在大企业中是一种常见的场景,比如我司,所有的PC实际都安装了公司签发的根,所有的TLS流量实际都会被网关劫持。

TLS中的一些概念

CA

CA,全称数字证书认证机构,是整个互联网可信体系的核心第三方权威机构。

还是沿用之前传纸条的例子,公钥本身可以随意生成、随意发送,任何人都能伪造一份假公钥冒充别人,单纯依靠公钥完全没有可信度。

这就好比每个人都可以自己随便写一张身份证,上面的名字、信息随便填,根本没法辨别真假,而 CA 就相当于国家公安局,负责统一颁发、认证合法身份证。

服务端会将自己的域名、公钥、企业信息提交给 CA 审核,审核通过后,CA 会用自己的根私钥进行签名,生成一张合法的数字证书。

客户端设备出厂或系统安装时,会内置全球可信的 CA 根证书列表。当我们访问 HTTPS 网站时,会拿到对方的证书,利用内置根证书层层验签,确认证书没有被篡改、域名匹配、在有效期内。只有 CA 背书过的证书才会被信任,非法伪造、私自签发的证书会直接被拦截。依靠 CA 构建的信任链,才让公钥体系真正落地,成为互联网安全通信的基石。

如果设备是没有更新CA根能力的设备,就会出现一种问题——根证书到期,即未在根证书到期前刷新本地的信任根,导致业务失效。

算法套件

TLS 握手过程中,需要协商加密算法、摘要算法、密钥交换算法等一整套组合,这套打包好的算法组合,就是密码套件(Cipher Suite)

一次完整的 TLS 通信,不能只靠单一算法:密钥交换需要非对称算法、传输加密需要对称算法、完整性校验需要哈希算法,不同场景需要搭配不同组合。

算法套件会明确约定整条链路使用的规则,比如采用 RSA 还是 ECC 做密钥协商、使用 AES 还是 SM4 做数据加密、搭配 SHA256 还是 SHA384 做摘要校验。

不同的 TLS 版本、客户端与服务端环境,支持的套件也不一样。握手阶段双方会互相发送自身支持的算法列表,按照优先级比对,协商出双方都兼容、安全性最高的一套套件。老旧、脆弱的加密算法套件会随着安全漏洞曝光被逐步淘汰,比如早期的 DES、RC4 等弱算法。日常运维中,关闭弱加密套件、优先启用高强度套件,是提升 TLS 安全性最基础的操作。

TLS1.2/1.3和SSL

SSL 是早期的安全通信协议,先后经历 SSL1.0、SSL2.0、SSL3.0 多个版本。

由于设计缺陷、加密漏洞过多,SSL 整套协议早已被全面淘汰,存在严重安全风险,现在所有标准业务都禁止使用 SSL。

为了修复 SSL 的各类安全问题,行业在

SSL3.0 的基础上迭代升级,推出了 TLS 协议,本质可以理解为 SSL 的安全升级版。

日常口语中大家常说的 SSL 证书、SSL 卸载,只是历史叫法,实际运行的都是 TLS 协议。

目前最主流的两个版本就是 TLS1.2TLS1.3

TLS1.2 兼容性极强,几乎兼容所有老旧设备、浏览器和业务系统,部署简单、生态成熟,是现阶段使用最广泛的版本,但握手流程繁琐、网络延迟偏高,部分老旧套件存在安全隐患。TLS1.3 是最新的标准化版本,做了大幅精简优化:缩短握手交互次数,由原来的多轮交互简化为 1-RTT 甚至 0-RTT,大幅提升访问速度;同时直接剔除所有弱加密算法、不安全协商逻辑,安全性更强。

交互流程介绍

TLS在TCP完成握手之后进入TLS握手。

这里展开两种模式——有证书的和没证书的。

基于证书

基于证书的交互,先验身份、再建加密通道,同时兼顾防篡改、防中间人劫持,安全性最高,也是主流落地方案。

基于ECDHE算法

ClientHello

客户端携带 TLS 版本、套件、客户端随机数、椭圆曲线参数。

ServerHello

服务端确认算法套件、TLS 版本,返回服务端随机数。

下发证书 + 签名

服务端携带合法 CA 证书,同时用自身私钥,对临时 ECC 公钥做数字签名。

证书 & 签名校验

客户端校验证书合法性,再用服务端公钥验签,确保临时公钥未被篡改。

交换临时公钥

两端互相交换各自生成的临时 ECDHE 公钥

协商共享密钥

双方基于本地私钥 + 对方临时公钥,通过椭圆曲线算法,各自算出一致的共享秘密。

会话密钥衍生

结合两端随机数,衍生出最终业务对称加密密钥。

发送 Finished 校验报文,切换加密通道,握手结束。

基于RSA算法

ClientHello

客户端发送:支持的 TLS 版本、加密套件列表、随机数Client Random、会话参数。

ServerHello

服务端选定协商版本、加密套件,返回Server Random

服务端下发证书

携带自身 RSA 公钥证书,证明身份。

证书校验

客户端验证 CA 签名、域名、有效期,确认证书合法。

密钥交换(核心)

客户端随机生成预主密钥 Pre-Master Key,使用服务端 RSA 公钥加密,发送给服务端。

解密 & 密钥推导

服务端用本地 RSA 私钥解密,拿到 Pre-Master Key。两端通过「客户端随机数 + 服务端随机数 + 预主密钥」,各自计算出相同的会话密钥

切换加密

两端发送 ChangeCipherSpec、Finished 报文,校验握手完整性。 握手完成,后续业务流量使用对称密钥加密传输。

基于PSK

不需要 CA 证书、不需要非对称算法,依赖通信双方提前约定好一段固定密钥

ClientHello

客户端携带支持的 PSK 套件、预共享密钥标识。

ServerHello

服务端匹配对应 PSK 标识,确认使用 PSK 模式通信。

身份认证

双方通过提前线下约定好的预共享密钥完成身份互认,无证书校验。

会话密钥派生

基于固定 PSK + 两端随机数,直接衍生出本次会话的加密密钥。 完整性校验、切换加密状态,握手完成。

证书链校验

普通校验

设备预制根证书,服务端在握手时发送除根以外的完整的证书链,设备使用根证书一层一层的校验合法性,最终校验服务端身份的有效性。

交叉证书链

交叉证书为了解决一个场景:服务端切换证书,但设备端暂时还无法切换证书

这时候拿一套证书文件M,同时由根1和根2签发生成证书M1和证书M2,证书校验传递证书链时都带上,这样证书链就有两条校验路径。