web-dev-qa-db-ja.com

Googleの保護Chrome WindowsでのLogjamエクスプロイトに対するブラウザ

WindowsでのLogjam TLSエクスプロイトに対してChromeを修正する方法はありますか？私は自分のChromeを最新バージョンに更新しました https： //weakdh.org/ Webサイトは、 "WebブラウザはLogjamに対して脆弱であり、弱い暗号化を使用するようにだまされる可能性があることを警告します。ブラウザを更新する必要があります。"

修正/パッチはまだリリースされていませんか？一方、これを修正する手動の方法はありますか？

Windows 7上のChromeバージョン43.0.2357.65 m。

編集：実際に修正されたバージョンをまだ公開しているブラウザはないようです。ブラウザチームが少なくとも修正を準備する機会を得る前に、Logjam論文の著者がリリースするのは少し時期尚早ではなかったのではないでしょうか。急いでいたことは何ですか？

tlschrome
17
curious_cat

2015-09-03を編集：修正済み。

2015-09-01のChromeバージョン45以降で修正。 WeakDH.orgは次のように報告します。
Good News! Your browser is safe against the Logjam attack.

元の投稿のほとんどは以下に保存されています。

バッチ回避策
回避策は、Chromeを起動し、すべての一時的なDHスイートを明示的に無効にするバッチファイルを作成することです。

現時点では、さまざまなブラックリスト文字列がインターネット上に浮かんでいます。以下は私の試みです。

暗号スイートは16進数IDで識別されます。 IANAには 登録済み暗号スイートの公式リスト があります。

しかし、そのリストから選んで選択するのではなく、OpenSSL（v1.0.2）にそれを任せることにしました。スイートは次のとおりです。

openssl ciphers -V DHE | sort

0x00,0x11 - EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export
0x00,0x12 - EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
0x00,0x13 - EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
0x00,0x14 - EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
0x00,0x15 - EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
0x00,0x16 - EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
0x00,0x32 - DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
0x00,0x33 - DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x38 - DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x40 - DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH     Au=DSS  Enc=AES(128)  Mac=SHA256
0x00,0x44 - DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
0x00,0x67 - DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH     Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0x6A - DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH     Au=DSS  Enc=AES(256)  Mac=SHA256
0x00,0x6B - DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH     Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x87 - DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
0x00,0x99 - DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
0x00,0x9A - DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0xA2 - DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(128) Mac=AEAD
0x00,0xA3 - DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256) Mac=AEAD

上記のリストから16進数IDを選択してブラックリスト文字列を生成するために使用した醜い小さなスクリプトを次に示します。

openssl ciphers -V DHE | 
sort | 
awk '{print $1}' | 
sed 's/,0x//g' | 
xargs echo | 
sed 's/ /,/g' | 
sed 's/^/--cipher-suite-blacklist=/'

そして、これはそのコマンドの出力です：

--cipher-suite-blacklist = 0x0011,0x0012,0x0013,0x0014,0x0015,0x0016,0x0032,0x0033,0x0038,0x0039,0x0040,0x0044,0x0045,0x0067,0x006A、0x006B、0x0087,0x0088,0x0099,0x009A、0x009E 0x009F、0x00A2、0x00A3

（免責事項：この文字列はおそらく長すぎます。Chromeがこれらの暗号スイートをすべてサポートしているとは思いません。（ SSL Labsクライアントテスト を使用して確認できます。））

2015-07-03の更新：Chromeはまだ脆弱です。

Logjamの公式ページ https://WeakDH.org/ は、512ビットのDHEサポートをチェックします。内部的に https://dhe512.zmap.io/ ドメインを使用してチェックします。このドメインに接続する機能は失敗と評価されます。

  • Chromeが失敗する。
  • Internet Explorer、Safari、Firefoxパス。

使用される実際の最小DHEビット長は次のとおりです。

（参照：ウィキペディア： Logjam ）

テストするいくつかのDHキーの長さは次のとおりです。

ただし、a Chrome 45の最小1024ビットが発表されています 。 （そして、これは2015年9月を意味すると思います。しかし、Chromeリリースモデルを本当に理解していません。）

15
StackzOfZtuff

2つ目の質問の答えとして、logjamが機能するためには、クライアントとサーバーの両方が古い「512ビットDH接続のエクスポート」をサポートしている必要があります。これは、これらのレガシー暗号スイートを除外するようにWebサーバーを再構成するだけで修正されます。この場合、サーバーを修正するためにパッチを適用する必要はありません。これらの暗号スイートは、使用されている限りずっと死んでいるからです。

これらは前世紀から一般的に使用されていない非常に弱い暗号であるため、サーバー側での修正は非常に簡単で、実際の欠点はありません。そのため、研究者たちは、ブラウザがそれを修正してユーザーがアップグレードするのを待つのではなく、間違いなくこの脆弱性を発表しました。

実際、ほとんどの主要なWebサイトはこのレガシー暗号スイートを長い間受け入れていません。そのため、世界中の発表を行うことが、これらの悪い構成を無効にするために（おそらく無意識のうちに）Wordをサポートするすべての人にWordを広める唯一の方法です。

下記のとおり、DHEをサポートするWebサイトの17％にその数が表示されています。彼らがエクスプロイトを発表する前の数字は次のとおりです。

HTTPS DHEは通常、Webサーバーにデプロイされます。 Alexa Top 1Mサイトの68.3％がDHEをサポートし、ブラウザーの信頼できる証明書を使用するサイトの23.9％がDHEをサポートしています。 DHEをサポートする上位100万サイトのうち、84％が1024ビット以下のグループを使用し、そのうち94％が5つのグループのいずれかを使用しています。

特にブラウザーメーカーがまだブラウザーを修正していないことを考えると（おそらく互換性の理由から）、彼らは正しい選択をしたと思います。ユーザーもブラウザをアップグレードする必要があることを忘れないでください。FFとChromeはほとんどの人が定期的にアップグレードしますが、IEは実際には同じことを言うことはできません。

したがって、Chrome FFおよびIEがパッチをリリースするのを待つのではなく、6月にここに座って数を大幅に減らして非常に満足しています。覚えておいてください。研究者は、これがリリース前にNSAによって積極的に悪用されていたと考えています。

5
Steve Sether