强制Chrome忽略“弱临时Diffie-Hellman公钥”


17

随着Chrome浏览器更新到v45,它阻止了使用弱通用Diffie-Hellman公钥的页面的访问。我了解这是由于Logjam造成的。我了解在某些情况下从https切换到http是一种“解决方案”。

但是,我无法从https切换到http,因为我们在Intranet上使用的基于Web的软件将我自动重定向到https。

显然,解决方案是让安全性更改各种Intranet服务器,使其免受logjam的影响,我知道,但是这不是当前的选择,而且在固定之前,我无法做更多的工作。因为它是一个Intranet,并且完全只是连接就需要一个物理位置,所以风险很小。

我有什么方法可以继续通过https协议使用Chrome版本45中短暂的短暂Diffie-Hellman公钥继续通过https协议访问页面?


对于:productforums.google.com/forum/#!topic/chrome/xAMNtyxfoYM,似乎可以禁用单个密码套件来解决此问题。除了显而易见的事情(降低安全性会增加在外部网络上的风险)之外,在Intranet上使用此功能是否还有缺点?而更多的信息:fehlis.blogspot.com/2013/12/... code.google.com/p/chromium/issues/detail?id=58833
瑞恩龙

Answers:


8

修正此问题的修补程序(Mac OSX)

  • 在启动Chrome时在命令行中运行此方法来解决此问题

铬:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

金丝雀:

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

对于Firefox

  • 转到about:config
  • 搜索 security.ssl3.dhe_rsa_aes_128_shasecurity.ssl3.dhe_rsa_aes_256_sha
  • 将它们都设置为false

注意:永久性解决方法是更新长度> 1024的DH密钥


5

确实,似乎浏览器已经认真对待Diffie-Hellman问题,其密钥的长度小于1024,这在一定程度上是个消息,但另一方面,它引起了很多Chrome用户愤怒

解决此问题(以及许多其他与安全有关的问题)的方法是系统管理员的责任,因此据我所知,决定阻止任何提供512位以下或更低Diffie-Hellman密钥的网站的决定是一种针对该问题的压力措施。那些管理远程站点安全性的人,具有“缺点”的用户在于用户。

当前,可以通过使用--cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013参数运行Google Chrome浏览器时将某些密码套件列入黑名单,这似乎禁用了与LogJam漏洞相关的参数,并允许用户加入站点,但我坚持认为这应由系统管理员负责用Diffie-Hellmann的钥匙解决问题。


谢谢nKn,当Chrome更新到版本45时,它与Cisco Finesse一样富有魅力,而我现在无法访问该程序。
Christopher Chipps 2015年

0

您要问的一件事是在Intranet设置中使用列出的解决方法(或使用未列出的其他解决方法)是否有任何不利之处。简短的答案是,只要所涉及的服务器使用弱密钥,所涉及的服务器将容易受到使用logjam攻击的任何系统的侵害,并且根据服务器的性质,该服务器随后可能是可能会传播此漏洞的受感染服务器。向访问服务器的其他客户端发出问题。

两种不常见的情况是:一台笔记本电脑在再次连接到Intranet时被Intranet感染而无法访问内部服务器,或者配置为忽略当前用于访问Internet的问题的浏览器(如上文和其他地方所建议),并且恰好连接到受感染的服务器,这是攻击Intranet服务器的起点。

由于我个人并不熟悉该僵局漏洞所带来的所有问题,因此我无法说这两种情况中的任何一种是否特别有可能发生。我自己的经验是,面向Internet的服务器的系统管理员往往会尽力解决此类问题。那就是说,我的经验还在于,Intranet服务器管理员倾向于在解决服务器安全性问题之前做一些使站点变得很像的事情。


0

面临同样的问题。如果您是服务器端的家伙,只需在server.xml tomcat的443连接器中添加以下行

sslProtocols = “使用TLSv1,TLSv1.1,TLSv1.2工作” 密码= “TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA”

这将帮助您解决此SSL密钥问题。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.