【网络】SSL/TLS介绍

发布于:2025-07-03 ⋅ 阅读:(21) ⋅ 点赞:(0)

一、SSL/TLS 概述

  • SSL(Secure Socket Layer) : 最初由网景(Netscape)开发,用于在客户端和服务器之间建立安全的加密连接,防止数据被窃取或篡改。后来逐步演进,最终被 TLS 取代。

  • TLS(Transport Layer Security) : TLS 是 SSL 的后继协议,目前已经成为互联网安全通信的标准。它不仅实现了数据加密,还提供了身份验证和数据完整性保护,确保双方通信时的信息保密且未被篡改。

在这里插入图片描述

SSL/TLS协议提供的服务主要有:

  1. 认证用户和服务器,确保数据发送到正确的客户机和服务器;
  2. 加密数据以防止数据中途被窃取;
  3. 维护数据的完整性,确保数据在传输过程中不被改变。

在这里插入图片描述

TLS与SSL的差异
  1. 版本号:TLS记录格式与SSL记录格式相同,但版本号的值不同,TLS的版本1.0使用的版本号为SSLv3.1。
  2. 报文鉴别码:SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用 了相似的算法,两者差别在于SSLv3.0中,填充字节与密钥之间采用的是连接运算,而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
  3. 伪随机函数:TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块,是更安全的方式。
  4. 报警代码:TLS支持几乎所有的SSLv3.0报警代码,而且TLS还补充定义了很多报警代码,如解密失败 (decryption_failed)、记录溢出(record_overflow)、未知CA(unknown_ca)、拒绝访问 (access_denied)等。
  5. 密文族和客户证书:SSLv3.0和TLS存在少量差别,即TLS不支持Fortezza密钥交换、加密算法和客户证书。
  6. certificate_verify和finished消息:SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时,计算的输入有少许差别,但安全性相当。
  7. 加密计算:TLS与SSLv3.0在计算主密值(master secret)时采用的方式不同。
  8. 填充:用户数据加密之前需要增加的填充字节。在SSL中,填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中,填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为255字节),这种方式可以防止基于对报文长度进行分析的攻击。
TLS的主要增强内容

TLS的主要目标是使SSL更安全,并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上,提供了以下增强内容:

  1. 更安全的MAC算法
  2. 更严密的警报
  3. “灰色区域”规范的更明确的定义
TLS对于安全性的改进
  1. 对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认证,但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。
  2. 增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。
  3. 改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。
  4. 一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。
  5. 特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

二、SSL/TLS 协议流程

2.1 对称加密

对称加密是指在加密和解密数据时使用相同的密钥。发送者使用该密钥将明文转换为密文,而接收者则使用同一密钥将密文还原为原始数据。

  1. 加密过程:发送方用密钥 K 加密明文 P,得到密文 C = Encrypt(K, P)
  2. 解密过程:接收方必须用相同的密钥 K 解密密文,得到 P = Decrypt(K, C)

关键点:双方必须共享同一个密钥 K,因此密钥必须从发送方传递给接收方

优点

  • 速度快:对称加密算法通常计算效率高,适合大数据量的加密。
  • 实现简单:算法相对简单,资源占用较少。

缺点

  • 密钥分发问题:双方必须共享同一个密钥,如何安全地传递这个密钥是一个关键问题。如果密钥在传输过程中被截获,数据安全就会受到严重威胁。

2.2 非对称加密

非对称加密(如 RSA、ECC)的核心特性是使用一对关联的密钥公钥(公开)私钥(私密)。在传输密钥时,其逻辑与对称加密完全不同,核心在于:公钥可公开传输,私钥绝不外传,且主要用于安全传输对称加密的密钥

  • 公钥:可以公开给任何人,用于加密数据或验证数字签名。
  • 私钥:仅由持有者保管,用于解密数据或生成数字签名。

优点

  • 安全的密钥分发:无需通过安全渠道传输私密密钥,公钥可以公开分发,极大降低了密钥泄露风险。
  • 数字签名:可以使用私钥生成签名,别人可以用公钥验证数据的完整性和真实性。

缺点

  • 计算速度较慢:相比对称加密,非对称加密在计算上更为复杂,因此通常只用于加密小数据量或者用来交换对称加密所使用的密钥。

常见算法 如 RSA、ECC(椭圆曲线加密)等。

2.3 公钥和私钥

公钥(Public Key)
  • 定义:可以公开传播的密钥,任何人都能获取。
  • 特性
    • 用于加密数据验证数字签名,但无法解密自己加密的内容。
    • 相当于一把 “公开的锁”,任何人都能用这把锁加密信息,但只有持有对应钥匙的人才能打开。
私钥(Private Key)
  • 定义:必须严格保密的密钥,仅由所有者持有。
  • 特性
    • 用于解密公钥加密的数据生成数字签名,是加密体系的安全核心。
    • 相当于 “唯一的钥匙”,一旦泄露,整个加密体系将失效。
公钥的用途
  • 加密数据:发送方用接收方的公钥加密信息,确保只有接收方(持有私钥)能解密。
    (例:HTTPS 中客户端用服务器公钥加密对称密钥)。
  • 验证签名:用于验证某段数据是否由对应的私钥持有者生成(数字签名的核心逻辑)。
私钥的用途
  • 解密数据:解公钥加密的信息,获取原始内容。
  • 生成签名:对数据进行签名,证明数据由私钥持有者发出,且未被篡改(如 SSL 证书签名、Git commit 签名)

2.4 TLS证书

TLS 证书的本质与核心作用
  • 定义:TLS 证书是一种遵循 X.509 标准 的数字文档,用于证明 “网络实体(如服务器、客户端)的身份” 与 “其公钥的合法性”,本质是 公钥与身份的绑定凭证
TLS 证书的关键组成部分(X.509 格式)

一张标准的 TLS 证书包含以下核心字段(以服务器证书为例):

  1. 主体信息(Subject)

    • 证书持有者的身份标识,如域名(www.example.com)、组织名称(企业)、国家 / 地区等。
    • 关键字段Common Name (CN)Subject Alternative Name (SAN),必须与访问的域名严格匹配(如证书 CN 为example.com,无法用于www.example.com,会触发浏览器警告)。
  2. 公钥(Public Key)

    • 服务器用于非对称加密的公钥(如 RSA 2048 位或 ECC 密钥),客户端通过证书获取该公钥。
  3. 颁发机构(Issuer)

    • 签发证书的 CA(Certificate Authority,证书权威机构)名称,如 DigiCert、Let’s Encrypt。
  4. 有效期(Validity)

    • 证书生效的起止时间,过期后客户端会拒绝连接(需重新申请证书)。
  5. 数字签名(Signature)

    • CA 使用自身私钥对证书内容(除签名外的所有字段)进行哈希和加密,形成签名。客户端用 CA 的公钥验证签名,确保证书未被篡改。
  6. 序列号(Serial Number)

    • CA 为证书分配的唯一标识符,用于吊销时标识证书。
证书的颁发流程:CA 如何 “盖章认证”?
  1. 服务器申请证书(CSR 生成)

    • 服务器生成密钥对(公钥 + 私钥),并使用公钥和身份信息生成证书签名请求(CSR),包含域名、组织信息等。
  2. CA 审核与签名

    • CA 对服务器身份进行验证(如域名所有权、企业合法性),审核通过后,用自身私钥对 CSR 内容签名,生成最终的 TLS 证书。
    • CA 的信任基础:CA 的根证书已预装在操作系统、浏览器中(如 Windows、Chrome 内置数百个根 CA 证书),客户端信任 CA 的签名。
  3. 证书分发

    • 服务器将证书部署到服务器端,供客户端在 TLS 握手时获取。

2.5 SSL/TLS 握手过程

TLS(Transport Layer Security,传输层安全)握手是客户端与服务器建立安全通信的核心过程,其目标是:协商加密算法、验证身份、生成共享密钥,确保后续数据传输的机密性和完整性
在这里插入图片描述

第一阶段:客户端发起握手(ClientHello)
  1. 客户端发送的关键信息

    • 版本号:声明支持的 TLS 最高版本(如 TLS 1.2)。
    • 随机数(Client Random):一个 32 字节的随机数,用于后续生成密钥。
    • 密码套件列表:客户端支持的加密算法组合(如TLS_RSA_WITH_AES_256_GCM_SHA384,包含密钥交换算法、对称加密算法、哈希算法)。
    • 扩展字段:可选信息(如 SNI 域名、压缩算法等)。
  2. 核心目的
    告知服务器 “我想建立安全连接,并提供了可选的加密方案”。

第二阶段:服务器响应(ServerHello + 证书 + 密钥交换)
  1. ServerHello 消息

    • 选择版本:服务器从客户端支持的版本中选择最高兼容版本。
    • 随机数(Server Random):另一个 32 字节随机数,与 Client Random 共同构成密钥生成的基础。
    • 选定密码套件:从客户端列表中选择一个具体的加密方案。
    • 扩展字段:返回服务器配置(如证书类型)。
  2. 服务器证书(Certificate)

    • 服务器发送自己的数字证书(含公钥),证书由 CA(证书颁发机构)签名,用于证明服务器身份。
    • 客户端验证证书:检查证书是否过期、CA 是否可信、域名是否匹配(防止中间人攻击)。
  3. 密钥交换相关消息(如 ServerKeyExchange)

    • 若密码套件使用 RSA 等算法,服务器直接在证书中提供公钥;若使用 DH(Diffie-Hellman)等算法,服务器会发送用于密钥协商的参数。
  4. ServerHelloDone
    服务器告知客户端 “握手参数已发送完毕”。

第三阶段:客户端验证与密钥生成
  1. 客户端验证服务器身份

    • 通过服务器证书中的公钥,验证证书签名是否有效(使用 CA 的根公钥),确认服务器合法性。
  2. 生成预主密钥(Pre-Master Secret)

    • 客户端生成一个 48 字节的随机数,用服务器公钥加密(非对称加密),发送给服务器(即ClientKeyExchange 消息)。
    • 只有服务器能用私钥解密该数据,获取预主密钥。
  3. 计算主密钥(Master Secret)

    • 客户端和服务器分别用以下数据生成相同的主密钥:
      Master Secret = PRF(Pre-Master Secret, "master secret", Client Random + Server Random)
      其中 PRF 是伪随机函数,确保输出的密钥随机性。
  4. 生成会话密钥(Session Keys)

    • 主密钥进一步衍生出多组密钥,用于后续通信:
      • 加密密钥:客户端和服务器各一套,用于数据加密。
      • MAC 密钥:用于计算消息认证码(HMAC),确保数据完整性。
第四阶段:密钥验证与握手完成
  1. 客户端发送 ChangeCipherSpec
    告知服务器 “后续通信将使用新协商的加密算法和密钥”。

  2. 客户端发送 Finished 消息

    • 用刚生成的加密密钥,对握手过程中的所有消息哈希值进行加密,发送给服务器(用于验证密钥正确性和握手完整性)。
  3. 服务器响应 ChangeCipherSpec
    确认切换到新的加密机制。

  4. 服务器发送 Finished 消息
    同样用加密密钥对握手消息哈希加密,回传给客户端,完成双向验证。

2.6 握手后的通信

  • 握手完成后,客户端与服务器用对称加密算法(如 AES)和会话密钥进行数据传输,每次通信都附带 HMAC 确保完整性。
  • 非对称加密仅在握手阶段用于密钥交换,避免了大量数据加密的性能损耗。
密钥生成:双方协商,不对外暴露
  • TLS 握手时,对称加密的会话密钥由以下步骤生成(以 RSA 握手为例):
    1. 客户端生成预主密钥(随机数),用服务器公钥加密后发送(此时公钥仅用于保护预主密钥的传输)。
    2. 服务器用私钥解密得到预主密钥,双方再结合各自的随机数(Client Random + Server Random),通过伪随机函数(PRF)生成主密钥(Master Secret)
    3. 主密钥进一步衍生出对称加密所需的会话密钥(如客户端发送密钥、服务器发送密钥等)。

整个过程中,会话密钥的生成依赖于双方的随机数和预主密钥,而预主密钥在传输时被服务器公钥加密,中间人无法破解(因无服务器私钥),因此会话密钥仅双方可知

密钥保密:不公开传输,仅内存持有
  • 会话密钥从未通过网络公开传输,仅存在于客户端和服务器的内存中,用于数据加密 / 解密。
  • 即使网络中截获密文,由于不知道会话密钥,也无法解密数据(对称加密的安全性依赖于密钥的保密性)。

在这里插入图片描述

三、总结

TLS 的安全性与实践要点
  1. 安全增强

    • 前向保密(FS):使用 ECDHE 等算法,即使服务器私钥泄露,历史会话也无法解密。
    • 证书透明度:强制 CA 将证书记录在公开日志,防止伪造证书。
  2. 常见问题

    • 证书过期 / 域名不匹配:浏览器会提示 “连接不安全”,需及时更新证书或确保域名与证书 CN/SAN 一致。
    • 中间人攻击:若 CA 私钥泄露或证书链验证失败,可能导致加密失效,需依赖浏览器内置的根 CA 信任机制防范。
TLS 如何保障安全?

TLS 通过 “非对称加密协商对称密钥,对称加密传输数据,数字证书验证身份” 的三层设计,解决了网络通信中的三大核心问题:密钥安全分发、身份伪造、数据篡改。其混合加密架构既保证了安全性,又通过对称加密的高效性支撑了全球海量的 HTTPS 流量,成为现代互联网安全的基石。

更多资料:https://github.com/0voice


网站公告

今日签到

点亮在社区的每一天
去签到