首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >推荐的ssl_ciphers安全性兼容性完美的前向保密

推荐的ssl_ciphers安全性兼容性完美的前向保密
EN

Security用户
提问于 2014-04-01 17:55:27
回答 7查看 64K关注 0票数 37

我目前使用的是nginx和以下密码:

代码语言:javascript
复制
ssl_ciphers HIGH:!aNULL:!eNULL:!LOW:!ADH:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;

我希望保持与旧浏览器的兼容性,特别是较旧的移动浏览器,因此不完全不允许SHA1。

如何实现SHA256优先于SHA1 (消息身份验证代码),并总是在可能的情况下使用。

我可以通过向我的SHA256字符串中添加SHA256:!SHA:来强制应用SHA1,但这也完全不允许SHA1。

但是,在ssl_cipher开始时,它倾向于只使用SHA1。有什么建议吗?

更新29.12.2014

感谢大家的建设性意见和讨论。

尽管我仍然认为服务器端上的Mozilla页面总体上涵盖了这个主题--我只会推荐现代兼容性,但有一个限制,即应该删除DSS密码,并明确禁止使用(!DSS),这是反弱密码建议的--谢谢您发现了它。

代码语言:javascript
复制
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: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-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:!3DES:!MD5:!PSK

有趣的是,ssllabs并没有对此发出警告或降低速度.

此外,我更喜欢使用自定义生成的Diffie-Hellman参数。尽管标准的那些显然被认为是安全的。什么是OpenSSL标准的Diffie-Hellman参数(素数)?

代码语言:javascript
复制
openssl dhparam -check -out /etc/ssl/private/dhparams.pem 2048

如果你愿意的话,如果你喜欢的话,把这个值提高到4096。

EN

回答 7

Security用户

回答已采纳

发布于 2014-04-02 04:09:52

首先,让我们简单介绍密码套件协商是如何工作的。例如,我们可以使用TLS1.2文档RFC 5246,从7.4.1.2节开始以简短的形式查看:

  • ClientHello:客户端告诉服务器客户端支持哪个密码套件
  • 现在服务器选择一个
  • 我将讨论如何控制它接下来选择哪一个!
  • ServerHello:服务器告诉客户机它选择了哪个密码套件,或者给客户端一条失败消息。

现在,关于实际的选择。我参考了nginx ssl模块文档Qualys 2013年关于配置Apache、Nginx和OpenSSL用于前向保密的文章Hynek强化了网络服务器的SSL密码文章。后两者同时涵盖Apache和Nginx (因为它们都使用OpenSSL作为基础)。

本质上,您需要告诉Nginx使用您选择的顺序,并且您需要选择一个订单。要查看该顺序的结果,可以使用OpenSSL命令行。

代码语言:javascript
复制
openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'

注意:您可能希望从该字符串中删除:!3 DES;3键三重DES并不有效,但它本身对于多少112位的安全性仍然是安全的,而且非常非常常见。

使用上面的命令确定哪些密码套件在您的配置中将是最首选和最不首选的,并更改它直到您喜欢结果。我给出的引用有它们自己的字符串;我稍微修改了它以获得上面的示例(例如,删除RC4和SEED,并将每个TLS1.2密码套件置于任何'SSLv3‘密码套件之上)。

然后,对于Nginx,您将修改配置文件,以包括以下内容:

代码语言:javascript
复制
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";

如果您真的坚持要添加SSLv3到ssl_protocols中。

ssl_prefer_server_ciphers将通知nginx使用我们指定的顺序,而忽略客户端在其中显示密码列表的顺序。现在,如果ClientHello和list OpenSSL -v之间唯一的共享密码套件.给出的是我们最不喜欢的密码,这当然是nginx会用到的。如果没有匹配,那么我们将向客户发送失败通知。

在这里,ssl_ciphers命令是选择的主要内容,因为nginx将通知OpenSSL我们首选的密码套件列表。请使用openssl密码器-v命令查看您在平台上获得的结果。理想情况下,在更改OpenSSL版本后再次检查它。

另外,请阅读斯科特关于在nginx中设置HSTS (HTTP严格传输安全性)的文章),这将允许主机在客户端强制使用HTTPS。确保将HSTS标头包含在带有ssl语句的http块中。

编辑补充:至少在此之后(如果不是之前),去Qualys实验室查看HTTPS的安全信息,并访问测试您的服务器,这是过去几年来一直保持的。建议有规律的变化,有时甚至经常改变自己(例如,RC4,几乎是鞭打引起的)。你甚至可以测试您的浏览器

票数 27
EN

Security用户

发布于 2015-04-21 21:26:55

Mozilla有一个在线工具,可以帮助您选择正确的密码套件。

https://mozilla.github.io/server-side-tls/ssl-config-generator/

它将允许您输入服务器版本、软件版本等,然后在安全和遗留支持之间进行选择。

票数 9
EN

Security用户

发布于 2014-04-02 00:58:27

OpenSSL自然会更喜欢新的MACs电脑,而不是同等的密码套件。例如,密码字符串的长openssl ciphers -v输出以以下开头:

代码语言:javascript
复制
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(256)    Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(256)    Mac=AEAD
ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA384
ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA384
ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA1
ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA1

当然,TLS只使用服务器和客户端相互支持的密码套件,Chrome和Firefox都不支持HMAC- the 256密码套件。由于HMAC-SHA1 (甚至HMAC-MD5)仍然被认为是安全的,我相信他们的开发人员(以及他们都使用的TLS库NSS的开发人员)对浪费开发人员的精力和TLS握手大小表示怀疑,因为它们增加了新的、不必要的和向后兼容的密码套件。

例如,看看铬33's支持的密码套件按优先顺序排列

  1. ChaCha20-Poly1305
  2. AES-128-GCM,
  3. AES-256-CBC与HMAC-SHA1,1,
  4. RC4 (ugh)和AES-128-CBC与HMAC-SHA1,.

OpenSSL不支持ChaCha20-Poly1305。如果你的不支持AES-GCM (?)并使用RSA证书,ECDHE-RSA-AES256-SHA自然是Chrome将使用的密码套件。(火狐29将使用ECDHE-RSA-AES128-SHA。)

(您在其他网站上看到的" SHA-256“密码套件可能是ChaCha20-Poly1305或AES-128-GCM,它们是不使用HMAC的AEADs,但其密码套件在PRF中使用sha-256。)

票数 3
EN
页面原文内容由Security提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://security.stackexchange.com/questions/54639

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档