Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Chrome signale ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY lors de la connexion au serveur web local via HTTPS

ayi

Summary

Chrome is reporting ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY quand I try et connect to mon local web server over HTTPS. Je suis almost certain this problem has to do avec mon recent Windows 10 upgrade, mais Je ne know how to fix it.

What worked

Voici le chain of events, avec me having Windows 8.1 Pro installed at le start:

Generated a self-signed certificate intended for use as a trusted root CA using le suivant command: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
Generated an application-specific certificate depuis le trusted root 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
Added a HOSTS file entry for myapp.local that points to 127.0.0.1
Created an IIS 8.5 application that is bound to le myapp.local domain et listens for HTTPS requests only
Assigned le myapp.local certificate to le web site

With this setup, I had no trouble accessing mon local web site depuis Chrome sans tout certificate ou security warnings. The browser displayed le green padlock, as expected.

What ne work

Recently, I upgraded to Windows 10. I did pas know at le time that Windows 10 ships avec IIS 10, qui supports HTTP/2. Now, quand I try et access mon local web sites avec Chrome, I receive an ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY error. I should note that le même request sent depuis Edge does pas result in an error et does use HTTP/2 for le connection. A cursory Google search didn't turn up anything promising, except to hint that le problem might be that HTTP/2 ou Chrome is strict about what ciphers it will accept in SSL certificates.

Thinking it may be an issue avec enabled cipher suites in Windows (but pas being an expert in such things), I downloaded le latest version of IIS Crypto. I clicked le Best Practices button, clicked Apply, et restarted mon machine.

IIS Crypto reports these settings as "best practices":

Enabled protocols: TLS 1.0, TLS 1.1, TLS 1.2
Enabled ciphers: Triple DES 168, AES 128/128, AES 256/256
Enabled hashes: MD5, SHA, SHA 256, SHA 384, SHA 512
Enabled key exchanges: Diffie-Hellman, PKCS, ECDH

SSL cipher suite order:

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

Je vais aussi add that le browser application Je suis developing does not need to be usable depuis Windows XP. Je sais there are certains issues about Windows XP pas supporting newer protocols.

Detailed information about le HTTPS negotiation

I decided to use Fiddler to intercept le HTTPS negotiation. Voici what Fiddler reported about le request:

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

and le response:

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

Quel est working

Based on Håkan Lindqvist's answer, et le très detailed et apparently-thoroughly-researched answer here, I reconfigured IIS Crypto avec le suivant settings, qui eliminated le Chrome error:

Enabled protocols: TLS 1.0, TLS 2.0, TLS 3.0
Enabled ciphers: AES 128/128, AES 256/256
Enabled hashes: SHA, SHA 256, SHA 384, SHA 512
Enabled key exchanges: Diffie-Hellman, PKCS, ECDH

SSL cipher suite order:

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

ayi

Http/2 requirements as per https://httpwg.org/specs/rfc7540.html#rfc.section.9.2.2 :

9.2.2 TLS 1.2 Cipher Suites

A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use tout of le cipher suites that are listed in le cipher suite black list (Appendix A).

Endpoints MAY choose to generate a connection error (Section 5.4.1) of type INADEQUATE_SECURITY si one of le cipher suites depuis le black list is negotiated. A deployment that chooses to use a black-listed cipher suite risks triggering a connection error sauf si le set of potential peers is known to accept that cipher suite.

Implementations MUST NOT generate this error in reaction to le negotiation of a cipher suite that is pas on le black list. Consequently, quand clients offer a cipher suite that is pas on le black list, they have to be prepared to use that cipher suite avec HTTP/2.

The black list includes le cipher suite that TLS 1.2 makes mandatory, qui means that TLS 1.2 deployments could have non-intersecting sets of permitted cipher suites. To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] avec le P-256 elliptic curve [FIPS186].

Note that clients might advertise support of cipher suites that are on le black list in order to allow for connection to servers that do pas support HTTP/2. This allows servers to select HTTP/1.1 avec a cipher suite that is on le HTTP/2 black list. Cependant, this can result in HTTP/2 being negotiated avec a black-listed cipher suite si le application protocol et cipher suite are independently selected.

Your negotiated cipher TLS_RSA_WITH_AES_128_GCM_SHA256 is in le ci-dessus mentioned (and linked) Http/2 blacklist.

Je crois you will want to adjust votre cipher suites (ordering?) to meet le ci-dessus requirements. Maybe simply putting TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 avec le NIST P-256 elliptic curve (identified as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256 on Windows) at le top of le list, ou at least avant anything included in le blacklist?