Suplantando la autenticación del certificado de cliente con el mismo nombre de sujeto

Question

Suplantando la autenticación del certificado de cliente con el mismo nombre de sujeto

#1 de Crypt32 (4 votos)

1

Estoy investigando la seguridad de un servicio que utiliza certificados de clientes para autenticar solo a personas que llaman conocidas. Ejecutamos un servicio de API web de C # que verifica cada asunto del certificado de solicitud si está en la lista blanca. También verifica que el certificado sea válido (validación de la cadena de certificados).

Pero si un atacante obtiene un certificado con el mismo nombre de sujeto que emite alguna autoridad de certificación, puede atacar nuestro servicio, ¿verdad? Esto me parece menos seguro. Los certificados SSL del servidor son seguros porque los usuarios están llegando a un dominio explícitamente y el certificado SSL que utiliza el servidor contiene el nombre de dominio validado por una autoridad de certificación. A menos que se comprometa el certificado del servidor y algunas formas en que el dominio al que el usuario intenta acceder está comprometido, el servidor es seguro y el cliente puede confiar en el servidor.

Pero confiar en un cliente me parece menos seguro. ¿Mi entendimiento es correcto o me estoy perdiendo algo?

tls certificates http x.509 client

pregunta rboorgapally 08.02.2018 - 20:27

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates http x.509 client

¿Es compatible un certificado TLS 1.2 con versiones anteriores? [duplicar] Requisitos de ISP de conformidad con PCI

score 4 · Accepted Answer

Buena pregunta. Con C # y .NET es difícil limitar un número de CA raíz de confianza a través de la clase X509Chain que utilizará para validar cadenas. Esta clase no ofrece dicha funcionalidad (aunque, la función nativa subyacente CertCreateCertificateChainEngine lo permite a través de CERT_CHAIN_ENGINE_CONFIG.hRestrictedRoot , aunque es una larga historia).

En Active Directory, por ejemplo, esta pregunta se resuelve introduciendo un registro NTAuthCertificates en CN=Public Key Services, CN=Services, CN=Configuration, {ConfigurationNamingContext} que almacena certificados de CA (emisores directos) que pueden emitir certificados de autenticación de clientes y inicio de sesión de tarjeta inteligente. El controlador de dominio durante el inicio de sesión de la tarjeta inteligente realiza la construcción y validación de la ruta general, luego obtiene el emisor (de la cadena validada) y comprueba si está listado en NTAuthCertificates . Si todo está bien, entonces el inicio de sesión del certificado continúa, de lo contrario, falla.

Sugeriría ir por el mismo camino. Mantenga una colección de CA (de nuevo, emisores directos, no raíces) que estén aprobados por su política para emitir certificados de autenticación. Puedes almacenar certificados completos, sus huellas digitales, claves públicas o lo que sea que te ayude a identificarlos fuertemente.