安全与隐私wiki.mozilla.org编辑精选
服务器端 TLS 配置指南
Server Side TLS
2013 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Mozilla 维护的服务器端 TLS 配置指南，给出了 Nginx、Apache 等主流服务器的推荐加密套件配置和安全建议，并配有在线配置生成器。该页面多年来持续更新，是运维人员配置 HTTPS 时最常参考的资料之一。
为什么经久不衰：它把复杂易错的 TLS 配置整理成可直接复制的最佳实践，且随标准演进不断更新，多年后仍是配置服务器加密的权威起点。
HN 评论精选
提醒 HSTS 配置错误风险很高，需谨慎对待
还值得提一下 https://cipherli.st/。不过我觉得需要更多关于 HSTS 的警告，因为 HSTS 配置错误会导致域名长时间无法访问。
serialx查看英文原文
Worth mentioning https://cipherli.st/ too. But I think more warning about HSTS is needed, since misconfiguring HSTS will cause the domain to be inaccessible for long periods.
推荐用 SSL Labs 等工具验证配置效果
配置完成后可以用这个工具检查：https://www.ssllabs.com/ssltest/。命令行下 sslyze 也不错。
Erwin查看英文原文
You can check your configuration afterwards using this tool: https://www.ssllabs.com/ssltest/ For command line, this his nice: https://github.com/iSECPartners/sslyze
页面和配置生成器开源，欢迎社区贡献
如果想为这个页面或配套的配置生成器做贡献，可以到 GitHub 上的仓库看看。
jvehent查看英文原文
If you want to contribute to this page, or the config generator [1] that goes with it, check out its repository on github: https://github.com/mozilla/server-side-tls [1] https://mozilla.github.io/server-side-tls/ssl-config-generator/
批评盲目照抄长套件列表，主张按需精简配置
于是开始了多年盲目复制粘贴加密套件列表而不理解其含义的日子。你的套件列表应该比他们的精简得多。除非需要支持 IE6 的 SSL，否则可以禁用 SSLv3（v2 应始终禁用）。
ck2查看英文原文
And so begins years of copy/paste of cipher lists without knowing what they mean or do. Your cipher list should be far more paired down than their list. And unless you need IE6 support for SSL, you can disable SSLv3 (v2 should always be disabled)
认为套件列表过于复杂，加密配置应追求简单明确
哇，这么多套件，希望能看到允许这么多的理由。多少客户端支持 128 位 AES 却不支持 256 位？在加密上我永远偏好简单——不只是更少的套件，还有由此带来的明确保证：只允许某种强度的密钥、是否保证前向保密等。不过还是比保持默认设置好多了。
e12e查看英文原文
> The general purpose ciphersuite at the time of this writing is: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK Whoa! I'd like to see some reasoning behind allowing that many. How many user agents allow 128-bit aes and not 256? Why would you need to allow both? If 128 is enough, you don't need 256. If you need 256 you should block 128. It's not a very big deal, but given the choice between complexity and simplicity in encryption -- I'd always prefer simplicity... Not just "fewer cipher suites", but also what follows from that: "We allow X bit symmetric keys only", we guarantee forward secrecy (or not) etc. But still, a lot better than leaving things at their default, I guess :-)
历次讨论
同类还值得读
非法素数
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.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选