结合Beast，Crime，Breach和Poodle的TLS降级攻击可以消除大部分（如果不是全部） SSLv3及更高版本。 Microsoft默认情况下禁用SSLv3，这对我来说似乎是个不错的选择。由于RC4，MD5和SHA1的弱点，因此可供选择的密码套件甚至更少。
“理想的” HTTPS服务将仅启用TLS 1.0、1.1和1.2，以及以下的密钥大小变体密码？什么是最优选的密码套件？
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
#1 楼
“理想的” HTTPS服务是否仅启用TLS 1.0、1.1和1.2，并带有遵循密码的密钥大小变体？
否，一个“理想的” HTTPS服务将仅启用TLS 1.2，并且仅启用基于AEAD（带有关联数据的经过身份验证的加密）的密码套件，该套件具有SHA-2、4096位DH参数和521符合您要求的类型的位EC曲线（政府批准或政府未生成）。
上述服务也将无法被许多较旧的客户端使用，包括Android 4.3和更低版本，IE 10和更低版本，Java 7（至少u25）和更低版本，OpenSSL 0.9 .8y及更早版本（OpenSSL 1.0.0根本不在我的来源中列出），依此类推。但是，它将不受任何仅适用于TLS 1.1及更低版本的攻击，任何依赖SHA-1的攻击以及任何依赖CBC模式或RC4之类的过时密码的攻击。<br />
客户端密码每个https://www.ssllabs.com的套件限制。
什么是最优选的密码套件？
这要视情况而定！
我认为必须遵守Foward Secrecy。
我认为“目前被认为是安全的“是一项要求。
我认为“至少由一个主要参与者实际实施”是一项要求。
所有与之相关的要求必须具有/不能使用某些或其他子集。密码（必须使用X，不能使用Y等）。
因此，我提出以下清单作为一个合理的起点。从顶部类别（TLS 1.2 AEAD）开始，然后继续向下滑动列表并添加类别，直到达到与用户群兼容的级别或您到达舒适区的尽头为止，以先到者为准。
尽可能包含每个类别的密码套件，以便在下一次攻击发生时，您将能够删除受影响的密码套件并继续其余的密码套件。
请密切注意威胁环境，以便您可以继续删除具有漏洞的密码套件。
在每个主要类别中，请根据您的喜好订购或剔除密码套件：DHE当然比ECDHE慢，但完全删除了椭圆曲线的来源，依此类推。目前，排序似乎是一种折衷，但是如果您想提高速度，则可以选择甚至要求TLS_ECDHE_ *。如果您不信任当前普遍采用的椭圆曲线，或者由于2015年8月的NSA Suite B指南而对椭圆曲线感到担忧，那表明不久的将来将会远离先前的Suite B椭圆曲线，并且愿意请注意，“普通”证书是RSA证书，可与TLS_ECDHE_RSA_ *和TLS_DHE_RSA_ *密码套件一起使用。请记住，“正常”证书是RSA证书。迄今为止，与TLS_ECDHE_ECDSA_ *密码套件配合使用的DSA证书非常罕见，而且许多CA都没有提供它们。
仅TLS 1.2 AEAD（也都是SHA-2）
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256（新的0xcca9，RFC7905 0xcc14）
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256（新的0xcca8，SCR15x_CH_ACH_ACH_AWS_POL5130_SHA_x3_ACH_ACH_ACH_AWS_CH_A5C，RFC_5xPre_RFC_5x_a_CH_A5C，RFC_5xPre_RFC_5x_a_CH_A5C，EAP_CH5A，RFC_5xPre5，LDAP_CH_A5，RFC_5xPrec br /> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384（0xc030）
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256（0xc02f）
对于对NIST合规性感兴趣的美国人，这是使用TLS 1.2的TLS密码套件每个NIST SP800-52修订版1表3-3的私有密钥和RSA证书
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384（0x9f）
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256（0x9e）
TLS_EC_ITH_ECDS（02x02） />
对于对NIST遵从性感兴趣的美国人员，这是一个TLS 1.2类别密码套件，适用于根据NIST SP800-52修订版1表3-5使用椭圆曲线私钥和ECDSA证书的服务器3-5
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256（0xc02b）
对于对NIST合规性感兴趣的美国人，这是一个TLS 1.2，应为使用椭圆曲线私钥和ECDSA证书（根据NIST SP800）的服务器分类密码套件-52版本1表3-5
这些是我目前在常见TLS实现中所知道的最高安全级别。
截至2017年1月，主要的现代浏览器一定要处理此级别，包括但不限于Android，带有支持AES-GCM的6.0，以及（仅主要的）旧版本的CHACHA20-POLY1305和7.0，支持新的CHACHA20-POLY1305，Chrome带有AES-GCM和CHACHA20-POLY1305，Firefox同时具有AES-GCM和CHACHA20-POLY1305，IE和Edge仅具有AES-GCM，Java仅具有AES-GCM，开放具有AES-GCM和CHACHA20-POLY1305的SSL 1.1.0，仅具有AES-GCM的Safari）。
许多主流浏览器都无法处理此问题，即使是2015年的老式浏览器（OSX 10.9，Android 4.3及更低版本的Safari 7，IE Win7上为10（如果已修补Windows，则即使在Win7上，IE 11也将支持0x9f和0x9e）
TLS 1.2 SHA2家族（非AEAD）
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256（0x6b）
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256（0x67）
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384（0xc028）
TLS_ECDHE中的
_W_C符合NIST，这是针对NRSA SP800-52修订版1表3-3使用RSA私钥和RSA证书的服务器的TLS 1.2应该类别密码套件，
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384（0xc024）
对于对NIST符合性感兴趣的美国用户，这是针对使用NIST SP800-52修订版1表3-5使用椭圆曲线私钥和ECDSA证书的服务器的TLS 1.2可能分类密码套件，请参见表3-5
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256（0xc023）
对于对NIST合规性感兴趣的美国人，这是一个TLS 1.2，应为使用按NIST SP800使用椭圆曲线私钥和ECDSA证书的服务器分类密码套件-52修订版1表3-5
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384（0xc077）
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256（0xc076）
TLS_DHE_RSA_WITH_CAMELLA（256） AEAD模式，并且正在使用较旧的CBC模式；这不理想。 CBC模式在过去曾是包括Lucky Thirteen和BEAST在内的数次攻击的一个促成因素，因此不难相信CBC模式也可能与将来的漏洞有关。
一些没有任何现代浏览器的浏览器AEAD密码套件确实在该类别中具有更多的适用性，例如，Win7上的IE 11可以使用TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256，而Safari 6和Safari 7可以使用其中的一些
如果您没有ECDHE_ECDSA GCM套件，请使用
带有现代密码的TLS 1.0和1.1（和过期的哈希，因为这一切可用）
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA（0xc014）
对于对NIST合规性感兴趣的美国人，这是使用RSA私钥的服务器的可能类别密码套件和RSA证书（符合NIST SP800-52修订版1表3-2）
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA（0xc013）
对NIST遵从性感兴趣，这是针对应根据NIST SP800-52修订版1表3-2使用RSA私钥和RSA证书的服务器的应有类别密码套件。
TLS_DHE_RSA_WITH_AES_256_CBC_SHA（0x39）
TLS_DHE_RSA_WITH_AES_128_CBC_SHA（0x33）
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA（均为0x88）
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA（0×45）
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA（0xc00a）
一旦你包括这个级别的密码套件，您可能会发现几乎所有现代实现都可以使用的东西。
在此级别上，您不仅在使用CBC模式，而且还在使用SHA-1。 NIST SP800-131A建议在2013年12月31日之后（实际上是一年前的今天）禁止使用SHA-1进行数字签名生成。
TLS 1.0和1.1的版本较旧，但仍然合理密码和过时的哈希
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA（0x16）
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA（0xc012）
这是针对应按NIST SP800-52修订版1表3-2使用RSA私钥和RSA证书的服务器的应分类密码套件，请参见表3-2
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA（0xc008）
对于对NIST遵从性感兴趣的美国人员，这是针对应使用NIST SP800-52修订版1表3-4的使用椭圆曲线私钥和ECDSA证书的服务器的密码分类套件，<3-4
>
由于DH参数最大值，Windows XP上的IE 8和Java 6u45仍然运气不佳。
这绝对是我建议的最低级别。
请注意，对于使用RSA私钥和RSA证书且需要符合NIST SP800-52修订版1的服务器，您应该并且应该并且可能会实施其他不提供前向保密性的TLS_RSA_ *密码套件，并且因此，除非需要遵守此规定，否则我不建议您这样做。
另请注意，该文档的第3.3.1段声明了特定的“服务器应配置为仅使用完全由批准的算法组成的密码套件。此部分提供了通用的可接受密码套件的完整列表...”
其他国家和行业要求当然会有所不同。
并且可能彼此冲突；请仔细阅读所有适用于您的内容。
我将在此处插入常用的插件-使用您自己的工具尝试使用密码列表（openssl密码-v '...'（针对基于opensl的系统），请首先访问https://www.ssllabs.com/index.html，以检查各种客户端支持的密码套件，然后设置您的站点，然后返回www。 ssllabs.com并运行其服务器测试。
请注意，_ECDSA_密码套件当然需要ECDSA证书，而这些证书仍然很难找到。
ETA：NSA套件B EC建议，并且IE 11 / Win7现在支持0x9f和0x9e。
ETA：截止2016年1月，NIST SP800-52r1保持不变，并且已向其中添加了一个新的密码套件（0xc00a）。清单。
ETA：截至2017年1月，RFC7905更改了三个TLS 1.2 AEAD CHACHA20-POLY1305密码，并且“现代”浏览器已大大改善了对AEAD的支持，如新项目符号所述。有关最新的IANA密码套件，请参阅https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4。
评论
到目前为止，这是最好的答案。 SHA1仍然是NIST认可的算法，但是我们应该使用它吗？理想的密钥大小不是那么多，但是协议会遭受一些非平凡的攻击吗？ SHA1遭受了非同寻常的攻击。
–rook
2014年12月30日15:55
@Rook，谢谢！ [NIST SP800-131A过渡：过渡使用密码算法和密钥长度的建议]（csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf），于2011年1月发布，指出SHA- 2013年12月31日之后，不允许使用1进行数字签名的生成。有关其他参考，[IBM Mobile Access 8.0安全访问管理器]（www-01.ibm.com/support/knowledgecenter/SSELE6_8.0.0.4/…）仅允许TLS 1.2在严格模式下。
–反弱密码
2014年12月31日，1：11
作为MAC使用的@Rook HMAC-SHA-1几乎没有被破坏（HMAC-MD5也不是）。仅当需要防撞功能（例如，证书使用的数字签名）时，SHA-1才会断开。
– CodesInChaos
2015年1月2日在16:49
@CodesInChaos这是一个好点，并且在HTTPS连接的相对较短的生命周期内生成第二个前映像是不可行的，这不是正确的错误类型...不幸的是，这个问题更适合对于金融世界，那里对安全意味着什么有严格的解释。
–rook
15年1月6日在18:15
仅供参考：OpenSSL 1.0.0不支持TLS 1.1或1.2； 1.0.1以上版本包括SHA2和GCM，但不包括CCM，而ChaCha-Poly仅在1.1.0中。 Oracle / OpenJDK Java 7确实实现了TLS 1.1和1.2（但未实现AEAD），但是客户端默认情况下未启用它们，因此您必须调整代码和/或配置。 Java 7也仅支持DHE最多1024。 Java 8支持2048，但不支持更多（不是4096）。 Java 7或8与OpenSSL一样，对包括P521在内的所有命名曲线均支持ECDHE。 @JanDoggen：OpenSSL（当前）实现rfc4137，但不实现5932和6367，因此排除了您询问的套件。
–dave_thompson_085
16-10-28在1:29
#2 楼
通常，我不会仅使用链接来回答问题，但是由于对此问题的答案经常变化，因此我经常这样做。同样，“理想”密码套件完全取决于应用程序和目标受众。您可以控制哪些，您可以做出哪些选择，您是否有能力负担得起（例如，您需要支持IE6？），这些都会影响“理想”答案。无论如何，https：/ /cipherli.st/很好地总结了流行应用程序的密码套件和配置示例。正如其他人指出的那样，Qualys SSLLabs有一个很好的工具来测试您的配置，并提供了一些很好的解释。
评论
链接不再有效。
– Mark Hosang
18年2月17日在14:41
这就是为什么仅将链接发布为答案被认为是网站上的不良做法。
–马塞尔曼
20/09/23在13:29
#3 楼
最好的起点是Mozilla建议的TLS密码。Qualys SSL Labs是测试公共HTTPS网站安全性的一种好方法，该网站还包含许多有关TLS / SSL的文章（重点是HTTPS）。 。
评论
为“现代兼容性”列出的某些密码依赖于损坏的原语。
–rook
2014年12月28日在22:10
@Rook哪些依赖破碎的原语？
–cpast
2014年12月28日在22:19
@cpast-至少Mozilla列表上的DSS密码对我来说是一个巨大的危险信号，因为DSS实现仅限于1024位DSA密钥；太短了，太短了，不能立即被认为是安全的。
–反弱密码
2014年12月29日下午4:45
@Rook是一个很好的例子，为什么没有所谓的“理想”密码套件集。正如其他人指出的那样，答案是相当主观的。没有一个答案。尽管针对不同的场景，有人可能会选择3-4种不同的用例。高兼容性，高安全性，低处理器使用率。选择您的价值观，您就可以回答问题。在没有值的情况下，将采用值。
– Steve Sether
15年1月2日在20:28
#4 楼
通过SSL Labs更新2016：您应该主要依靠AEAD套件，该套件提供强大的身份验证和密钥交换，转发保密性以及至少128位的加密。如果仅与不支持任何更好功能的老客户端进行协商，则仍可以支持其他一些较弱的套件。
必须避免一些过时的加密原语：
匿名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部署最佳实践＃23-使用安全密码套件
评论
五分之二的人不提供PFS。相关：keylength.com
更多信息：MSFT安全公告以禁用RC4。 Logjam攻击：diffie-hellman可能不安全
@LamonteCristo这个网站不使用HTTPS有多讽刺？ ：D
@SteveDL对吗？至少它让我在专属网络上看到了这一点。