Security+ Academy · 课时

TLS 版本、密码套件与完全前向保密

Q: 「TLS 版本、密码套件与完全前向保密」这节课中我会学到什么？

配置 TLS 1.2/1.3，选择强密码套件并启用完全前向保密，确保捕获的流量无法被事后解密。 你通过在浏览器中直接运行的动手代码来练习 Security+ Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

配置 TLS 1.2/1.3，选择强密码套件并启用完全前向保密，确保捕获的流量无法被事后解密。

TLS 版本、密码套件与完全前向保密 是 CoddyKit 上的免费 Security+ Academy 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Security+ Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Security+ Academy 课程共包含 4 节课。

TLS 协议概述

TLS（传输层安全）是一种保护大多数互联网通信的加密协议——HTTPS、SMTPS、IMAPS、LDAPS 和 VPN 都依赖 TLS。TLS 提供三种安全属性：机密性（加密可防止窃听）、完整性（MAC 可防止篡改）以及身份验证（证书可验证服务器身份）。TLS 源自 SSL（安全套接字层），后者现已弃用。目前的版本是 TLS 1.2（已广泛部署）和 TLS 1.3（速度更快且更安全，建议所有新部署使用）。

TLS 版本历史与弃用情况

TLS 经历了多个版本，较旧的版本包含严重漏洞。SSL 2.0/3.0：已弃用，容易受到 POODLE 和 DROWN 攻击。TLS 1.0：于 2020 年被 NIST 和 PCI-DSS 弃用（容易受到 BEAST 攻击，以及针对块密码的 POODLE 攻击）。TLS 1.1：与 TLS 1.0 一同弃用。TLS 1.2：当前最低标准；使用强密码套件并正确配置时是安全的。TLS 1.3：于 2018 年发布；移除了所有弱算法，强制使用前向保密，显著加快握手速度（1-RTT，而不是 2-RTT），并可防止降级攻击。PCI-DSS 4.0 要求最低使用 TLS 1.2，并建议使用 TLS 1.3。

# TLS version timeline
SSL 2.0   1995  DEPRECATED (DROWN)
SSL 3.0   1996  DEPRECATED (POODLE)
TLS 1.0   1999  DEPRECATED 2020 (BEAST, POODLE)
TLS 1.1   2006  DEPRECATED 2020 (no improvements over 1.0)
TLS 1.2   2008  MINIMUM STANDARD (strong ciphers required)
TLS 1.3   2018  RECOMMENDED (mandatory PFS, faster, secure)

# Check which TLS versions a server supports
nmap --script ssl-enum-ciphers -p 443 example.com
# Or:
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

密码套件

密码套件是一组在 TLS 会话中配合使用的加密算法。每个密码套件都指定：密钥交换算法（如何建立会话密钥）、身份验证算法（如何验证服务器）、批量加密算法（使用什么算法加密数据），以及消息身份验证码（MAC）算法（如何验证完整性）。客户端和服务器会在 TLS 握手期间协商要使用的密码套件——服务器会选择双方都支持的最强套件。

# TLS cipher suite naming format (TLS 1.2)
# TLS_[KeyExchange]_WITH_[Cipher]_[MAC]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  ECDHE     = Elliptic Curve Diffie-Hellman Ephemeral
  RSA       = Server certificate authentication
  AES_256_GCM = 256-bit AES in Galois/Counter Mode
  SHA384    = HMAC with SHA-384 for integrity

# TLS 1.3 simplified format (fewer components)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

密钥交换算法

密钥交换阶段会建立会话密钥，但不会传输该密钥。RSA 密钥交换（TLS 1.2）：客户端使用服务器的公钥加密预主密钥——如果私钥之后遭到泄露，过去的所有会话都可能被解密。DHE（Diffie-Hellman Ephemeral）：为每个会话生成新的密钥对；可提供前向保密，但速度较慢。ECDHE（Elliptic Curve DHE）：使用更小的密钥长度和更高的性能，实现与 DHE 相同的前向保密——这是 TLS 1.2 和 TLS 1.3 中首选的密钥交换方式。TLS 1.3 强制使用 ECDHE 或 DHE，完全移除了 RSA 密钥交换。

完美前向保密（PFS）

完美前向保密（PFS）可确保即使服务器的长期私钥之后遭到泄露，也无法解密过去记录的会话。PFS 通过使用临时密钥交换（ECDHE 或 DHE）实现：每个会话都会生成一对新的临时密钥，并在使用后丢弃。如果没有 PFS（RSA 密钥交换），攻击者可以在今天记录所有加密的 TLS 会话，等到最终获取私钥后再对这些会话进行追溯解密。NSA 的“先收集、后解密”监控策略假定目标最终会升级到更强的密钥，或者量子计算机会破解当前的密钥。

# Cipher suites WITH perfect forward secrecy
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     # Good
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   # Good
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256        # OK (slower)

# Cipher suites WITHOUT perfect forward secrecy
TLS_RSA_WITH_AES_256_CBC_SHA256  # NO PFS - avoid
TLS_RSA_WITH_3DES_EDE_CBC_SHA    # NO PFS + weak

# Key: look for ECDHE or DHE prefix
# RSA alone as key exchange = no forward secrecy

应避免使用的弱密码算法

一些旧版密码组件在密码学上已经失效，必须禁用。NULL 密码：完全不进行加密。导出级密码（FREAK 攻击）：为遵守 20 世纪 90 年代 US 的出口法规而被刻意削弱。RC4：带有统计偏差的流密码，这些偏差可被攻击利用。DES 和 3DES：块大小过小（SWEET32 攻击）或密钥长度不足的块密码。用于 MAC 的 MD5 和 SHA-1：存在碰撞漏洞。匿名密码（aNULL）：不验证服务器身份。现代 TLS 配置应仅允许将 AES-GCM、ChaCha20-Poly1305、AES-CCM 用作批量密码。

# nginx: disable weak ciphers, enforce strong only
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:
             ECDHE-RSA-AES256-GCM-SHA384:
             ECDHE-ECDSA-CHACHA20-POLY1305:
             ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES128-GCM-SHA256:
             ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;

# Explicitly disable weak ciphers in Apache
SSLCipherSuite 'HIGH:!aNULL:!MD5:!3DES:!RC4:!EXPORT'

TLS 1.3 的改进

TLS 1.3 相比 1.2 实现了多项重要的安全改进。强制使用 PFS：移除 RSA 密钥交换，所有会话都使用 ECDHE 或 DHE。更少的密码套件：仅允许使用 5 个 AEAD 密码套件，不可能协商使用弱密码。更快的握手：TLS 1.2 需要 2 次往返，而 TLS 1.3 只需 1 次往返（1-RTT）；恢复会话时还可使用 0-RTT（但 0-RTT 存在重放攻击方面的考量）。加密的握手：服务器证书会在握手期间加密，从而防止被动观察者识别客户端正在连接的证书（进而识别所访问的网站）。

# TLS 1.3 handshake (simplified)
Client -> Server: ClientHello (supported ciphers, key shares)
Server -> Client: ServerHello (chosen cipher, key share)
                  {EncryptedExtensions}
                  {Certificate}
                  {CertificateVerify}
                  {Finished}
Client -> Server: {Finished}

# Both sides now have session keys
# Total: 1 round-trip before application data
# (TLS 1.2 required 2 round trips)

# Note: {} = encrypted (cert is hidden from observers)

降级攻击与 POODLE

降级攻击会诱使 TLS 服务器和客户端使用双方都支持的较旧、较弱的 TLS 版本或密码套件。POODLE（Padding Oracle On Downgraded Legacy Encryption，降级旧版加密上的填充预言机）利用了 TLS 实现会在连接错误时回退到 SSL 3.0 这一事实。缓解措施是禁用 SSL 3.0。FREAK 和 Logjam 利用了导出级密码。TLS_FALLBACK_SCSV 是一种伪密码套件，客户端会将其包含在请求中，以表示“这不是我的首选版本”——如果服务器看到它且支持更高版本，就会中止降级尝试。

证书验证与固定

TLS 服务器身份验证依赖客户端将服务器的证书链追溯至受信任的根 CA。关键检查包括：有效期（证书必须处于有效期内）、吊销状态（CRL 或 OCSP 检查确认证书未被吊销）、主机名（SAN 或 CN 必须与要连接的域名匹配），以及签名链（中间 CA 和根 CA 的签名必须有效）。Certificate Transparency（CT）要求所有公开受信任的证书都记录在只能追加的 CT 日志中，从而能够在证书签发后的几分钟内发现错误签发的证书。

# Check TLS certificate details
openssl s_client -connect example.com:443 \
  -showcerts 2>/dev/null | openssl x509 -noout \
  -text | grep -E 'Subject:|Issuer:|Not After:|SAN'

# Verify certificate chain
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \
  server.crt

# Check OCSP status
openssl ocsp -issuer intermediate.crt \
  -cert server.crt \
  -url http://ocsp.ca.example.com \
  -text -noverify

SSL Labs 与配置测试

Qualys SSL Labs（ssllabs.com/ssltest）是评估 Web 服务器 TLS 配置的黄金标准工具。它会根据以下因素对服务器从 A+（优秀）到 F（存在严重问题）进行评级：支持的 TLS 版本、密码套件强度、证书有效性、HSTS 配置、前向保密支持情况，以及抵御已知攻击的能力。要获得A+ 评级，必须满足：仅使用 TLS 1.2 及更高版本、使用所有 ECDHE 密码、证书有效，以及启用带预加载的 HSTS。组织应在初始配置完成后运行 SSL Labs 测试，并在 TLS 协议栈发生任何更改后再次运行。许多合规框架（PCI-DSS）要求定期评估 TLS 配置。

TLS 证书管理最佳实践

过期的 TLS 证书会导致服务中断和用户信任警告，攻击者可能利用这些问题。证书生命周期管理包括：在证书清单中跟踪所有证书；至少在到期前 30 天配置到期提醒；使用 ACME 协议（Let's Encrypt、Certbot）自动续期；使用较短的证书有效期（公共证书为 90 天），缩短证书遭到泄露后的风险窗口；以及谨慎使用通配符证书（*.example.com），因为通配符证书一旦泄露，会影响所有子域名。证书管理平台（Venafi、DigiCert CertCentral）可以在大型证书清单中自动完成发现和生命周期管理。

# Auto-renew Let's Encrypt cert with Certbot
# Install Certbot
apt install certbot python3-certbot-nginx

# Issue certificate
certbot --nginx -d example.com -d www.example.com

# Certbot auto-renewal (runs twice daily via systemd timer)
systemctl status certbot.timer

# Test renewal without actually renewing
certbot renew --dry-run

# Verify cert expiry date
openssl x509 -enddate -noout -in /etc/ssl/certs/example.crt
# Output: notAfter=Feb 20 12:00:00 2025 GMT

快速 Check

测试您对本课 CompTIA Security+ (SY0-701) 概念的理解。

课程回顾

在本课中，您学习了：TLS 1.0/1.1 已弃用，TLS 1.2 是最低标准，而 TLS 1.3 因强制使用 PFS 和加密握手而成为首选；密码套件会指定密钥交换（首选 ECDHE）、批量加密（AES-GCM、ChaCha20）和 MAC 算法；完美前向保密要求使用临时的（DHE/ECDHE）密钥交换，因此即使密钥遭到泄露，也无法解密过去的会话。接下来，我们将探索安全 DNS：DNSSEC 和基于 HTTPS 的 DNS。

常见问题解答

「TLS 版本、密码套件与完全前向保密」课时是免费的吗？

是的 — 「TLS 版本、密码套件与完全前向保密」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Security+ Academy 课程的其余内容，请升级到 CoddyKit PRO。 Security+ Academy 课程共包含 4 节课。

「TLS 版本、密码套件与完全前向保密」这节课中我会学到什么？

配置 TLS 1.2/1.3，选择强密码套件并启用完全前向保密，确保捕获的流量无法被事后解密。你通过在浏览器中直接运行的动手代码来练习 Security+ Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Security+ Academy 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Security+ Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「TLS 版本、密码套件与完全前向保密」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Security+ Academy 课中编写并运行代码吗？

能。每节 Security+ Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Security+ Academy