Los sitios web que buscan mantener la máxima compatibilidad con los navegadores (heredados) pueden desear servir cadenas de certificados firmados por SHA2 a aquellos agentes de usuarios que los admiten, y SHA1 a aquellos que no lo hacen.
La especificación TLS 1.2 ( enlace ) define una nueva extensión signature_algorithm que, cuando lo envía el navegador, se puede usar para detectar el soporte para SHA2. Por ejemplo, si el navegador incluye "SHA256 / RSA" le dice al servidor que admite este par de algoritmo de firma / hash específico. Luego, el servidor puede seleccionar una cadena compatible y devolverla, o retroceder a algo como "SHA / RSA".
Sin embargo, hay dos problemas principales relacionados con esta extensión:
- RFC 5246 especifica que es opcional (consulte la sección 7.4.1.4.1)
Si el cliente admite solo los algoritmos de hash y firma predeterminados (enumerados en esta sección), PUEDE omitir la extensión signature_algorithms. Si el cliente no admite los algoritmos predeterminados, o admite otros algoritmos hash y de firma (y está dispuesto a usarlos para verificar los mensajes enviados por el servidor, es decir, certificados de servidor e intercambio de claves del servidor), DEBE enviar la extensión signature_algorithms, listando los algoritmos que está dispuesto a aceptar.
- Algunos navegadores (por ejemplo, Android 2.3-4.3) admiten SHA2 pero no TLS 1.2 (consulte matriz de características )
- Si la lógica del lado del servidor requiere la extensión, puede "sobrepasar" los certificados SHA1 a los clientes que de otro modo podrían procesar SHA2.
Dadas las dos deficiencias anteriores, ¿hay alguna otra parte del mensaje de TLS ClientHello que se pueda usar para detectar el soporte SHA2?
La idea original era ver si SHA256 aparecía en el campo PRF / MAC de un conjunto de cifrado (por ejemplo, el SHA256 al final de TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256), pero parece que estos también estarán presentes a partir de TLS 1.2). / p>