Chrome informa que ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY se conecta al servidor web local a través de HTTPS

Resumen

Chrome informa ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYcuando intento conectarme a mi servidor web local a través de HTTPS. Estoy casi seguro de que este problema tiene que ver con mi reciente actualización de Windows 10, pero no sé cómo solucionarlo.

Lo que funcionó

Aquí está la cadena de eventos, con Windows 8.1 Pro instalado al principio:

1. Generó un certificado autofirmado destinado a ser utilizado como CA raíz de confianza utilizando el siguiente comando: makecert.exe -pe -ss Root -sr LocalMachine -n "CN=local, OU=development" -r -a sha512 -e 01/01/2020
2. Generó un certificado específico de la aplicación de la CA raíz de confianza: 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. Se agregó una HOSTSentrada de archivo paramyapp.local que apunta a127.0.0.1
4. Creó una aplicación IIS 8.5 que está vinculada a myapp.local dominio y escucha solo las solicitudes HTTPS
5. Asignado el myapp.localcertificado al sitio web

Con esta configuración, no tuve problemas para acceder a mi sitio web local desde Chrome sin ningún certificado o advertencia de seguridad. El navegador mostró el candado verde, como se esperaba.

Lo que no funciona

Recientemente, actualicé a Windows 10. No sabía en ese momento que Windows 10 viene con IIS 10, que admite HTTP / 2. Ahora, cuando intento acceder a mis sitios web locales con Chrome, recibo un ERR_SPDY_INADEQUATE_TRANSPORT_SECURITYerror. Debo tener en cuenta que la misma solicitud enviada desde Edge no genera un error y utiliza HTTP / 2 para la conexión. Una búsqueda rápida en Google no arrojó nada prometedor, excepto para insinuar que el problema podría ser que HTTP / 2 o Chrome son estrictos acerca de los cifrados que aceptará en los certificados SSL.

Pensando que puede ser un problema con las suites de cifrado habilitadas en Windows (pero no siendo un experto en tales cosas), descargué la última versión de IIS Crypto . Hice clic en el botón Mejores prácticas, hice clic en Aplicar y reinicié mi máquina.

IIS Crypto informa estas configuraciones como "mejores prácticas":

• Protocolos habilitados: TLS 1.0, TLS 1.1, TLS 1.2
• Cifrados habilitados: Triple DES 168, AES 128/128, AES 256/256
• Hashes habilitados: MD5, SHA, SHA 256, SHA 384, SHA 512
• Intercambios de claves habilitados: Diffie-Hellman, PKCS, ECDH

• Orden del conjunto de cifrado 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

También agregaré que la aplicación de navegador que estoy desarrollando no necesita ser utilizable desde Windows XP. Sé que hay algunos problemas acerca de que Windows XP no admite protocolos más nuevos.

Información detallada sobre la negociación HTTPS

Decidí usar Fiddler para interceptar la negociación HTTPS. Esto es lo que Fiddler informó sobre la solicitud:

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

y la respuesta:

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

Que funciona

Basado en la respuesta de Håkan Lindqvist, y la respuesta muy detallada y aparentemente investigada aquí , reconfiguré IIS Crypto con la siguiente configuración, lo que eliminó el error de Chrome:

• Protocolos habilitados: TLS 1.0, TLS 2.0, TLS 3.0
• Cifrados habilitados: AES 128/128, AES 256/256
• Hashes habilitados: SHA, SHA 256, SHA 384, SHA 512
• Intercambios de claves habilitados: Diffie-Hellman, PKCS, ECDH

• Orden del conjunto de cifrado 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_128_CBC_SHA_P521
  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
  
  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_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
  
  
  
  TLS_RSA_WITH_AES_128_CBC_SHA256
  TLS_A_25_C__SU_C_S_25
  .

Requisitos de Http / 2 según https://http2.github.io/http2-spec/#rfc.section.9.2.2 :

9.2.2 Suites de cifrado TLS 1.2

Una implementación de HTTP / 2 sobre TLS 1.2 NO DEBE utilizar ninguno de los conjuntos de cifrado que se enumeran en la lista negra del conjunto de cifrado ( Apéndice A ).

Los puntos finales PUEDEN optar por generar un error de conexión (Sección 5.4.1) de tipo INADEQUATE_SECURITY si se negocia uno de los conjuntos de cifrado de la lista negra. Una implementación que elige usar un conjunto de cifrado en la lista negra corre el riesgo de provocar un error de conexión a menos que se sepa que el conjunto de pares potenciales acepta ese conjunto de cifrado.

Las implementaciones NO DEBEN generar este error en reacción a la negociación de un conjunto de cifrado que no está en la lista negra. En consecuencia, cuando los clientes ofrecen un conjunto de cifrado que no está en la lista negra, deben estar preparados para usar ese conjunto de cifrado con HTTP / 2.

La lista negra incluye el conjunto de cifrado que TLS 1.2 hace obligatorio, lo que significa que las implementaciones de TLS 1.2 podrían tener conjuntos no intersectados de conjuntos de cifrado permitidos. Para evitar este problema que causa fallas en el protocolo de enlace TLS, las implementaciones de HTTP / 2 que usan TLS 1.2 DEBEN admitir TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] con la curva elíptica P-256 [FIPS186].

Tenga en cuenta que los clientes pueden anunciar el soporte de conjuntos de cifrado que están en la lista negra para permitir la conexión a servidores que no admiten HTTP / 2. Esto permite a los servidores seleccionar HTTP / 1.1 con un conjunto de cifrado que se encuentra en la lista negra de HTTP / 2. Sin embargo, esto puede hacer que se negocie HTTP / 2 con un conjunto de cifrado en la lista negra si el protocolo de aplicación y el conjunto de cifrado se seleccionan de forma independiente.

Su cifrado negociado TLS_RSA_WITH_AES_128_GCM_SHA256está en la lista negra Http / 2 mencionada anteriormente (y vinculada).

Creo que querrá ajustar sus conjuntos de cifrado (¿pedidos?) Para cumplir con los requisitos anteriores. ¿Tal vez simplemente colocando TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256con la P-256curva elíptica NIST (identificada como TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256en Windows) en la parte superior de la lista, o al menos antes de cualquier cosa incluida en la lista negra?

Aquí hay algunos PowerShell que creé para deshabilitar temporalmente HTTP / 2 en 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

Estoy respondiendo esto porque deshabilitar HTTP / 2 parece ser la única "solución" al problema. Sin embargo, no lo aceptaré, ya que realmente me gustaría usar HTTP / 2 en IIS 10 de manera confiable con todos los navegadores.

Simplemente obtenga un certificado de una CA adecuada, hay otros gratuitos ( StartSSL ) y no toma mucho más tiempo obtener uno.

Cuando utilicé un certificado adecuado, no tuve ningún problema con el uso de IIS 10 en Windows 10 y HTTP / 2 con Chrome.