¿Cómo hacer que los navegadores TLS "modernos" y "obsoletos" sean compatibles?

El tema fue impulsado por una discusión del post anterior , en el que sonaba la voz de un administrador de servidor web atento: TLS 1.2 y AEAD son la elección de una persona sana, pero ¿quién se arrepentirá de los usuarios de navegadores "obsoletos"? Analicemos esto: la supuesta incompatibilidad entre el TLS "moderno" y los navegadores "heredados".



La hipótesis es la siguiente: si solo se dejan en el servidor web versiones estables del protocolo de seguridad de la capa de transporte TLS (1.2 y 1.3) y conjuntos de cifrado (AEAD), los usuarios de navegadores "obsoletos" no podrán acceder al sitio.



Hagamos una excursión opcional a la historia ... En 2005 (es decir, hace 16 años), la Agencia de Seguridad Nacional de EE. UU. Anunció un corpus de estándares, pautas, recomendaciones y otros documentos de respaldo sobre el uso de algoritmos criptográficos: NSA Suite B Cryptography.



En 2009, IETF publicó RFC5430Perfil de la suite B para la seguridad de la capa de transporte, que estableció qué protocolos y conjuntos de cifrado deben usarse para las conexiones HTTPS a fin de cumplir con los requisitos de la NSA. Incluso entonces, para cumplir con estos requisitos, el servidor web y el navegador web tenían que admitir TLS versión 1.2 y los conjuntos de cifrado TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 y TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.



Es decir, durante al menos los últimos 11 años, los desarrolladores han sabido qué requisitos deben cumplir sus productos para poder calificar para una orden del gobierno estadounidense. Por lo tanto, probablemente percibirá el siguiente hecho sin sorpresa: todos los navegadores que se utilizan actualmente son compatibles con el conjunto de cifrado mencionado en la versión con una clave de cifrado de 128 bits, y muchas (pero no todas), y con una de 256 bits.



Este podría ser el final del artículo, recomendando que todos los administradores de servidores web dejen el soporte solo para TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 y no se molesten con los mitos sobre la incompatibilidad de TLS 1.2 con navegadores "obsoletos", si no por un matiz: en versiones de TLS anteriores a 1.3, el algoritmo de firma digital debe estar en cifrado coincidiendo con el algoritmo en el certificado TLS, y menos del 6% de los servidores web con certificado firmado usando el algoritmo ECDSA en la zona de dominio .RU , el resto se utilizan para firma RSA.



¿Quién tiene la culpa es una cuestión de un estudio aparte, nos interesa qué hacer? En primer lugar, recordemos que no solo la combinación ECDHE + ECDSA + AES recomendada por la NSA, sino también otras, se encuentran entre los conjuntos de cifrado más sólidos de la actualidad:





Un total de 19 conjuntos de cifrado fuerte, pero no todos son adecuados para su uso en la vida real en un servidor web público: el algoritmo de cifrado CAMELLIA, como AES en modo CCM, es compatible con poco más que nadie, con CHACHA20 y sus fieles companion POLY1305 son solo navegadores modernos relativamente familiares, y para usar conjuntos de cifrado basados ​​en ECDSA, como ya se mencionó, se requiere un certificado TLS apropiado. Por lo tanto, solo nos quedan 4 conjuntos de cifrado "adicionales":



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.



Es tentador suponer que si el navegador es compatible con la combinación ECDHE + ECDSA, definitivamente hará frente a ECDHE + RSA, pero este no es siempre el caso; muchos solo pueden usar DHE + RSA, y para satisfacer las solicitudes de todos los navegadores antiguos, en un sitio con un certificado RSA, necesita admitir dos conjuntos de cifrado:



TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256;

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Esto nos dará compatibilidad con al menos los siguientes sistemas operativos y navegadores:



Android 4.4.2 + Navegador de Android (Chrome);

Windows XP + Chrome 49 / Firefox 49 / Opera 12.18;

Windows 7 + Internet Explorer 11 / Chrome 31 / Firefox 31;

OS X + Firefox 29 / Chrome 37;

iOS 9 + Safari 9;

Java 8b.



No diré sobre los sistemas * nix, depende del ensamblaje, pero es obvio que el problema no existe como tal. El único problema surgirá con Windows Phone 8.1 + IE 10, que solo admiten una combinación estable: ECDHE + ECDSA.



Pero, ¿qué deberían hacer los usuarios de Windows XP + IE 6 o algunos Android 2.3? - preguntará el administrador atento. Continuarsentarse sin acceso a la Internet moderna, responderé, porque incluso el soporte del protocolo de servidor web SSL 2.0 no los ayudará. El hecho es que incluso si ejecuta Windows XP con todas las actualizaciones publicadas para él (hasta mayo de 2019) y actualiza el navegador estándar a la versión 8, esto solo brindará soporte para TLS 1.2, pero no para conjuntos de cifrado estables. Además, Windows XP no sabía ni aprendería qué son Indicación de nombre de servidor (SNI), HTML 5 Live HTML y CSS 3.



¿Estás listo por el obstinado "excavador y medio" para mantener una IP dedicada para el sitio y no actualizar el diseño? Luego agregue soporte, por ejemplo, TLS_RSA_WITH_AES_256_CBC_SHA256, sino que debe asumir que un usuario moderno de Windows XP ha estado usando durante mucho tiempo un navegador alternativo que incluso es compatible con TLS 1.3. Lo mismo es cierto para Android 2.3, instalando Firefox 27 en el que obtendremos soporte completo para TLS 1.2 y conjuntos de cifrado AEAD, y sin instalarlo, simplemente no podremos usar una parte significativa de los sitios modernos, incluso a través de HTTP.



Todo lo anterior, por supuesto, no es un llamado a abandonar el soporte para conjuntos de cifrado más fuertes, que serán exigidos por los navegadores modernos y que deberían proponerse para negociación en primer lugar.



Para no levantarse dos veces, considere brevemente la situación con curvas elípticas. La criptografía NSA Suite B reconoce solo dos de ellos: NIST P-384 y NIST P-256, cuya compatibilidad en el servidor web proporcionará acceso al sitio para navegadores modernos y "heredados". En realidad, es suficiente para admitir sólo NIST P-384 para "oldies" y Curve25519 para navegadores modernos; bueno, excepto quizás para agregar NIST P-521, para algunos "viejos avanzados".



Para resumir: si queremos que el sitio siga siendo accesible para navegadores "obsoletos", pero al mismo tiempo admitamos solo versiones estables del protocolo de seguridad de la capa de transporte y conjuntos de cifrado, procederemos de la siguiente manera.



Para un sitio con un certificado TLS firmado usando el algoritmo ECDSA, habilite la compatibilidad con el conjunto de cifrado TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.



Para un sitio con un certificado TLS firmado con el algoritmo RSA , habilite la compatibilidad con los conjuntos de cifrado TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 y TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.



Para ambos sitios, habilitaremos la compatibilidad con la curva elíptica NIST P-384 o NIST P-256 y estableceremos el orden de preferencia para los conjuntos de cifrado y las curvas elípticas, según el cual los conjuntos y curvas anteriores se ofrecen a los navegadores para que coincidan después de más los estables, por ejemplo, después de TLS_ECDHE_RSA_WITH_AES_ 256 _GCM_SHA 384 y Curve25519, respectivamente.