¿Se requiere la validación de la verificación CN/nombre de host con el certificado SSL en openssl y por qué?

Question

En la mayoría de los protocolos/aplicaciones que utilizan SSL, el cliente debe verificar AMBOS (1) que el servidor presente un certificado válido, es decir, uno emitido por una CA confiable y que no esté vencido, revocado o manipulado Y (2) que ese certificado sea para el servidor que desea, no a otra persona a quien su conexión fue dirigida por error o por un ataque deliberado. (Hay casos raros en los que no necesita autenticación del servidor, solo confidencialidad, pero probablemente sea mejor utilizar los conjuntos de cifrado "anon" o "aNULL" que explícitamente no autentican).

OpenSSL hasta la fecha hace (1) pero no (2)y normalmente solo admite certificados raíz de CA en su almacén de confianza; una raíz de CA podría ser "responsable" de miles o millones de certificados de servidor y, si, por ejemplo, Verisign emitió certificados para ambos bigbank.com, localdiner.comeso no significa que quiera ceder mis cuentas de Bigbank a localdiner. Por lo tanto, la aplicación debe realizar (2), ya sea en un verificar_callback o después de que se complete el protocolo de enlace pero antes de enviar datos (confidenciales). Se planea que la próxima versión principal 1.0.2 contenga mejoras en la validación de la cadena de certificados y creo que también en la validación de nombres en al menos algunos casos. Nota para HTTPS que usa RFC 2818 u otros protocolos basados en TLS que usan RFC 6125, debe verificar tanto CommonName en Asunto como la extensión SubjectAlternativeNames si está presente.

No sépor qué OpenSSL(y antes de eso SSLeay)no lo haceya. Se podría decir que algunas aplicaciones SSL/TLS inusuales quieren algo más que el estándar CN/SAN, pero hay otras áreas donde OpenSSL maneja el caso común y proporciona devoluciones de llamada u opciones para los casos raros. Creo que probablemente fue demasiado trabajo y poca gente (hasta hace muy poco).

Answer 1

En la mayoría de los protocolos/aplicaciones que utilizan SSL, el cliente debe verificar AMBOS (1) que el servidor presente un certificado válido, es decir, uno emitido por una CA confiable y que no esté vencido, revocado o manipulado Y (2) que ese certificado sea para el servidor que desea, no a otra persona a quien su conexión fue dirigida por error o por un ataque deliberado. (Hay casos raros en los que no necesita autenticación del servidor, solo confidencialidad, pero probablemente sea mejor utilizar los conjuntos de cifrado "anon" o "aNULL" que explícitamente no autentican).

OpenSSL hasta la fecha hace (1) pero no (2)y normalmente solo admite certificados raíz de CA en su almacén de confianza; una raíz de CA podría ser "responsable" de miles o millones de certificados de servidor y, si, por ejemplo, Verisign emitió certificados para ambos bigbank.com, localdiner.comeso no significa que quiera ceder mis cuentas de Bigbank a localdiner. Por lo tanto, la aplicación debe realizar (2), ya sea en un verificar_callback o después de que se complete el protocolo de enlace pero antes de enviar datos (confidenciales). Se planea que la próxima versión principal 1.0.2 contenga mejoras en la validación de la cadena de certificados y creo que también en la validación de nombres en al menos algunos casos. Nota para HTTPS que usa RFC 2818 u otros protocolos basados en TLS que usan RFC 6125, debe verificar tanto CommonName en Asunto como la extensión SubjectAlternativeNames si está presente.

No sépor qué OpenSSL(y antes de eso SSLeay)no lo haceya. Se podría decir que algunas aplicaciones SSL/TLS inusuales quieren algo más que el estándar CN/SAN, pero hay otras áreas donde OpenSSL maneja el caso común y proporciona devoluciones de llamada u opciones para los casos raros. Creo que probablemente fue demasiado trabajo y poca gente (hasta hace muy poco).

¿Se requiere la validación de la verificación CN/nombre de host con el certificado SSL en openssl y por qué?

Respuesta1

información relacionada