2. TLS/SSL 基础原理：TLS 握手过程、证书链、公钥与私钥、对称与非对称加密
TLS（Transport Layer Security）及其前身 SSL（Secure Sockets Layer）是保障网络通信安全的核心协议。在 Exporter 安全加固场景中，启用 TLS 加密是防止中间人攻击、数据窃听和篡改的第一道防线。本节从密码学基础出发，逐步拆解 TLS 的核心组件与握手流程。
2.1 对称加密与非对称加密
TLS 协议同时使用了两种加密体系：非对称加密用于密钥交换和身份验证，对称加密用于实际数据传输。两者的核心差异如下表所示：
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 通信双方共享同一个密钥 | 每个实体拥有一对密钥（公钥 + 私钥） |
| 加密速度 | 快（适合大量数据） | 慢（比对称加密慢 100~1000 倍） |
| 典型算法 | AES、ChaCha20、3DES | RSA、ECDSA、Ed25519 |
| 密钥分发 | 需要安全通道传递密钥 | 公钥可公开，私钥本地保管 |
| 主要用途 | 批量数据加密 | 密钥交换、数字签名、身份认证 |
关键理解：TLS 并非直接使用非对称加密传输所有数据，而是利用非对称加密安全地协商出一个临时的对称密钥（Session Key），后续通信全部使用对称加密。这种混合设计兼顾了安全性与性能。
2.2 公钥与私钥
非对称加密的核心是密钥对（Key Pair）：
- 私钥（Private Key）：必须严格保密，由所有者保管。用于解密、签名。
- 公钥（Public Key）：可以公开发布，用于加密、验签。
在 Exporter 场景中，服务端持有私钥，客户端使用服务端的公钥加密预主密钥（Pre-Master Secret），只有持有对应私钥的服务端才能解密。这种机制确保了即使公钥被中间人获取，也无法解密通信内容。
运维提示：私钥文件（通常为
server.key）必须设置 600 权限，并定期轮换。公钥证书（server.crt）可公开，但需防篡改。
2.3 证书链（Certificate Chain）
公钥本身无法解决“公钥属于谁”的问题。证书链通过层级信任模型解决了身份绑定：
- 根证书（Root CA）：自签名，是信任锚点。浏览器/操作系统内置了约 100~150 个根证书。
- 中间证书（Intermediate CA）：由根证书签发，用于分担根证书风险。根证书离线存储，中间证书用于日常签发。
- 服务器证书（Leaf/Server Certificate）：由中间证书签发，绑定域名或 IP，包含公钥、有效期、Subject 等信息。
常见错误：部署 Exporter 时只配置服务器证书而缺少中间证书，导致部分客户端（如 curl、Prometheus）报错
certificate signed by unknown authority。必须将服务器证书与中间证书拼接为完整证书链文件。
2.4 TLS 握手过程
TLS 握手是客户端与服务器在传输应用数据前，协商加密参数、验证身份、生成会话密钥的过程。以最常用的 TLS 1.3 为例，握手仅需 1-RTT（一次往返），相比 TLS 1.2 的 2-RTT 显著降低了延迟。
以下是 TLS 1.3 完整握手的主要步骤：
| 步骤 | 方向 | 内容 | 说明 |
|---|---|---|---|
| 1 | Client → Server | ClientHello | 支持的 TLS 版本、密码套件、随机数、Key Share（公钥） |
| 2 | Server → Client | ServerHello + 证书 + 完成 | 选定密码套件、服务器随机数、证书链、签名验证、Key Share |
| 3 | Client → Server | Finished | 客户端验证证书，计算并发送会话密钥确认 |
| 4 | — | 握手完成 | 双方开始使用对称加密传输应用数据 |
核心安全机制：在步骤 2 中，服务器必须提供由受信任 CA 签发的证书链。客户端验证证书链的合法性、域名匹配性、有效期和吊销状态。任何一环失败，握手立即终止。
2.5 密码套件（Cipher Suite）
密码套件是 TLS 握手中协商的一组算法组合，决定了密钥交换、身份验证、对称加密和完整性校验的方式。一个典型的密码套件格式如下：
TLS_AES_128_GCM_SHA256
│ │ │
│ │ └── 哈希算法（用于 PRF 和 HMAC）
│ └── 对称加密算法 + 模式（AES-128-GCM）
└── 协议版本（TLS 1.3 固定前缀）在 Exporter 部署中，推荐优先使用以下密码套件：
- TLS_AES_128_GCM_SHA256：性能与安全均衡，硬件加速友好
- TLS_AES_256_GCM_SHA384：更高安全强度，适合合规要求严格的场景
- TLS_CHACHA20_POLY1305_SHA256：移动端或无 AES 硬件加速环境下的首选
安全红线：禁止在 Exporter 中启用 TLS 1.0 / 1.1 以及以下弱密码套件：
TLS_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、所有包含 RC4、3DES、EXPORT 的套件。这些算法已被证明存在严重漏洞。
2.6 证书验证与信任模型
客户端验证服务器证书时，执行以下检查链：
- 证书链验证：从叶子证书逐级向上，验证每个证书的签名是否由上一级 CA 的私钥签发，直到信任的根证书。
- 域名匹配：检查证书的 Subject Alternative Names (SAN) 是否包含客户端访问的域名或 IP。
- 有效期检查：确认当前时间在证书的
notBefore和notAfter之间。 - 吊销状态检查：通过 CRL（证书吊销列表）或 OCSP（在线证书状态协议）确认证书未被吊销。
Exporter 实践：在 Prometheus 配置中，可以通过
tls_config 的 insecure_skip_verify: true 跳过证书验证（仅限测试环境）。生产环境必须配置 ca_file、cert_file、key_file 实现双向 TLS（mTLS）认证。