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

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

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

明らかに、解決策は、さまざまなイントラネットサーバーをlogjamから保護するためにセキュリティを変更することです。しかし、それは今のところ正しいオプションではなく、修正されるまでこれ以上作業を行うことはできません。それはイントラネットであり、単に接続するには物理的にここにいる必要があるため、リスクは非常に小さいです。

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

この問題を回避するためのハック修正（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_shaとsecurity.ssl3.dhe_rsa_aes_256_sha
• 両方に設定しますfalse。

注：1024を超える長さでDHキーを更新すると、永久に修正されます

実際、ブラウザは長さが1024未満のキーを使用するDiffie-Hellmanの問題を真剣に受け止めているようです。これは、一部では素晴らしいニュースですが、一方で、多くの怒っているChromeユーザーを生み出しています。

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

現在、--cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013パラメータで実行してGoogle Chromeブラウザを起動すると、一部の暗号スイートをブラックリストに登録することができます。これにより、LogJam脆弱性に関連するものが無効になり、ユーザーがサイトに参加できるようになりますが、システム管理者の責任であるべきだと主張していますDiffie-Hellmannのキーの問題を修正します。

質問の1つは、イントラネットのセットアップでリストされている回避策を使用する（またはリストされていない他の回避策を使用する）ことに不利な点があるかどうかでした。簡単な答えは、関与するサーバーが弱いキーを使用している限り、関与するサーバーはlogjam攻撃を使用するシステムの影響を受けやすく、サーバーの性質によっては、その後サーバーが侵害されたサーバーとなり、サーバーにアクセスする他のクライアントへの問題。

ありそうにない2つのシナリオは、イントラネットに再接続したときに内部サーバーにアクセスしてイントラネットから感染したラップトップ、またはインターネットへのアクセスに現在使用されている問題（上記および他で示唆された）を無視するように構成されたブラウザーです侵入されたサーバーに接続して、イントラネットサーバーを攻撃する出発点になります。

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

同じ問題に直面した。サーバー側の場合は、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キーの問題を解決するのに役立ちます。