Chrome 通过 HTTPS 连接到本地网络服务器时报告 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

Chrome 通过 HTTPS 连接到本地网络服务器时报告 ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

概括

当我尝试通过 HTTPS 连接到本地 Web 服务器时,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. 添加了一个HOSTS文件条目myapp.local,指向127.0.0.1
  4. 创建了绑定到域myapp.local并仅侦听 HTTPS 请求的IIS 8.5 应用程序
  5. 将证书分配myapp.local给网站

使用此设置,我可以轻松通过 Chrome 访问本地网站,无需任何证书或安全警告。浏览器如预期显示绿色挂锁。

什么不起作用

最近,我升级到了 Windows 10。当时我并不知道 Windows 10 附带了支持 HTTP/2 的 IIS 10。现在,当我尝试使用 Chrome 访问本地网站时,我收到错误ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY。我应该注意到,从 Edge 发送的相同请求不会导致错误,并且确实使用 HTTP/2 进行连接。粗略的 Google 搜索没有找到任何有希望的信息,只是暗示问题可能是 HTTP/2 或 Chrome 对在 SSL 证书中接受的密码要求严格。

我认为这可能是 Windows 中启用的密码套件的问题(但我不是这方面的专家),所以我下载了最新版本的IIS 加密。我单击了“最佳实践”按钮,单击了“应用”,然后重新启动了我的计算机。

IIS Crypto 将这些设置报告为“最佳实践”:

  • 启用的协议:TLS 1.0、TLS 1.1、TLS 1.2
  • 启用的密码:三重 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åkan Lindqvist 的回答,以及非常详细且显然经过彻底研究的答案这里之后,我使用以下设置重新配置了 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_使用
    _AES_256_GCM_SHA384 TLS_DHE_RSA_使用
    _AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_使用_AES_256_GCM_SHA384_P521
    TLS_ECDHE_ECDSA_使用_AES_256_GCM_SHA384_P384 TLS_ECDHE_ECDSA_使用_AES_128_GCM_SHA256_P521 TLS_ECDHE_ECDSA_使用_AES_128_GCM_SHA256_P384 TLS_ECDHE_ECDSA_ 使用
    _AES_128_GCM_SHA256_P256 TLS_ECDHE_ECDSA_使用_AES_256_CBC_SHA384_P521 TLS_ECDHE_ECDSA_使用AES_256_CBC_SHA384_P384 TLS_ECDHE_ECDSA_使用AES_128_CBC_SHA256_P521 TLS_ECDHE_ECDSA_使用AES_128_CBC_SHA256_P384 TLS_ECDHE_ECDSA_使用AES_128_CBC_SHA256_P256 TLS_ECDHE_ECDSA_使用 AES_256_CBC_SHA_P521 TLS_ECDHE_ECDSA_使用 AES_256_CBC_SHA_P384 TLS_ECDHE_ECDSA_使用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






























答案1

Http/2 要求https://httpwg.org/specs/rfc7540.html#rfc.section.9.2.2

9.2.2 TLS 1.2 密码套件

基于 TLS 1.2 的 HTTP/2 部署不应使用密码套件黑名单中列出的任何密码套件 (附录 A)。

如果协商了黑名单中的某个密码套件,端点可能会选择生成 INADEQUATE_SECURITY 类型的连接错误(第 5.4.1 节)。选择使用黑名单密码套件的部署可能会触发连接错误,除非已知潜在对等端组接受该密码套件。

实现不得在协商不在黑名单中的密码套件时生成此错误。因此,当客户端提供不在黑名单中的密码套件时,他们必须准备好将该密码套件与 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_SHA256NISTP-256椭圆曲线(在 Windows 上标识为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256)放在列表​​顶部,或者至少放在黑名单中包含的任何内容之前?

答案2

下面是我创建的一些用于暂时禁用 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

只需从适当的 CA 获取证书即可,有免费的证书(启动SSL),而且不需要花太长时间就能得到它。

当使用适当的证书时,我在 Windows 10 上使用 IIS 10 以及在 Chrome 上使用 HTTP/2 没有任何问题。

相关内容