web-dev-qa-db-ja.com

Chromeは、HTTPS経由でローカルWebサーバーに接続しているERR_SPDY_INADEQUATE_TRANSPORT_SECURITYを報告します

まとめ

HTTPS経由でローカルウェブサーバーに接続しようとすると、ChromeがERR_SPDY_INADEQUATE_TRANSPORT_SECURITYを報告します。この問題が最近のWindows 10のアップグレードに関係していることはほぼ確実ですが、それを修正する方法がわかりません。

機能したもの

これが一連のイベントです。最初にWindows 8.1 Proがインストールされています。

  1. 次のコマンドを使用して、信頼されたルートCAとして使用することを目的とした自己署名証明書を生成しました：makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
  2. 信頼されたルートCAからアプリケーション固有の証明書を生成しました：makecert.exe -pe -ss My -sr LocalMachine -n "CN=myapp.local, OU=Development" -is Root -ir LocalMachine -in local -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -a sha512 -e 01/01/2020 -sky -eku 1.3.6.1.5.5.7.3.1
  3. myapp.localを指す127.0.0.1のHOSTSファイルエントリを追加しました
  4. myapp.localドメインにバインドされ、HTTPSリクエストのみをリッスンするIIS 8.5アプリケーションを作成しました
  5. myapp.local証明書をWebサイトに割り当てた

この設定により、ChromeからローカルWebサイトに問題なくアクセスでき、証明書やセキュリティ警告も表示されませんでした。ブラウザーは期待どおりに緑の南京錠を表示しました。

機能しないもの

最近、Windows 10にアップグレードしました。Windows10にHTTP/2をサポートするIIS 10が同梱されていることを当時は知りませんでした。 Chromeでローカルウェブサイトにアクセスしようとすると、ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYエラーが表示されます。 Edgeから送信された同じリクエストはエラーにならず、接続にHTTP/2を使用することに注意してください。大まかなGoogle検索では、HTTP/2またはChromeがSSL証明書で受け入れる暗号について厳密であることが問題である可能性があるというヒントを除いて、有望なものは何も見つかりませんでした。

Windowsで有効になっている暗号スイートの問題である可能性がある（しかし、そのようなものの専門家ではない）と考えて、最新バージョンの IIS Crypto をダウンロードしました。 「ベストプラクティス」ボタンをクリックし、「適用」をクリックして、マシンを再起動しました。

IIS Cryptoはこれらの設定を「ベストプラクティス」として報告します。

  • 有効なプロトコル：TLS 1.0、TLS 1.1、TLS 1.2
  • 有効な暗号：Triple DES 168、AES 128/128、AES 256/256
  • 有効なハッシュ：MD5、SHA、SHA 256、SHA 384、SHA 512
  • 有効な鍵交換：Diffie-Hellman、PKCS、ECDH

  • SSL暗号スイートの順序：

    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_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P284
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P284
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P284
    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_256_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA

また、私が開発しているブラウザーアプリケーションがWindows XPから使用できる必要はないではないことも追加します。新しいプロトコルをサポートしていないWindows XPに関するいくつかの問題があることを知っています。

HTTPSネゴシエーションに関する詳細情報

Fiddlerを使用してHTTPSネゴシエーションをインターセプトすることにしました。 Fiddlerがリクエストについて報告した内容は次のとおりです。

Version: 3.3 (TLS/1.2)
Random: 6B 47 6D 2B BC AE 00 F1 1D 41 57 7C 46 DB 35 19 D7 EF A9 2B B1 D0 81 1D 35 0D 75 7E 4C 05 14 B0
"Time": 2/1/1993 9:53:15 AM
SessionID: 98 2F 00 00 15 E7 C5 70 12 70 CD A8 D5 C7 D4 4D ED D8 1F 42 F9 A8 2C E6 67 13 AD C0 47 C1 EA 04
Extensions: 
    server_name myapp.local
    extended_master_secret  empty
    SessionTicket   empty
    signature_algs  sha512_rsa, sha512_ecdsa, sha384_rsa, sha384_ecdsa, sha256_rsa, sha256_ecdsa, sha224_rsa, sha224_ecdsa, sha1_rsa, sha1_ecdsa
    status_request  OCSP - Implicit Responder
    NextProtocolNego    empty
    SignedCertTimestamp (RFC6962)   empty
    ALPN        http/1.1, spdy/3.1, h2-14, h2
    channel_id(GoogleDraft) empty
    ec_point_formats    uncompressed [0x0]
    elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
Ciphers: 
    [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

Compression: 
    [00]    NO_COMPRESSION

と応答：

Version: 3.3 (TLS/1.2)
SessionID:  98 2F 00 00 15 E7 C5 70 12 70 CD A8 D5 C7 D4 4D ED D8 1F 42 F9 A8 2C E6 67 13 AD C0 47 C1 EA 04
Random:     55 C6 8D BF 78 72 88 41 34 BD B4 B8 DA ED D3 C6 20 5C 46 D6 5A 81 BD 6B FC 36 23 0B 15 21 5C F6
Cipher:     TLS_RSA_WITH_AES_128_GCM_SHA256 [0x009C]
CompressionSuite:   NO_COMPRESSION [0x00]
Extensions:
        ALPN        h2
        0x0017      empty
        renegotiation_info  00
        server_name empty

機能しているもの

HåkanLindqvistの回答と、非常に詳細かつ明らかに調査された回答 here に基づいて、IIS Cryptoを次の設定で再構成し、Chromeを排除しました_エラー：

  • 有効なプロトコル：TLS 1.0、TLS 2.0、TLS 3.0
  • 有効な暗号：AES 128/128、AES 256/256
  • 有効なハッシュ：SHA、SHA 256、SHA 384、SHA 512
  • 有効な鍵交換：Diffie-Hellman、PKCS、ECDH

  • SSL暗号スイートの順序：

    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
    TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
    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_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
    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

iisssl-certificatehttpsgoogle-chromewindows-10
21
NathanAldenSr

によるHttp/2要件https://http2.github.io/http2-spec/#rfc.section.9.2.2 ：

9.2.2 TLS 1.2暗号スイート

HTTP/2 over TLS 1.2の展開では、暗号スイートブラックリスト（ 付録A ）に記載されている暗号スイートを使用しないでください。

ブラックリストの暗号スイートの1つがネゴシエートされた場合、エンドポイントはタイプINADEQUATE_SECURITYの接続エラー（セクション5.4.1）を生成することを選択できます（MAY）。潜在的なピアのセットがその暗号スイートを受け入れることがわかっている場合を除いて、ブラックリストに記載された暗号スイートの使用を選択するデプロイメントは、接続エラーをトリガーするリスクがあります。

実装は、ブラックリストにない暗号スイートのネゴシエーションに反応してこのエラーを生成してはなりません（MUST NOT）。その結果、クライアントがブラックリストにない暗号スイートを提供する場合、HTTP/2でその暗号スイートを使用する準備をする必要があります。

ブラックリストには、TLS 1.2が必須とする暗号スイートが含まれています。これは、TLS 1.2デプロイメントに、許可された暗号スイートの交差しないセットがある可能性があることを意味します。 TLSハンドシェイクの失敗を引き起こすこの問題を回避するために、TLS 1.2を使用するHTTP/2のデプロイメントは、P-256楕円曲線[FIPS186]でTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]をサポートする必要があります。

クライアントは、HTTP/2をサポートしないサーバーへの接続を許可するために、ブラックリストにある暗号スイートのサポートをアドバタイズする場合があることに注意してください。これにより、サーバーはHTTP/2ブラックリストにある暗号スイートを使用してHTTP/1.1を選択できます。ただし、アプリケーションプロトコルと暗号スイートが個別に選択されている場合、これにより、HTTP/2がブラックリストの暗号スイートとネゴシエートされる可能性があります。


交渉された暗号TLS_RSA_WITH_AES_128_GCM_SHA256は、上記の（およびリンクされた）Http/2ブラックリストに含まれています。

上記の要件を満たすように暗号スイート（順序？）を調整する必要があると思います。多分単にTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256をNIST P-256楕円曲線（WindowsではTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256として識別される）でリストの一番上、または少なくともブラックリストに含まれるものの前に置くだけですか？

22
Håkan Lindqvist

IISでHTTP/2を一時的に無効にするために作成したPowerShellは次のとおりです。

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\HTTP\Parameters -Name EnableHttp2Tls -Value 0 -Type DWord
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\HTTP\Parameters -Name EnableHttp2Cleartext -Value 0 -Type DWord

HTTP/2を無効にすることが問題の唯一の「解決策」であると思われるため、これを答えにします。ただし、IIS 10ですべてのブラウザで確実にHTTP/2を使用したいので、これは受け入れません。

3
NathanAldenSr

適切なCAから証明書を取得するだけで、無料の証明書（ StartSSL ）があり、取得にそれほど時間がかかりません。

適切な証明書を使用すると、Windows 10およびChromeでのHTTP/2でIIS 10を使用しても問題ありませんでした。

0
Peter Hahndorf