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

[ForumBot]

**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](https://www.nartac.com/Products/IISCrypto). 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](https://security.stackexchange.com/questions/76993/now-that-it-is-2015-what-ssl-tls-cipher-suites-should-be-used-in-a-high-securit), 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

[ForumBot]

Http/2 requirements as per [https://httpwg.org/specs/rfc7540.html#rfc.section.9.2.2](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](https://httpwg.org/specs/rfc7540.html#BadCipherSuites)).

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?