安全与隐私moserware.com编辑精选
HTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
2009 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。它用细粒度的叙事把抽象的加密协议变成可追踪的步骤。
为什么经久不衰：它把日常 HTTPS 握手拆成清晰可读的逐帧过程，而评论中对 RSA 签名验证的纠错也提醒读者协议细节的重要性。
HN 评论精选
验证 RSA 签名必须逐字节比较重建的完整块，不能只比对末尾哈希。
这是一篇好文章。但不幸的是，它具体描述了如何错误地验证 PKCS RSA 签名，延续了一个几年前坑过浏览器厂商的错误。具体来说：验证时你恰恰不能只看 RSA 块末尾的 SHA-1 哈希并把它与自己算出的哈希比较，因为 RSA 算法可能产生无数其他 RSA 块，其中可以包含攻击者选定的 SHA-1 块。厂商们吃了苦头才学会：要验证 RSA 签名，必须重建你期望看到的完整 m 块，并将其与证书中“解密”得到的完整 m 块逐字节比较。密码学真难搞。
tptacek查看英文原文
This is a fine article. Unfortunately, it describes very specifically how not to verify an PKCS RSA signature, perpetuating a mistake that screwed over browser vendors a couple years back: http://www.matasano.com/log/558/public-key-signature-forgery-collected/ To wit: you verify specifically cannot look at the SHA-1 hash at the end of an RSA block and compare it to your own hash, because there are hundreds of zillions of other RSA blocks that can result from the RSA algorithm that could contain a SHA-1 block of an attacker's choosing. Vendors learned the hard way that to verify an RSA signature, you have to reconstruct the entire m block you'd expect to see, and byte compare it to the entire "decrypted" m block from the certificate. Crypto sucks.
SPDY 通过 TLS NPN 在握手阶段协商协议，凸显最初几毫秒的关键作用。
除此之外，随着 SPDY 的出现，最初这几毫秒变得更加重要。因为 SPDY 需要服务器和客户端进行某种协商以确认双方都支持该协议，这给首个请求带来一个问题：在还没看到服务器响应之前，你怎么知道它支持 SPDY？注意，普通的 HTTP Accept 协商不够，因为浏览器应该在看到响应前就已经流水线发出多个请求。由于 SPDY 设计者也认为安全很重要，他们利用了 TLS 的协议协商特性：实际上在这最初几毫秒的 HTTPS 连接中就把自己声明为一种 TLS 协议。很妙。
stingraycharles查看英文原文
In addition to this, with SPDY around, these first milliseconds are becoming even more important. Since SPDY requires some sort of negotiation between server and client to agree they both support the protocol, this creates a problem for the first request: how do you know a server supports SPDY without having seen a response from said server? Note that the regular HTTP Accept negotiation is not enough since the browser should already pipeline multiple requests before having seen a response. Since the designers of SPDY also figured security is important, they made use of TLS' protocol negotiation feature: they actually announce themselves as a TLS protocol in these first milliseconds of a HTTPS connection. Brilliant. For more information, see: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2#TOC-Server-Advertisement-of-SPDY-through-TLS-NPN-extension
询问不同 TLS 密码套件在 CPU/内存开销上的量级差异。
写得真好！我好奇的是为什么用 TLS_RSA_WITH_RC4_128_MD5 而不是 TLS_DHE_RSA_WITH_AES_256_CBC_SHA：这两种方案在内存/CPU 使用上差别多大？显然因服务器而异，但大概慢 2 倍还是 10 倍？
edave查看英文原文
Really well written! One thing I was curious about was the use of TLS_RSA_WITH_RC4_128_MD5 instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA: what's the difference between these setups in terms of mem/cpu usage? Obviously it varies between servers, but is it roughly 2x, 10x slower?
文章兼顾入门可读性与机制深度。
这么好的文章，真正的 Hacker News 素材。它不假设读者懂太多该领域知识，却仍能让人深入理解其中的机制。
flixic查看英文原文
Such a great article, true Hacker News material. Does not assume much knowledge about the field, yet still allows for a much deeper understanding of mechanics involved.
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comGoogle 拥有我的大部分邮件，因为它拥有你所有的邮件（2014）
Google has most of my email because it has all of yours (2014)
作者(2014年)分析了自己社交网络中的邮件往来数据，发现由于大多数联系人都在用 Gmail，Google 实际上能看到他与几乎所有人的通信内容——即使他自己不用 Gmail，隐…
安全与隐私上首页 4 次 · 2014–2025mako.cc