分类
TLS 与传输
本分类下的所有工具与文章，集中在一处。
工具
文章
TLS 密码套件的结构
TLS 密码套件实际命名了什么，如何逐部分阅读像 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这样的套件，以及同一个两字节代码点如何以三种不同的命名约定出现。
阅读读懂密码套件名称：IANA、OpenSSL 和 GnuTLS
为什么同一个密码套件有三个不同的名称和一个两字节代码点，如何在 IANA、OpenSSL 和 GnuTLS 的约定之间互译，以及 IANA 那含 Y、N 和 D 的 Recommended 列究竟意味着什么。
阅读AEAD 对比 CBC：模式为何重要
像 AES-GCM 这样的 AEAD 密码与带单独 HMAC 的较旧 CBC 密码之间的实际差别，终结了 MAC-then-encrypt 的填充预言机攻击，以及 AEAD 至今仍提出的那一个取舍。
阅读前向保密与密钥交换
前向保密保证了什么，为什么静态 RSA 密钥传输不提供它，ECDHE 和 DHE 又如何提供它，以及为什么身份验证和密钥交换是套件名称分开保持的两项不同任务。
阅读TLS 1.3 密码套件：变了什么
为什么一个 TLS 1.3 套件只命名一个密码和一个哈希，密钥交换和身份验证去了哪里，以及为什么套件列表从数百个缩减到寥寥几个。
阅读What a Quantum Computer Would Break, and What It Would Not
A large quantum computer would not weaken all cryptography equally. Shor's algorithm breaks the public-key math behind RSA, Diffie-Hellman, and elliptic curves outright; Grover's algorithm only halves the strength of symmetric ciphers and hashes, which AES-256 and SHA-384 already survive. This explains the split, why 'harvest now, decrypt later' makes it a today problem, and why a broken candidate like SIKE is a reminder to stay humble.
阅读The NIST Post-Quantum Standards: ML-KEM, ML-DSA, and SLH-DSA
In August 2024 NIST finalized the first three post-quantum standards: FIPS 203 (ML-KEM, from Kyber) for key establishment, and FIPS 204 (ML-DSA, from Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) for signatures. This explains what each one is for, why there are two signature standards on different math, and where HQC and FN-DSA fit as the backups still coming down the pipeline.
阅读Hybrid Key Exchange in TLS 1.3: What X25519MLKEM768 Does on the Wire
The web did not swap classical key exchange for post-quantum; it runs both at once. X25519MLKEM768 combines a 1990s elliptic curve with lattice-based ML-KEM-768 in a single TLS 1.3 group, so a break of either still leaves the session secure. This covers why hybrid rather than replacement, the wire format and its size problem, and where deployment stands across browsers, servers, and the middleboxes it breaks.
阅读Inbound TLS: Offload, Bridging, and Passthrough at the Reverse Proxy
A reverse proxy handling inbound HTTPS has three choices for the TLS session: terminate it and send plaintext to the backend (offload), terminate and re-encrypt to the backend (bridging), or forward the encrypted bytes untouched (passthrough). Each trades visibility against confidentiality and cost differently. This explains all three, why the proxy holds the server's certificate, and what SNI and mutual TLS change.
阅读TLS 1.2 vs TLS 1.3 vs DTLS vs QUIC: One Handshake Family, Four Shapes
TLS 1.2 and TLS 1.3 secure a TCP stream, DTLS carries the same guarantees over datagrams, and QUIC absorbs the TLS 1.3 handshake into the transport itself. What each one is, which RFC defines it today, what actually changed between them, and where each one runs.
阅读What Is a JA4 TLS Fingerprint?
How a TLS ClientHello becomes a stable fingerprint of the client software, why JA3 faded once browsers began randomizing extension order, how JA4 fixes that by sorting before hashing, and what JA4 can and cannot tell you.
阅读Why Do We Say SSL When We Mean TLS?
SSL has been prohibited, deprecated, and dead for years - and the industry still sells 'SSL certificates,' configures 'SSL inspection,' and links openssl. The history explains the habit: Netscape's SSL, the political rename to TLS in 1999 (the wire version field still said 3.1), and a quarter century of marketing inertia. Plus the musing the question deserves: what would a protocol-independent name even look like, and do any exist?
阅读