web-dev-qa-db-ja.com

Chromeに「弱い一時的なDiffie-Hellman公開鍵」を無視させる

Chromeがv45にアップデートされたことで、弱い一時Diffie-Hellman公開鍵を持つページへのアクセスがブロックされました。私はこれがLogjamによるものだと理解しています。私は、httpsからhttpへの切り替えが場合によっては「解決策」であることを理解しています。

ただし、イントラネットで使用しているWebベースのソフトウェアによってhttpsに自動リダイレクトされるため、httpsからhttpに切り替えることはできません。

明らかに、解決策はlogjamから安全になるようにさまざまなイントラネットサーバーをセキュリティで変更することでしょう、しかし私はそれを理解しています、しかしそれは今のところ正しい選択ではない、これはイントラネットであり、単に接続するためには物理的にここにいる必要があるため、リスクはごくわずかです。

Chromeバージョン45の弱い一時的なDiffie-Hellman公開鍵を使用して、httpsプロトコル経由でページにアクセスし続けることができる方法はありますか。

google-chromesecurityhttps
17
Raine Dragon

この問題を回避するための巧妙な修正（Mac OSX）

  • Chromeの起動中にこの問題を回避するには、コマンドラインでこれを実行します。

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_shaおよびsecurity.ssl3.dhe_rsa_aes_256_shaを検索します
  • 両方ともfalseに設定してください。

注：恒久的な解決策は、長さが1024より大きいDHキーを更新することです。

8
user38814

確かに、ブラウザは、長さが1024より小さいキーを持つDiffie-Hellman問題を深刻に受け止めているように思われますが、それは一部ではすばらしいニュースですが、他方ではそれを生み出しました。たくさんの 怒っているChromeユーザー 。

この問題（およびセキュリティに関する他の多くの問題）の修正は、システム管理者の責任です。私が理解しているように、弱い512ビット以下のDiffie-Hellmanキーを提供するWebサイトをブロックするという決定は、リモートサイトのセキュリティを管理し、「欠点」の影響を受けるユーザー。

Log Chromeの脆弱性に関連する脆弱性を無効にし、ユーザーがサイトに参加できるようにする--cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013パラメータを使用してGoogle Chromeブラウザを起動すると、現在一部のCipher Suitesをブラックリストに載せることが可能です。彼らのDiffie-Hellmannの鍵で問題を解決する責任があります。

5
nKn

あなたが尋ねたものの1つは、イントラネット設定でリストされた回避策を使用すること（またはリストされていない他のものを使用すること）に不利があるかどうかでした。簡単な答えは、関係するサーバーが弱い鍵を使用している限り、関係するサーバーはlogjam攻撃を使用するシステムの影響を受けやすく、サーバーの性質によっては、その後サーバーを感染させる可能性があるサーバーです。サーバーにアクセスしている他のクライアントに発行します。

2つのありそうもないシナリオは、それらが再びイントラネットに接続するときに内部サーバーにアクセスするイントラネットから感染したラップトップ、またはインターネットにアクセスするために現在使用されている問題を無視するように設定されたブラウザです。イントラネットサーバーを攻撃するための危険な場所である侵入先のサーバーに接続すること。

私は個人的にはlogjamの欠陥が提示する問題のすべてに精通していないので、これら2つの状況のどちらかが特にありそうかどうかは言えません。私自身の経験では、インターネットに接続しているサーバーを持つシステム管理者は、できる限りそのような問題を回避する傾向があります。それは私の経験はまたイントラネットサーバー管理者がサーバーセキュリティ問題に対処する前にサイトを作るようなことをする傾向があるということでもあると言った。

0
Rusty YouDon'tNeedHisLastName

同じ問題に直面しました。サーバーサイドの人ならserver.xmlの443コネクタに次の行を追加するTomcat

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キーの問題を解決するのに役立ちます。

0
Kiran