Paquete de solicitudes WinHTTP y python, no se puede validar el certificado que contiene un CN válido pero un SAN no válido

Question

Paquete de solicitudes WinHTTP y python, no se puede validar el certificado que contiene un CN válido pero un SAN no válido

#1 de Steffen Ullrich (2 votos)

1

Estamos utilizando WinHTTP para enviar llamadas a la API desde nuestro cliente. Ahora de acuerdo con Common Criteria, FCS_TLSC_EXT.1.2 actividad de aseguramiento Prueba 2, si el certificado contiene un CN (nombre común) válido pero SAN (nombre alternativo del sujeto), la conexión debería fallar.

Prueba 2: el evaluador deberá presentar un certificado de servidor que contenga un CN que coincide con el identificador de referencia, contiene la extensión SAN, pero no contiene un identificador en la SAN que coincida con la referencia identificador El evaluador deberá verificar que la conexión falla. los El evaluador repetirá esta prueba para cada tipo de SAN compatible.

herramienta que estamos usando para generar un certificado con CN válido pero SAN no válido .

Sin embargo, con WinHTTP y el paquete de solicitudes de python, aceptan la SAN no válida (que no debería ocurrir). Parece que no hay documentación en WinHTTP sobre cómo se puede manejar esto. esta es la implementación interna de WinHTTP.

Internet Explorer también falla esta prueba y acepta la conexión. Sin embargo, Chrome niega la conexión y confirma que el certificado no es válido (que es el comportamiento requerido):

La prueba también falla con la biblioteca de solicitud de python.

Estamos buscando alguna forma si esto se puede modificar para verificar el problema. ¿O es que nosotros solo estamos enfrentando el problema?

Dado que las bibliotecas de Python y Windows se usan comúnmente, ¿es este comportamiento común? ¿Alguien más ha experimentado este problema?

Quiero saber si esta es la forma en que WInHTTP implementa la verificación de SAN, o es solo nuestra implementación. Además, no pude encontrar ninguna documentación en MSDN con respecto a la comprobación de SAN en WinHTTP.

tls certificates common-criteria

pregunta Muhammad Uzair Khan 27.02.2018 - 14:26

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates common-criteria

DTLS Grabe con un texto de cifrado extraño Banco solicitando una contraseña para el documento encriptado

score 2 · Accepted Answer

En primer lugar, el problema no es sobre la CN válida frente a la SAN no válida, sino sobre una CN que coincide con el dominio contra una SAN que no coincide con el dominio. Una SAN no coincidente sigue siendo una entrada SAN válida.

La regla de acuerdo con RFC 6125 es que la CN no DEBE ser verificada si hay una entrada de SAN SAN. Además, la CN está en desuso durante mucho tiempo y el RFC 6125 agrega explícitamente que la CN PUEDE verificarse si no existen registros SAN escritos correctamente y no los requiere. Aún así, la mayoría de las implementaciones comprueban tanto SAN como CN. Solo Chrome no comprueba el CN en absoluto desde hace un tiempo. Esta es la razón principal por la que el problema parece solucionarse con Chrome pero no con otros y esto en realidad viola "La verificación con el nombre común se requiere para los fines de compatibilidad hacia atrás" de FCS_TLSC_EXT.1.2.

... y el paquete de solicitudes de Python, aceptan la SAN no válida

Hasta donde puedo ver, la versión actual de las solicitudes utiliza la funcionalidad de este módulo ssl en Python para validar el nombre de host. El código aquí en la última versión de Python se asegura explícitamente de que CN solo se verifica si no existen nombres DNS de SAN. Por supuesto, esto puede variar con la versión desconocida de Python y las solicitudes que esté utilizando.

Quiero saber si esta es la forma en que WInHTTP implementa la verificación de SAN, o es solo nuestra implementación

Aunque no puedo estar seguro porque no conozco su implementación, existe una gran posibilidad de que al menos la versión de WinHTTP que está utilizando implemente la verificación de CN, además de SAN, al menos de manera predeterminada. Esto es similar a muchas otras implementaciones, aunque no coincide con el RFC 6125 ni con el anterior RFC 2818.