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


20

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
    .


Antes de que alguien señale lo obvio: Sí, soy consciente de que makecert.exeestá en desuso. Solo lo uso para escenarios de desarrollo como este porque es la opción más fácil que [solía hacerlo].
NathanAldenSr

Quizás no sea el cifrado sino la versión SSL / TLS que está habilitada. ¿Tienes tls v1.0 o inferior habilitado?
Drifter104

Actualicé la pregunta para incluir lo que hice con IIS Crypto para controlar esa configuración. ¿Sabes si la configuración es demasiado permisiva para HTTP / 2 y Chrome?
NathanAldenSr

stackoverflow.com/questions/31746620/… puede ayudar. Aparentemente, deshabilitar spdy en el navegador es el camino a seguir
Drifter104

1
IIS Crypto "Best Practices" en la versión 2.0 solucionó este error para mí. Intenté usar el orden de suite que especificó pero no tuvo efecto. Aparentemente, se ha solucionado en Windows o IIS Crypto en algún lugar del camino. :)
ahwm

Respuestas:


21

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?


Intentaré esto de inmediato y les haré saber cómo resulta. ¡Gracias por la respuesta detallada! :) Honestamente, parece que este problema de la suite de cifrado puede hacer que usar HTTP / 2 al mismo tiempo que HTTP / 1.1 sea realmente complicado, si no imposible, hasta que se garantice que los navegadores resuelvan las inconsistencias. IPv4 / IPv6, alguien?
NathanAldenSr

Comparé la lista de conjuntos de cifrado de "mejores prácticas" de IIS Crypto con la lista negra. Lo que encontré es que todas las TLS_RSAsuites de cifrado de mejores prácticas están en la lista negra. Los deshabilité a todos y reinicié. Sin embargo, ahora no puedo establecer una conexión segura a mi sitio web local con ningún navegador. Acabo de llegar ERR_CONNECTION_RESET. ¿Podría esto tener algo que ver con los propios certificados?
NathanAldenSr

@NathanAldenSr No creo que necesite eliminar los cifrados incluidos en la lista negra (pueden ser útiles para fines de compatibilidad para clientes HTTP / 1.x) siempre que los cifrados no incluidos en la lista negra tengan mayor prioridad. En particular, el mencionado menciona que todas las implementaciones de HTTP / 2 DEBEN soportar ( TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
Håkan Lindqvist

1
Gracias por el punto de partida. He actualizado mi respuesta para mostrar lo que funcionó para mí.
NathanAldenSr

1
Tenga en cuenta que la especificación HTTP / 2 dice que es TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 con la curva elíptica P-256 [FIPS186], que significa la cadena: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_P256para Windows.
Bart Verkoeijen

2

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.


Ajustar sus conjuntos de cifrado (posiblemente solo el pedido) para cumplir con las especificaciones Http / 2 debería resolver el problema correctamente. (Ver respuesta por separado)
Håkan Lindqvist

3
Parece que debe reiniciar Windows para que estos cambios surtan efecto. Solo llamar iisresetno fue suficiente para mí.
Sebastian Krysmanski,

-1

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.


1
Esto no funcionará para mí, desafortunadamente. Tengo scripts automatizados que generan estos certificados para entornos locales y de desarrollo, y la estación de trabajo de cada desarrollador los necesita. Además, quiero la flexibilidad para poder cambiar los nombres de host sin tener que volver a un tercero para obtener nuevos certificados.
NathanAldenSr

@NathanAldenSr - Entiendo. Para un proceso totalmente programado, estamos utilizando una CA interna local. Sería bueno saber si los makecert.execertificados de creación propia son el problema. Nunca usé makecert.exe, siempre pensé que una CA local es una solución mucho más limpia.
Peter Hahndorf
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.