摘要： SSL/TLS是一个看似简单的技术。非常容易部署和让她跑起来，但是…她真的跑 起来了吗？第一部分是真的 —— SSL确实容易部署 —— 然而正确部属她并不容易。 为了确保TLS提供安全性，系统管理员和开发者必须投入额外的精力，去配置服务器和 编写应用程序。 2009年，我们在SSL Labs开始了相关工作，因为我 们想明白TLS到底是在怎么样被使用，我们也打算弥补TLS缺乏易用的工具和文档 的局面。我们进行了对全局TLS使用情况的完整调查，以及实现了在线检测工具，但文 档缺乏的问题依然存在。这份文档是解决这个问题过程中的一步。 我们的目标是让已经不堪负重的系统管理员和程序员尽可能花费少量时间就能完 成安全站点或Web应用的部署，正是因为我们的目的如此，所以这份文档可能不够完备，遗漏了 一些高级主题。因此，我们只提供简单实用容易理解的建议。 对于那些想了解更多信息的读者，可以看看 Section 6。 1. 私钥和证书 TLS提供的安全质量完全依赖于私钥和证书。私钥是安全的基础，而证书则用于向访问者表明 服务器的身份。 1.1 使用2048位的私钥 在你的所有服务器上使用2048位的RSA，或者等价强度的256位ECDSA私钥。密钥的强度能 保证在相当长时间内的安全，如果你已经使用1024位的RSA，尽快替换它们。如果你 的安全需求必须使用大于2048位的密钥，请考虑ECDSA，因为性能不错。不过ECDSA的缺点 是小部分客户端不支持，因此你有可能需要同时部署RSA和ECDSA以确保互操作性。 Lenx注：RSA 1024的强度相当于分组加密的80-96bit，已经被视为不安全。 1.2 保护私钥 私钥是重要的资产，尽可能限制能接触到私钥的人。推荐策略包括： 在一台可信的计算机(Shawn注:加固过的物理机器)上生成私钥和CSR( Certificate Signing Requests)。有一些CA会为你生成密钥和CSR，但这样做 明显不妥。 受密码保护的密钥可以防止从备份系统中泄漏。然而私钥密码在生产系统中使用的 帮助是有限的，因为这并不能阻止一个聪明的攻击者从进程内存中截获私钥。 一些硬件设备可以在服务器被攻陷的情况下确保私钥安全，但这些昂贵的设备 只在对安全有严格要求的机构中使用。 在发现系统被攻陷后，吊销老的证书，生成新的密钥和证书。 每年更新证书，同时更新私钥。 1.3 确保充分的域名覆盖 确保你的证书覆盖到目标站点的所有活跃域名。比如你的主站是www.trustauth.cn，但 你可能还有个www.trustauth.cn。你的目标就是避免无效证书警告，因为那会让你 的用户产生疑惑从而影响对你的信任。 即使你的服务器只有一个主机名配置，也要记得你不能控制用户是通过什么路径 访问你的站点的，可能是其他的链接过来的。大部分情况下，你应该保证证书能 在没有www前缀的情况下工作(比如，trustauth.cn和www.trustauth.cn)。这里经验法则 就是：一个安全的WEB服务器应该有一个对所有DNS名称解析都合法的证书配置。 通配符证书(Wildcard certificates)有它的适用场景。但如果这样的配置意味着 暴露私钥给不必要的人群（特别是在跨越部门边界的情形下），则应该避免使用。 换句话说，越少的人能访问私钥越好。此外，要意识到共享证书可能会导致安全漏洞 从一个站点扩散到所有使用相同证书的站点。 1.4 从靠谱的CA那里获得证书 选择一个对待安全业务认真可靠的CA( Certificate Authority)。在选择CA过程 中考虑以下因素： 对待安全的态度 大多的CA都会有常规的安全审计（否则根本没有资格当CA），但是其中一些会更重视 安全。搞清楚哪些更重视安全不是一件容易的事情，但一个可行的做法 是看看他们在安全方面的历史状况，他们如何响应攻击事件以及如何从错误中学习。 足够大的市场占有率 满足此因素的CA不太可能轻易撤销所有证书，而这种事情过去曾发生在小的CA身上。 业务重心 如果一家机构的核心业务是CA，那么一旦出现严重问题，他们将会受到严重影响。 因此这些CA不太可能因为追逐利润而忽视证书部门的重要性。 提供哪些服务 在最底线的情况，你选择的CA至少应该提供CRL( Certificate ... 更多