Chrome segnala ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY che si connette al server Web locale tramite HTTPS

Sommario

Chrome segnala ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYquando provo a connettermi al mio server Web locale tramite HTTPS. Sono quasi certo che questo problema abbia a che fare con il mio recente aggiornamento di Windows 10, ma non so come risolverlo.

Cosa ha funzionato

Ecco la catena di eventi, con Windows 8.1 Pro installato all'inizio:

1. Generato un certificato autofirmato destinato all'uso come CA radice attendibile utilizzando il comando seguente: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
2. Generato un certificato specifico dell'applicazione dalla CA radice attendibile: 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. Aggiunta una HOSTSvoce di file per myapp.localquesto punto a127.0.0.1
4. Creata un'applicazione IIS 8.5 che è associata al myapp.localdominio e ascolta solo le richieste HTTPS
5. Assegnato il myapp.localcertificato al sito Web

Con questa configurazione, non ho avuto problemi ad accedere al mio sito Web locale da Chrome senza alcun certificato o avviso di sicurezza. Il browser ha visualizzato il lucchetto verde, come previsto.

Cosa non funziona

Di recente, ho eseguito l'aggiornamento a Windows 10. All'epoca non sapevo che Windows 10 fosse fornito con IIS 10, che supporta HTTP / 2. Ora, quando provo ad accedere ai miei siti Web locali con Chrome, ricevo un ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYerrore. Devo notare che la stessa richiesta inviata da Edge non provoca un errore e utilizza HTTP / 2 per la connessione. Una rapida ricerca su Google non ha rivelato nulla di promettente, tranne per suggerire che il problema potrebbe essere che HTTP / 2 o Chrome sono rigidi su quali cifre accetteranno nei certificati SSL.

Pensando che potrebbe essere un problema con le suite di crittografia abilitate in Windows (ma non essendo un esperto in tali cose), ho scaricato l'ultima versione di IIS Crypto . Ho fatto clic sul pulsante Best practice, ho fatto clic su Applica e ho riavviato il mio computer.

IIS Crypto segnala queste impostazioni come "best practice":

• Protocolli abilitati: TLS 1.0, TLS 1.1, TLS 1.2
• Cifre abilitate: Triple DES 168, AES 128/128, AES 256/256
• Hash abilitati: MD5, SHA, SHA 256, SHA 384, SHA 512
• Scambi chiave abilitati: Diffie-Hellman, PKCS, ECDH

• Ordine della suite di crittografia 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

Aggiungerò anche che l'applicazione del browser che sto sviluppando non deve essere utilizzabile da Windows XP. So che ci sono alcuni problemi su Windows XP che non supportano i protocolli più recenti.

Informazioni dettagliate sulla negoziazione HTTPS

Ho deciso di utilizzare Fiddler per intercettare la negoziazione HTTPS. Ecco cosa ha riferito Fiddler in merito alla richiesta:

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

e la risposta:

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

Cosa sta funzionando

Sulla base di risposta di Håkan Lindqvist, e la risposta molto dettagliata e apparentemente-accuratamente studiate qui , ho riconfigurato IIS Crypto con le seguenti impostazioni, che ha eliminato l'errore di Chrome:

• Protocolli abilitati: TLS 1.0, TLS 2.0, TLS 3.0
• Cifre abilitate: AES 128/128, AES 256/256
• Hash abilitati: SHA, SHA 256, SHA 384, SHA 512
• Scambi chiave abilitati: Diffie-Hellman, PKCS, ECDH

• Ordine della suite di crittografia 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

Requisiti Http / 2 secondo https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 Suite di cifratura TLS 1.2

Una distribuzione di HTTP / 2 su TLS 1.2 NON DOVREBBE utilizzare nessuna delle suite di crittografia elencate nella black list della suite di crittografia ( Appendice A ).

Gli endpoint possono scegliere di generare un errore di connessione (Sezione 5.4.1) di tipo INADEQUATE_SECURITY se viene negoziata una delle suite di cifratura della black list. Una distribuzione che sceglie di utilizzare una suite di crittografia nella black list rischia di innescare un errore di connessione a meno che non sia noto che l'insieme di potenziali peer accetti quella suite di crittografia.

Le implementazioni NON DEVONO generare questo errore in risposta alla negoziazione di una suite di cifratura che non è nella lista nera. Di conseguenza, quando i client offrono una suite di crittografia che non è nella black list, devono essere pronti a utilizzare quella suite di crittografia con HTTP / 2.

La black list include la suite di crittografia che TLS 1.2 rende obbligatoria, il che significa che le distribuzioni TLS 1.2 potrebbero avere insiemi non intersecanti di suite di crittografia consentite. Per evitare questo problema che causa errori di handshake TLS, le distribuzioni di HTTP / 2 che utilizzano TLS 1.2 DEVONO supportare TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] con la curva ellittica P-256 [FIPS186].

Si noti che i client potrebbero pubblicizzare il supporto delle suite di crittografia presenti nella black list per consentire la connessione a server che non supportano HTTP / 2. Ciò consente ai server di selezionare HTTP / 1.1 con una suite di crittografia che si trova nell'elenco nero HTTP / 2. Tuttavia, ciò può comportare la negoziazione di HTTP / 2 con una suite di crittografia in black list se il protocollo dell'applicazione e la suite di crittografia sono selezionati in modo indipendente.

La cifra negoziata TLS_RSA_WITH_AES_128_GCM_SHA256è nella lista nera Http / 2 sopra menzionata (e collegata).

Credo che vorrai adattare le tue suite di cifratura (ordinando?) Per soddisfare i requisiti di cui sopra. Forse semplicemente inserendo TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256la P-256curva ellittica NIST (identificata come TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256su Windows) in cima all'elenco, o almeno prima di qualsiasi cosa inclusa nella lista nera?

Ecco alcuni PowerShell che ho creato per disabilitare temporaneamente HTTP / 2 in IIS:

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

Sto rispondendo a questa domanda poiché la disabilitazione di HTTP / 2 sembra essere l'unica "soluzione" al problema. Non lo accetterò, però, poiché mi piacerebbe davvero usare HTTP / 2 in IIS 10 in modo affidabile con tutti i browser.

Basta ottenere un certificato da una CA corretta, ce ne sono di gratuiti ( StartSSL ) e non ci vuole molto tempo per ottenerne uno.

Quando ho usato un certificato appropriato non ho avuto problemi con l'utilizzo di IIS 10 su Windows 10 e HTTP / 2 con Chrome.