web-dev-qa-db-fra.com

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

Résumé

Chrome signale ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY lorsque 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 entrée de fichier HOSTS pour myapp.local qui pointe vers 127.0.0.1
  4. Création d'une IIS 8.5 application liée à myapp.local domaine et écoute uniquement les demandes HTTPS
  5. Attribué le myapp.local certificat sur le 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 fonctionne 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 un ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY Erreur. 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 en la matière), 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 ne pas doit être utilisable à partir de Windows XP. Je sais qu'il y a des problèmes avec Windows XP ne prenant pas en charge les protocoles plus récents.

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é le 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

iisssl-certificatehttpsgoogle-chromewindows-10
21
NathanAldenSr

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 l'une des suites de chiffrement répertoriées dans la liste noire de la suite 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_SHA256 figure 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_SHA256 avec le NIST P-256 courbe elliptique (identifiée comme TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256 sous Windows) en haut de la liste, ou au moins avant tout ce qui est inclus dans la liste noire?

22
Håkan Lindqvist

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.

3
NathanAldenSr

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 à utiliser IIS 10 sur Windows 10 et HTTP/2 avec Chrome.

0
Peter Hahndorf