HTTPS and TLS 1.3 Handshake: Keys, Certificates, and RTT in Practice

HTTPS is fundamentally more than "HTTP over an encrypted channel." It is the cornerstone of modern network security architecture. In TLS 1.3, the handshake is a heavily optimized state machine designed to minimize round-trips while maximizing cryptographic resilience. It rigorously negotiates cryptographic parameters, computes ephemeral shared secrets via elliptic curves, authenticates the server's X.509 identity, and verifies the transcript integrity. Below, we dissect TLS 1.3 at an extreme engineering depth—ranging from Galois field mathematics to OpenSSL's C implementation and eBPF kernel-level profiling.

1. The Architecture of TLS 1.3: 1-RTT and State Machine Overhaul

TLS 1.3 drastically reduced the handshake latency from 2-RTT to 1-RTT by aggressively deprecating obsolete primitives (RSA key transport, SHA-1) and enforcing Forward Secrecy (FS). In the OpenSSL C implementation, this is driven by the state machine inside statem_clnt.c and statem_srvr.c. A client sends a ClientHello containing pre-computed key_share extensions. The server immediately transitions to TLS_ST_SW_SRVR_HELLO, computing the shared secret, and responds with a ServerHello, EncryptedExtensions, Certificate, CertificateVerify, and Finished messages in a single flight.

2. Advanced State Machine & HKDF Visualization

The following diagram expands the 1-RTT flow to highlight the exact stages where the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is applied to generate the Handshake and Application Traffic Secrets.

sequenceDiagram
    autonumber
    participant Client
    participant Server
    
    Client->>Server: ClientHello + Key Share (X25519) + ALPN
    Note right of Server: statem_srvr.c: tls_process_client_hello()
HKDF-Extract(0, ECDHE Shared Secret)
HKDF-Expand(Handshake Secret)
    Server->>Client: ServerHello + Key Share
    Server->>Client: {EncryptedExtensions + Certificate + CertVerify + Finished}
    Note left of Client: statem_clnt.c: tls_process_server_hello()
Derive keys, Verify Signature, Verify Finished MAC
    Client->>Server: {Finished} + [Application Data (HTTP Request)]
    Note right of Server: HKDF-Expand(Master Secret) -> Application Traffic Keys
    Server->>Client: [Application Data (HTTP Response)]

3. Mathematical Rigor: ECDLP and AES-GCM Polynomials

Modern TLS 1.3 deployments rely heavily on Curve25519 for the key exchange and AES-GCM for Authenticated Encryption with Associated Data (AEAD).

Elliptic Curve Discrete Logarithm Problem (ECDLP)

The key exchange leverages the Curve25519 Montgomery curve defined by the equation over a prime field (mathbb{F}_p):

[ v^2 = u^3 + 486662u^2 + u pmod{2^{255} - 19} ]

The security relies on the intractability of the ECDLP: given a base point ( G ) and a public key ( P = dG ), it is computationally infeasible to find the private scalar ( d ). The shared secret is computed as ( S = d_{client} P_{server} = d_{client} d_{server} G = d_{server} P_{client} ). OpenSSL implements this using highly optimized, constant-time Montgomery ladders to prevent timing side-channel attacks.

Galois/Counter Mode (GCM) Mathematics

Once keys are established, AES-GCM encrypts the application records. The authentication tag in GCM is computed using a universal hash function GHASH over the Galois field ( text{GF}(2^{128}) ). The field is defined by the irreducible polynomial:

[ P(x) = x^{128} + x^7 + x^2 + x + 1 ]

Elements of the field are 128-bit blocks. The GHASH function evaluates a polynomial where the coefficients are the ciphertext blocks and the variable is the hash subkey ( H ). In production, this multiplication is massively accelerated using CPU hardware instructions like Intel's AES-NI (specifically the vpclmulqdq instruction for carry-less multiplication).

4. Production Engineering: OpenSSL and Hardware Acceleration

In high-throughput architectures (e.g., terminating 100k+ TLS connections/sec), CPU overhead is the primary bottleneck. Modern edge load balancers bypass generic C implementations and invoke raw assembly. For example, in OpenSSL's evp_cipher API, AES-GCM is routed directly to the AES-NI vector units. Engineers tuning Envoy or Nginx for TLS termination must ensure that the OS CPU flags expose aes, pclmulqdq, and avx512f to the user-space process.

Furthermore, OpenSSL's EVP_DigestSign for ECDSA/RSA certificate signatures is often offloaded to asynchronous cryptographic engines (e.g., Intel QAT) via engine modules, allowing the Nginx event loop to continue serving other epoll events while the hardware computes the ECDLP scalar multiplication.

5. Advanced Tooling: eBPF Traffic Interception

Debugging production TLS issues (like handshake latency spikes or cipher negotiation failures) using TCP dumps is useless since the payload is encrypted. Instead, elite engineers deploy eBPF (Extended Berkeley Packet Filter) to trace OpenSSL dynamically in user-space.

#include <uapi/linux/ptrace.h>
BPF_HASH(start, u32);
BPF_HISTOGRAM(dist);

int probe_ssl_handshake_start(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    start.update(&pid, &ts);
    return 0;
}

int probe_ssl_handshake_return(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 *tsp = start.lookup(&pid);
    if (tsp != 0) {
        u64 delta = bpf_ktime_get_ns() - *tsp;
        dist.increment(bpf_log2l(delta / 1000000)); // Log2 histogram in ms
        start.delete(&pid);
    }
    return 0;
}

By injecting this eBPF program into the libssl.so text segment, SREs can visualize TLS handshake percentiles (p99 latency) without modifying the application code or suffering tcpdump context-switch overhead.

6. Post-mortem: Side-Channel Attack Mitigations

Production environments must harden against side-channel vulnerabilities such as Bleichenbacher attacks, Lucky Thirteen, or cache-timing attacks (e.g., Flush+Reload). TLS 1.3 eliminates many of these by removing RSA encryption (PKCS#1 v1.5 padding) and MAC-then-Encrypt CBC modes. To defend against remaining scalar multiplication timing leaks, libraries use Montgomery Ladders and ensure that branch instructions and memory access patterns are strictly independent of the secret scalar bits.

FAQ

Does the certificate encrypt application records?

No. The X.509 certificate mathematically authenticates the server via a digital signature (e.g., ECDSA over P-256) over the transcript hash, proving ownership of the public key. Encryption of the application layer is exclusively handled by the symmetric AEAD keys derived from the ephemeral ECDHE exchange via HKDF, guaranteeing Forward Secrecy.

Why not implement TLS from scratch?

Production TLS requires constant-time arithmetic to prevent microarchitectural side-channel data leaks. Rolling your own crypto in high-level languages often introduces cache-timing vulnerabilities, branch-prediction leaks, and memory-safety flaws. Always rely on battle-tested, hardware-accelerated libraries like OpenSSL, BoringSSL, or Rustls.

References

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• NIST SP 800-38D: Galois/Counter Mode (GCM)

HTTPS 绝不只是“在 HTTP 外面套一层加密”那么简单。它是现代网络安全架构的基石。在 TLS 1.3 中，握手协议被重构为一个高度优化的状态机，旨在最大化密码学抗性的同时最小化网络往返延迟。它严格协商密码学参数，通过椭圆曲线计算临时共享密钥，验证服务器的 X.509 身份，并校验整个握手 transcript 的完整性。本文将深入工程底层，从伽罗瓦域（Galois field）的数学基础、OpenSSL 的 C 语言源码实现，到内核级的 eBPF 性能追踪，对 TLS 1.3 进行极致剖析。

一、TLS 1.3 架构：1-RTT 与状态机重构

TLS 1.3 通过激进地废弃过时的密码学原语（如 RSA 密钥传输、SHA-1）并强制启用前向安全（Forward Secrecy），将握手延迟从 2-RTT 大幅降低至 1-RTT。在 OpenSSL 的 C 语言实现中，这一切由 statem_clnt.c 和 statem_srvr.c 中的状态机驱动。客户端发送包含预计算 key_share 扩展的 ClientHello。服务器立刻状态转移至 TLS_ST_SW_SRVR_HELLO，计算共享密钥，并在单个 flight 中回传 ServerHello、EncryptedExtensions、Certificate、CertificateVerify 和 Finished 消息。

二、高阶状态机与 HKDF 可视化

下面的时序图展开了 1-RTT 的详细流程，重点标出了基于 HMAC 的密钥派生函数（HKDF）提取（Extract）和展开（Expand）握手与应用流量密钥的具体阶段。

sequenceDiagram
    autonumber
    participant Client as 客户端
    participant Server as 服务端
    
    Client->>Server: ClientHello + Key Share (X25519) + ALPN
    Note right of Server: statem_srvr.c: tls_process_client_hello()
HKDF-Extract(0, ECDHE Shared Secret)
HKDF-Expand(Handshake Secret)
    Server->>Client: ServerHello + Key Share
    Server->>Client: {EncryptedExtensions + Certificate + CertVerify + Finished}
    Note left of Client: statem_clnt.c: tls_process_server_hello()
派生密钥，验证签名，校验 Finished MAC
    Client->>Server: {Finished} + [Application Data (HTTP Request)]
    Note right of Server: HKDF-Expand(Master Secret) -> 应用层流量密钥
    Server->>Client: [Application Data (HTTP Response)]

三、数学严密性：ECDLP 与 AES-GCM 多项式运算

现代 TLS 1.3 生产部署严重依赖 Curve25519 进行密钥交换，以及 AES-GCM 进行认证加密（AEAD）。

椭圆曲线离散对数问题 (ECDLP)

密钥交换使用了 Curve25519 蒙哥马利曲线，该曲线定义在素数域 (mathbb{F}_p) 上的方程为：

[ v^2 = u^3 + 486662u^2 + u pmod{2^{255} - 19} ]

其安全性依赖于 ECDLP 的难解性：已知基点 ( G ) 和公钥 ( P = dG )，在计算上无法反推私有标量 ( d )。共享密钥的计算公式为 ( S = d_{client} P_{server} = d_{client} d_{server} G = d_{server} P_{client} )。OpenSSL 在底层使用了高度优化的、恒定时间（constant-time）的蒙哥马利阶梯算法（Montgomery ladders）来实现，从而杜绝了时间侧信道攻击。

伽罗瓦/计数器模式 (GCM) 的数学原理

密钥协商完毕后，AES-GCM 负责加密应用层记录。GCM 的认证标签（Authentication tag）是基于伽罗瓦域 ( text{GF}(2^{128}) ) 上的通用哈希函数 GHASH 计算出来的。该域由以下不可约多项式定义：

[ P(x) = x^{128} + x^7 + x^2 + x + 1 ]

域中的元素是 128 位的块。GHASH 函数求解的是一个以密文块为系数、以哈希子密钥 ( H ) 为变量的多项式。在生产环境中，这种多项式乘法会被 CPU 硬件指令极大地加速，例如 Intel 的 AES-NI 指令集（特别是用于无进位乘法的 vpclmulqdq 指令）。

四、生产工程：OpenSSL 与硬件加速

在高吞吐量的网关架构中（如每秒终结 10 万个 TLS 连接），CPU 开销是核心瓶颈。现代边缘负载均衡器完全绕过通用的 C 语言实现，直接调用汇编指令。例如，在 OpenSSL 的 evp_cipher API 中，AES-GCM 被直接路由至 AES-NI 向量计算单元。工程师在为 Envoy 或 Nginx 进行调优时，必须确保宿主机操作系统的 CPU 标志位（flags）将 aes, pclmulqdq, 以及 avx512f 暴露给用户态进程。

此外，OpenSSL 中用于 ECDSA/RSA 证书签名的 EVP_DigestSign 函数经常通过 engine 模块被卸载到异步密码学硬件加速引擎（如 Intel QAT）上。这使得 Nginx 的事件循环在硬件计算 ECDLP 标量乘法的过程中，仍能继续处理其他的 epoll 事件。

五、高阶诊断工具：eBPF 流量拦截与追踪

使用 tcpdump 来排查生产环境下的 TLS 问题（如握手延迟毛刺或加密套件协商失败）毫无意义，因为载荷已被加密。相反，顶尖 SRE 会部署 eBPF（扩展的伯克利数据包过滤器）在用户态动态追踪 OpenSSL。

下面是一段 BCC (BPF Compiler Collection) 代码片段，它通过挂载 uprobe 到 OpenSSL 的 SSL_do_handshake 函数，在内核态精准测量握手延迟分布：

#include <uapi/linux/ptrace.h>
BPF_HASH(start, u32);
BPF_HISTOGRAM(dist);

int probe_ssl_handshake_start(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    start.update(&pid, &ts);
    return 0;
}

int probe_ssl_handshake_return(struct pt_regs *ctx) {
    u32 pid = bpf_get_current_pid_tgid();
    u64 *tsp = start.lookup(&pid);
    if (tsp != 0) {
        u64 delta = bpf_ktime_get_ns() - *tsp;
        dist.increment(bpf_log2l(delta / 1000000)); // 以毫秒为单位的 Log2 直方图
        start.delete(&pid);
    }
    return 0;
}

通过将此 eBPF 程序注入 libssl.so 的代码段，SRE 可以直观地监控 TLS 握手的 P99 延迟百分位图，而且完全无需修改应用代码或承受 tcpdump 抓包带来的上下文切换开销。

六、安全复盘：侧信道攻击防御

生产环境必须加固以抵御各种侧信道漏洞，例如 Bleichenbacher 攻击、Lucky Thirteen 或缓存时间攻击（如 Flush+Reload）。TLS 1.3 移除了 RSA 加密（PKCS#1 v1.5 填充）和 MAC-then-Encrypt 的 CBC 模式，从根本上消除了许多此类攻击。为了防御剩余的标量乘法时间泄漏，底层库采用了蒙哥马利阶梯算法，并在代码层面严格保证分支指令和内存访问模式与密钥的标量比特完全无关（恒定时间执行）。

FAQ

证书会用来加密应用层数据吗？

不会。X.509 证书的数学作用是通过数字签名（例如基于 P-256 的 ECDSA）对握手 transcript 杂凑值进行签名，以验证服务器身份并证明对公钥的所有权。应用层数据的加密专属由 ephemeral ECDHE 交换并通过 HKDF 派生出的对称 AEAD 密钥负责，从而保障了前向安全性。

为什么不要从零开始自己写一个 TLS？

生产级别的 TLS 要求极其苛刻的恒定时间（constant-time）算术运算以防止微架构级别的侧信道数据泄漏。在高级语言中“造密码学轮子”经常会引入缓存时间漏洞、分支预测泄漏以及内存安全缺陷。请务必依赖身经百战的、支持硬件加速的开源库，如 OpenSSL、BoringSSL 或 Rustls。

参考资料

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• NIST SP 800-38D: Galois/Counter Mode (GCM)