¿Se debe usar el elemento Keygen para crear un certificado para autenticación mutua TLS? ¿Qué alternativas hay?

Para realizar la autenticación de cliente basada en certificados con SSL, el cliente debe "poseer" un certificado, es decir, tener acceso a una clave privada y al correspondiente certificado (emitido por una CA que el servidor aceptará). Cuando el cliente es el navegador web, no hay forma de escapar de él: el navegador debe conocer la clave como tal.

Hay dos formas para que el navegador "sepa" una clave privada + un par de certificados:

1. Haga que la CA genere el par de claves, cree el certificado y empaque el conjunto como un archivo PKCS # 12 / PFX que luego se importa en el navegador.
2. Haga que el navegador genere el par de claves, envíe la clave pública a la CA, que genera el certificado; el certificado se importa en el navegador.

El segundo método a menudo se considera "mejor" de forma genérica. En particular, si el certificado debe usarse más adelante para firmar documentos, de manera legalmente vinculante, entonces los detalles del ciclo de vida de la clave son importantes para el valor legal; los detalles son complejos y dependen mucho de las leyes locales, pero, como resumen general, si la clave privada existe alguna vez, incluso de manera transitoria, en un sistema que no sea la computadora del usuario, entonces no funcionará. Sin embargo, en un escenario de autenticación , especialmente para una sesión SSL / TLS, esto podría no ser un problema.

El elemento <keygen> es la forma HTML5 de implementar el segundo modelo. En realidad, es bastante más antiguo que HTML5 y tiene sus raíces en Netscape Navigator. Consulte esta página y ese archivo para obtener detalles sobre cómo usarlo. Para Internet Explorer, tendrá que usar una forma específica de Microsoft, que se llamó Xenroll pero que ha sido desaprobada en favor de CertEnroll (consulte esta publicación de blog para una introducción). Microsoft ha demostrado ser renuente a implementar <keygen> , oficialmente porque no les gusta lo que hace .

De todos modos, si realiza una autenticación de certificado de nivel SSL, debe lidiar con el tipo de interfaz de usuario y la experiencia que admiten los navegadores, lo que no es del todo óptimo desde un punto de vista ergonómico. Las alternativas incluyen realizar alguna autenticación dentro de el túnel SSL, que, en un contexto web, significa algo que el usuario ingresa (contraseñas o equivalentes de click-o-matic) o trucos de Javascript. El problema con Javascript es que no tiene acceso al repositorio del sistema operativo del cliente para las claves privadas (y la interfaz para tarjetas inteligentes) a menos que algunos Se utilizan funciones no estándar .

La autenticación basada en certificados en SSL / TLS es no necesariamente " más seguro "que otros métodos de autenticación. Los certificados permiten separar identificación de autenticación . Es una buena característica, pero es inútil en sistemas donde la arquitectura general no requiere tal separación.

Creo que hay muchas desventajas en el uso del elemento keygen, ya que ya está enumerado en tu publicación. Si tiene un servicio web que debería ser fácilmente accesible y compatible con muchos clientes, es bastante difícil implementar la autenticación del lado del cliente con keygen, una solución bastante nueva y poco madura.

La mejor solución sería proporcionar tokens criptográficos a sus clientes, con certificados precargados, firmados por su CA. Por supuesto, esto agrega mucha complejidad, ya que tiene que administrar la generación y distribución de los certificados de clientes, lo que puede ser muy difícil si tiene muchos clientes y no hay infraestructura para una CA. La ventaja de esta solución sería un mecanismo de autenticación muy fuerte para sus clientes.

Si solo intenta evitar los ataques MITM, en la mayoría de los casos, usar SSL y un buen mecanismo de acceso de usuario / contraseña pueden ser suficientes.

Depende mucho de cuáles son los recursos que tiene, qué está tratando de proteger y contra quién y quiénes son los usuarios de su aplicación. Responder a estas preguntas sería el primer paso en el proceso de creación de sistemas seguros.

Actualizar:

En lo que respecta al modelo de amenaza que ha descrito, no creo que su modelo ofrezca protección contra CA comprometida. Aquí hay un ejemplo:

• Una CA está comprometida y se emite un certificado para su dominio
• El DNS del cliente está comprometido para que responda con la IP del atacante, cuando se le solicite su dominio
• El cliente intenta conectarse, establece una conexión con el servidor rogue, que a su vez se conecta a su servidor
• El servidor rogue actúa como un cliente que se conecta desde un nuevo dispositivo y se genera un nuevo certificado de cliente.
• Incluso si el cliente real envía su certificado existente, el servidor deshonesto lo ignoraría.

El ataque descrito anteriormente asume que un cliente puede tener varios certificados (uno para cada dispositivo desde el que se está conectando). Si no desea implementar este comportamiento, sería bastante difícil para un cliente regular copiar el certificado en cada dispositivo que esté usando y, por supuesto, una mala experiencia de usuario.

En definitiva, la protección contra las AC comprometidas es un negocio difícil, y creo que mientras las nuevas tecnologías como DNSEC no se implementen a gran escala, no hay mucho que se pueda hacer.

Por otro lado, el pirateo de una CA conocida no es algo que ocurra todos los días. Solo asegúrate de no comprar un certificado de una CA que no sea de nombre y debes estar lo suficientemente seguro por el momento.