Chrome signale que ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY se connecte au serveur Web local via HTTPS

Sommaire

Chrome signale ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYlorsque j'essaie de me connecter à mon serveur Web local via HTTPS. Je suis presque certain que ce problème est lié à ma récente mise à niveau de Windows 10, mais je ne sais pas comment le résoudre.

Ce qui a fonctionné

Voici la chaîne des événements, Windows 8.1 Pro étant installé au début:

1. Généré un certificat auto-signé destiné à être utilisé comme autorité de certification racine approuvée à l'aide de la commande suivante: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
2. Généré un certificat spécifique à l'application à partir de l'autorité de certification racine de confiance: 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. Ajout d'une HOSTSentrée de fichier pour myapp.locallaquelle pointe vers127.0.0.1
4. Création d'une application IIS 8.5 liée au myapp.localdomaine et à l'écoute des demandes HTTPS uniquement
5. Attribué le myapp.localcertificat au site Web

Avec cette configuration, je n'ai eu aucun problème pour accéder à mon site Web local à partir de Chrome sans certificat ni avertissement de sécurité. Le navigateur a affiché le cadenas vert, comme prévu.

Ce qui ne marche pas

Récemment, j'ai mis à niveau vers Windows 10. Je ne savais pas à l'époque que Windows 10 était livré avec IIS 10, qui prend en charge HTTP / 2. Maintenant, lorsque j'essaie d'accéder à mes sites Web locaux avec Chrome, je reçois une ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYerreur. Je dois noter que la même demande envoyée depuis Edge n'entraîne pas d'erreur et utilise HTTP / 2 pour la connexion. Une recherche rapide sur Google n'a pas semblé prometteuse, sauf pour laisser entendre que le problème pourrait être que HTTP / 2 ou Chrome est strict quant aux chiffrements qu'il acceptera dans les certificats SSL.

Pensant que cela peut être un problème avec les suites de chiffrement activées dans Windows (mais n'étant pas un expert dans de telles choses), j'ai téléchargé la dernière version de IIS Crypto . J'ai cliqué sur le bouton Meilleures pratiques, cliqué sur Appliquer et redémarré ma machine.

IIS Crypto signale ces paramètres comme des "meilleures pratiques":

• Protocoles activés: TLS 1.0, TLS 1.1, TLS 1.2
• Chiffres activés: Triple DES 168, AES 128/128, AES 256/256
• Hachage activé: MD5, SHA, SHA 256, SHA 384, SHA 512
• Échanges de clés activés: Diffie-Hellman, PKCS, ECDH

• Commande de suite de chiffrement 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

J'ajouterai également que l'application de navigateur que je développe n'a pas besoin d'être utilisable à partir de Windows XP. Je sais que Windows XP ne prend pas en charge les nouveaux protocoles.

Informations détaillées sur la négociation HTTPS

J'ai décidé d'utiliser Fiddler pour intercepter la négociation HTTPS. Voici ce que Fiddler a rapporté à propos de la demande:

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

et la réponse:

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

Ce qui fonctionne

Sur la base de la réponse de Håkan Lindqvist et de la réponse très détaillée et apparemment approfondie ici , j'ai reconfiguré IIS Crypto avec les paramètres suivants, ce qui a éliminé l'erreur Chrome:

• Protocoles activés: TLS 1.0, TLS 2.0, TLS 3.0
• Chiffres activés: AES 128/128, AES 256/256
• Hachage activé: SHA, SHA 256, SHA 384, SHA 512
• Échanges de clés activés: Diffie-Hellman, PKCS, ECDH

• Commande de suite de chiffrement 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

Exigences Http / 2 selon https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 Suites de chiffrement TLS 1.2

Un déploiement de HTTP / 2 sur TLS 1.2 NE DEVRAIT PAS utiliser les suites de chiffrement répertoriées dans la liste noire des suites de chiffrement ( annexe A ).

Les points d'extrémité PEUVENT choisir de générer une erreur de connexion (Section 5.4.1) de type INADEQUATE_SECURITY si l'une des suites de chiffrement de la liste noire est négociée. Un déploiement qui choisit d'utiliser une suite de chiffrement sur liste noire risque de déclencher une erreur de connexion à moins que l'ensemble de pairs potentiels ne soit connu pour accepter cette suite de chiffrement.

Les implémentations NE DOIVENT PAS générer cette erreur en réaction à la négociation d'une suite de chiffrement qui ne figure pas sur la liste noire. Par conséquent, lorsque les clients proposent une suite de chiffrement qui ne figure pas sur la liste noire, ils doivent être prêts à utiliser cette suite de chiffrement avec HTTP / 2.

La liste noire inclut la suite de chiffrement que TLS 1.2 rend obligatoire, ce qui signifie que les déploiements de TLS 1.2 pourraient avoir des ensembles non entrecroisés de suites de chiffrement autorisées. Pour éviter ce problème entraînant des échecs de négociation TLS, les déploiements de HTTP / 2 qui utilisent TLS 1.2 DOIVENT prendre en charge TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] avec la courbe elliptique P-256 [FIPS186].

Notez que les clients peuvent annoncer la prise en charge des suites de chiffrement qui sont sur la liste noire afin de permettre la connexion à des serveurs qui ne prennent pas en charge HTTP / 2. Cela permet aux serveurs de sélectionner HTTP / 1.1 avec une suite de chiffrement qui figure sur la liste noire HTTP / 2. Cependant, cela peut entraîner la négociation de HTTP / 2 avec une suite de chiffrement sur liste noire si le protocole d'application et la suite de chiffrement sont sélectionnés indépendamment.

Votre chiffre négocié TLS_RSA_WITH_AES_128_GCM_SHA256figure dans la liste noire Http / 2 mentionnée ci-dessus (et liée).

Je pense que vous souhaiterez ajuster vos suites de chiffrement (commande?) Pour répondre aux exigences ci-dessus. Peut-être simplement mettre TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256avec la P-256courbe elliptique NIST (identifiée comme TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256sous Windows) en haut de la liste, ou au moins avant tout ce qui est inclus dans la liste noire?

Voici quelques PowerShell que j'ai créés pour désactiver temporairement HTTP / 2 dans 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

J'en fais une réponse car la désactivation de HTTP / 2 semble être la seule "solution" au problème. Je ne l'accepterai pas, cependant, car j'aimerais vraiment utiliser HTTP / 2 dans IIS 10 de manière fiable avec tous les navigateurs.

Obtenez simplement un certificat d'une autorité de certification appropriée, il y en a des gratuits ( StartSSL ) et cela ne prend pas beaucoup de temps pour en obtenir un.

Lors de l'utilisation d'un certificat approprié, je n'ai eu aucun problème avec IIS 10 sur Windows 10 et HTTP / 2 avec Chrome.