在SSL/TLS 中，密码套件选择一组算法，用于多项任务：密钥协商、对称加密、完整性检查。

该证书类型影响的关键协议的选择。必须考虑两个参数：密钥类型和密钥用法：

• 使用 RSA 密钥，您名义上可以使用“RSA”和“DHE_RSA”密码套件。但是，如果服务器证书具有不包含“keyEncipherment”标志的密钥使用扩展，那么您名义上仅限于“DHE_RSA”。
• 使用 DSA 密钥，您只能使用“DHE_DSS”密码套件。
• 使用 Diffie-Hellman 密钥，您只能使用“DH_RSA”或“DH_DSS”之一，具体取决于颁发证书颁发机构的密钥类型。

大多数 SSL 服务器证书都有一个不受密钥使用扩展限制的 RSA 密钥，因此您可以同时使用“RSA”和“DHE_RSA”密钥类型。

“DHE”代表“Diffie-Hellman Ephemeral”。这允许完美前向保密。PFS 意味着如果攻击者窃取了服务器私钥（存储在文件中的私钥，因此很可能容易受到不可告人的盗窃），他仍然无法解密过去记录的交易。这是一个理想的属性，尤其是当您希望您的系统在审计期间看起来不错时。

对于完整性检查，您不应使用 MD5，并且如果可能，也应避免使用 SHA-1。目前已知的 MD5 和 SHA-1 的弱点都不会影响 TLS 的安全性（可能在证书中使用时除外，但这是由 CA 选择的，而不是您）。然而，使用 MD5（或者，在较小程度上，SHA-1）对公共关系不利。MD5 已“损坏”。如果您使用 MD5，您可能需要为自己辩护。没有人会质疑 SHA-256 的选择。普遍的共识是，由于遗留原因，SHA-1 是“可以容忍的”。

对于对称加密，您可以在（主要）RC4、3DES 和 AES 之间进行选择（对于后者，256 位版本是多余的；AES-128 已经很好了）。可以做到以下几点：

• RC4 和 3DES 将在任何地方得到支持。最老的客户端可能不支持 AES（例如 Internet Explorer 6.0 似乎无法协商基于 AES 的密码套件）。

• RC4 中存在已知的弱点。没有一个是立即致命的。情况有点类似于 SHA-1：学术上“破”，但现在不是问题。如果可以避免的话，这仍然是不使用 RC4 的一个很好的理由。

• 3DES 是 64 位分组密码。当您在单个会话中加密超过几 GB 时，这意味着一些（学术）弱点。

• 3DES 可能对您的 CPU 造成负担。在 2.7 GHz Intel i7 上，OpenSSL使用 AES-128 实现了 180 MB/s 的加密速度（如果使用AES-NI 指令，它可以做得更好），但使用 3DES 只有 25 MB/s。25 MB/s 仍然不错（这是 100 Mbits/s 链接可以处理的 2.5 倍，并且使用单核），但根据您的情况，可能不能忽略不计。

• BEAST 攻击是一个古老的学术弱点，最近已被证明可应用于实践。它要求攻击者监视链接并在客户端上运行恶意代码（并且该代码必须与外部间谍系统通信）；当恶意内部代码使用 Java 或 Javascript 时，BEAST 作者已经设法运行它。通用解决方案是切换到免疫的 TLS 1.1 或 1.2。此外，这仅涉及 CBC 模式下的分组密码；RC4 是免疫的。

• 在 SSL/TLS 握手中，客户端宣布他支持的密码套件（首选套件首先出现），然后服务器选择将使用的套件。传统上，服务器尊重客户端的偏好——即选择服务器可以处理的客户端发送的列表中的第一个套件。但是服务器可以强制执行自己的偏好顺序。

• DHE 意味着服务器上的 CPU 消耗稍高（但除非您每秒建立数百个新 SSL 会话，否则不会产生明显的差异）。

• 没有使用 RC4 的 DHE 密码套件。

摘要：这将我引向以下首选的密码套件列表。如果 BEAST 攻击可能适用于您（即客户端是 Web 浏览器），请使用以下命令：

• 如果会话使用 SSL-3.0 或 TLS-1.0，请尝试使用TLS_RSA_WITH_RC4_128_SHA.
• 如果客户端支持 TLS 1.1+，或者不支持TLS_RSA_WITH_RC4_128_SHA，或者您认为 PFS 对您来说比 BEAST 主动攻击更重要（例如，您最关心的是长期机密性，而不是立即违规），那么使用TLS_DHE_RSA_WITH_AES_128_CBC_SHA256（TLS_DHE_RSA_WITH_AES_128_CBC_SHA如果客户端不支持 SHA-256，则回退到）。
• 如果客户端不支持 DHE 密码套件，请使用相应的非 DHE 套件。
• 通用后备是TLS_RSA_WITH_3DES_EDE_CBC_SHA应该在任何地方都可以使用的。

请注意，上述选择假设您可以根据协商的协议版本更改套件选择，这可能是也可能不是您的特定 SSL 服务器的可用选项。

如果 BEAST 不适用于您（客户端不会运行恶意代码），则完全放弃 RC4 支持；专注于 AES-128 和 SHA-256；分别回退到 3DES 和 SHA-1；如果可用，请使用 DHE。

修复程序在哪里，它们会是什么样子？唯一的解决方法是所有相关平台上的所有浏览器都实现了 TLS 1.1 或 1.2。但是，我不相信这会发生在像这样的传统平台上。

因此，目前我只将 RC4 视为一种解决方法，因为过去大多数软件开发人员都错过了实施最新的 TLS 标准，现在我们陷入了这种情况。

我喜欢 Mozilla 提出的密码套件（2014 年 1 月）：

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256: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-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

来源：https ://wiki.mozilla.org/Security/Server_Side_TLS

它试图平衡性能和安全性。但是，按照我的 Microsoft 的建议，我会远离 RC4

通过 SSL Labs 更新 2016：

您应该主要依赖提供强身份验证和密钥交换、前向保密和至少 128 位加密的 AEAD 套件。其他一些较弱的套件可能仍受支持，前提是它们仅与不支持更好的旧客户端协商。

有几个必须避免的过时加密原语：

匿名 Diffie-Hellman (ADH) 套件不提供身份验证。

• NULL 密码套件不提供加密。
• 导出密码套件在连接中协商时是不安全的，但它们也可以用于更喜欢更强大套件的服务器（FREAK 攻击）。
• 具有弱密码（通常为 40 位和 56 位）的套件使用很容易被破解的加密。
• RC4 不安全。
• 3DES 又慢又弱。

使用以下为 RSA 和 ECDSA 密钥设计的套件配置作为您的起点：

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA- AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM- SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

注意 此示例配置使用 OpenSSL 所需的非标准套件名称。对于在其他环境（例如 IIS）中的部署，您需要使用标准的 TLS 套件名称。

参考：https ://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites