Chrome が「古い暗号化」について警告するのはなぜですか?

Chrome が「古い暗号化」について警告するのはなぜですか?

私は、IIS / Windows 2008R2 でワイルドカード SSL 証明書を使用して ASP.NET Web サイトをホストしています。Chrome は私の Web サイトで正常に動作し、https 接続に緑色のロックが表示されますが、https の詳細には「古い暗号化」と記載されています。

chrome https 詳細

これは SHA1 によるものだと思いますが、これは同じウィンドウの Chrome でも言及されています。

ただし、Digicert の SSL 証明書チェッカーによると、SHA256 を使用する必要があります。

ここに画像の説明を入力してください

何が起こっているのか、この問題をどう解決すればいいのか、私にはわかりません。このブログ投稿この問題の回避策が説明されていますが、回避策が非常にわかりにくいため (1. 手順: OpenSSL をインストールしますか?)、これが Windows 2008 R2 で実行するための正式な方法であるとは考えられません。

SSL 証明書の警告を取り除くにはどうすればよいですか?

編集:適用後脚本Grant の推奨により、私の SSLabs は C から A に改善され、Chrome は TLS 1.0 ではなく 1.2 を使用しています。ただし、「古い暗号化」の警告はまだ表示されます。

答え1

問題を引き起こしているのは SHA ではなく、TLS 1.0 です。

SSL Labsレポートドメインの で詳細がわかります。サーバーは TLS 1.0 のみをサポートしており、1.1 や 1.2 はサポートしていません。さらに、RC4 などの古い暗号もサポートしており、Perfect Forward Secrecy もサポートしていません。

IIS を調整してセキュリティを強化することは可能ですが、手作業で行うのは面倒です。 この素晴らしい脚本Alexander Hass によって書かれた は、IIS7.5 および IIS8 の古い安全でない暗号化方式を無効にするためにさまざまなレジストリ設定を設定します。

スクリプトを実行した後、サーバーを再起動すると、SSLLabs で A 評価が得られ、Chrome で警告が表示されなくなります。

答え2

私はこれを2012 R2の新規サーバーでテストしています。アレクサンダー・ハス脚本(AH-Script)、私はまだ時代遅れの暗号化を取得します:

Chrome の古い暗号化

Chrome 43 は次の暗号スイートをサポートしています。

[C02B]  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C02F]  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E]  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[CC14]  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
[CC13]  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[CC15]  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[C00A]  TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C014]  TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039]  TLS_DHE_RSA_WITH_AES_256_SHA
[C009]  TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C013]  TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033]  TLS_DHE_RSA_WITH_AES_128_SHA
[009C]  TLS_RSA_WITH_AES_128_GCM_SHA256
[0035]  TLS_RSA_AES_256_SHA
[002F]  TLS_RSA_AES_128_SHA
[000A]  SSL_RSA_WITH_3DES_EDE_SHA
[00FF]  TLS_EMPTY_RENEGOTIATION_INFO_SCSV

したがって、使用されるのはかなり下のほうにある [C013] です。Chrome は CBC よりも SHA256 と GCM を優先するようです。

AH スクリプトを取得し、[009E] (上から 3 番目) を暗号スイート リストに追加しました。再起動後、次のようになります。

Chrome 最新の暗号化

上の2つ[C08B]と[C02F]を動作させようとしましたが、できませんでした。

そこで、スクリプトを修正して実行すると、 が得られましたmodern cryptography

文字列の長さが制限されているため、既存の暗号の 1 つを削除しました。文字列の先頭は次のようになります。

$cipherSuitesOrder = @(
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256',
'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256',

編集:私はこれを sslLabs.com でテストしたところ、 を使用するとTLS_DHE_RSA_WITH_AES_128_GCM_SHA256となりBA以前の から に下がりました。

このサーバーは、弱い Diffie-Hellman (DH) キー交換パラメータをサポートしています。グレードは B に制限されています。

だから、これを使いたくないかもしれません。Chrome がこれをなぜ高く評価しているのかはわかりません。

答え3

Chromeの「古い暗号」メッセージは、サーバーが弱いDiffie-Hellman(DH)鍵交換をサポートしているためです。より具体的には、暗号スイートブラックリストの HTTP/2 仕様

使用するとAlexander Hass による PowerShell スクリプト(現在の承認された回答から)、これには、ブラックリストに載っている:

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

を見てみるとAzure App Serviceでは、次の暗号スイートの順序を使用します。:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

その結果、Qualys SSL Labs (2016 年 7 月) で A 評価を獲得し、ほとんどの一般的なブラウザで Forward Secrecy がサポートされます。

ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYChrome の問題を発見したのは、Windows 10 上のローカル IIS Express で、システムにブラックリストに登録された暗号スイートが構成されている場合に Chrome 51 でエラー メッセージが返されるからです。

関連情報