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

Question

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

Nat*_*nSr 21 iis https google-chrome ssl-certificate windows-10

概括

ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY当我尝试通过 HTTPS 连接到我的本地网络服务器时，Chrome 正在报告。我几乎可以肯定这个问题与我最近的 Windows 10 升级有关，但我不知道如何解决它。

什么有效

这是事件链，我在开始时安装了 Windows 8.1 Pro：

使用以下命令生成了用作受信任根 CA 的自签名证书： makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
从受信任的根 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
添加了指向的HOSTS文件条目myapp.local127.0.0.1
创建了一个绑定到myapp.local域并且只侦听HTTPS请求的IIS 8.5应用程序
将myapp.local证书分配给网站

通过此设置，我可以轻松地从 Chrome 访问我的本地网站，而且没有任何证书或安全警告。正如预期的那样，浏览器显示了绿色挂锁。

什么不起作用

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

认为这可能是 Windows 中启用的密码套件的问题（但不是此类方面的专家），我下载了最新版本的IIS Crypto。我单击了“最佳实践”按钮，单击“应用”，然后重新启动了我的机器。

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

Run Code Online (Sandbox Code Playgroud)

和回应：

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

Run Code Online (Sandbox Code Playgroud)

什么在起作用

基于哈坎·林奎斯特的回答，非常详细，显然，彻底深入研究的答案在这里，我重新配置IIS加密以下设置，这消除了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

Answer 1

Håk*_*ist 22

根据https://http2.github.io/http2-spec/#rfc.section.9.2.2 的Http/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 部署必须支持 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] 和 P-256 椭圆曲线 [FIPS186]。

请注意，客户端可能会宣传对黑名单上的密码套件的支持，以允许连接到不支持 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椭圆曲线（TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256在 Windows 上标识为）放在列表的顶部，或者至少放在黑名单中包含的任何内容之前？

归档时间：	10 年，1 月前
查看次数：	51092 次
最近记录：	9 年，2 月前