Explicación sencilla de los certificados de cliente SSL para un desarrollador

Editar: Me doy cuenta de que esto no queda claro en la respuesta a continuación ... pero desde el punto de vista de su aplicación, realmente no hace ninguna diferencia si ejecuta la PKI / CA usted mismo o si utiliza una o más CA de terceros. Incluso si elige ejecutar su propia PKI, realmente no quiere codificarla usted mismo, por lo que usaría uno de los existentes, que estaría lógicamente separado de la aplicación, y cualquier otro La interacción con la CA sería a través de los protocolos habituales. Fin de edición

  

¿Debería realmente operar una PKI y emitir los certificados yo mismo?

Como regla general, a menos que ya sepa cómo ejecutar una PKI, no debería hacerlo. Es un lote más complicado de lo que piensas, y muchas más formas en que las cosas pueden salir mal. Incluso las compañías que hacen PKI como su negocio principal a veces se equivocan; vea Diginotar a quien se le hizo una piratería de su infraestructura de certificado y finalmente se declaró en quiebra .

Permitir certificados de terceros, especialmente por múltiples CA, tiene sus propios inconvenientes. Tengo una tarjeta inteligente que contiene mi identificación electrónica que utilizo para acceder a mi banco y a varios sitios gubernamentales. Pero también podría tener un certificado "blando" que uso para acceder a otras cosas. Si su sitio aceptara ambas autoridades de certificación, ¿tendría alguna forma de saber que esos dos certificados se refieren a la misma persona (o usuario)? ¿Desea tener un usuario por certificado o desea que un usuario pueda usar más de un certificado? ¿Qué sucede cuando caduca un certificado? ¿Cómo sabría que mi nuevo certificado todavía se refiere a mí? Estas preguntas deben considerarse cuidadosamente al diseñar sus aplicaciones y cadenas de confianza.

  

¿Hay una manera de hacer que se comporten como las claves SSH, el usuario   presenta cualquier clave durante el registro y esa clave está vinculada a la cuenta?

Esto es solo una pequeña cuestión de programación ... (En otras palabras, no es tan pequeño, pero no imposible.) Es probable que también desee que el usuario agregue o elimine certificados de alguna manera.

  

Sobre la verificación de ellos en mi aplicación, la mayoría de la documentación que he encontrado hace   el servidor web verifica los certificados contra una CA (mi propia CA en este caso,   lo que nos lleva de nuevo al problema PKI) y establecer un entorno   variable si se confía en el certificado ... eso no funcionaría en mi caso como   Me gustaría deshacerme de la CA y que los clientes proporcionen su propia   certeza, basado en el hecho de que no puedo confiar en compararlos con   Un CA, ¿contra qué puedo verificarlos? ¿Los certificados de clientes tienen la   equivalente a la clave pública SSH que puedo almacenar en mi base de datos y verificar   en contra de eso?

No guardaría el certificado completo, solo guardaría suficiente información para poder verificar el certificado la próxima vez que el usuario lo presente. Este suele ser el número de serie del certificado, el CN y la CA emisora. También es posible que desee almacenar la fecha de caducidad, para que pueda recordar a los usuarios que renueven sus certificados antes de que caduquen. (Por supuesto, esto podría hacerse cuando verifique sus certificados al momento de iniciar sesión, pero sería conveniente almacenar los datos para que pueda enviar un recordatorio por correo electrónico en caso de que no se registren durante el tiempo en que recibirán la advertencia). / p>

Incluso cuando un certificado es emitido por una CA de terceros, el certificado contendrá información sobre cómo puede verificar su validez. Por lo general, esto se realizará mediante OCSP (Protocolo de estado de certificado en línea), que es una verificación en tiempo real contra la base de datos de la CA emisora. También hay CRL, una lista de revocación de certificados, que contiene información sobre qué certificados revoca la CA. Esto no es en tiempo real; la CRL se volverá a emitir a intervalos.

  

Finalmente, ¿cómo haría un nuevo cliente para registrarse en mi sitio web;   Se le pide que presente un certificado y no tiene ninguno, ¿cómo lo hace?   generar uno?

Si elige utilizar CA de terceros, debe darles un enlace a una o más de las CA en las que confía.

Si ejecuta su propia CA, les daría un enlace a esa CA, que debería configurarse para permitir que los usuarios anónimos (anteriormente), así como los usuarios existentes, soliciten un nuevo certificado.

Finalmente, si desea echar un vistazo a la configuración de una PKI, puede probar EJBCA, una CA / VA de código abierto . Le dará una idea básica de las complejidades involucradas.

Trabajo para una empresa de pruebas de penetración que requiere un certificado de cliente para iniciar sesión en cualquiera de nuestros hosts de prueba. Los certificados requieren que ingrese una contraseña cuando se autentique. Esto se hace como una capa agregada de seguridad, no para reemplazar la necesidad de contraseñas. Si el certificado no requiere una frase de contraseña, entonces sí, permitir que alguien obtenga la clave es tan malo como darles sus credenciales.

Tanto el objetivo como el enfoque son bastante cuestionables.

Los usuarios no tienen HSM en su PC (a menos que todos trabajen en una empresa muy especial que de alguna manera les proporciona a sus empleados hardware de cifrado). En el mejor de los casos, se encontrará con un usuario con una tarjeta inteligente, pero incluso entonces probablemente no usarán la tarjeta para su sitio, porque es demasiado engorroso. Una suposición más realista es que los usuarios simplemente mantienen las claves privadas en su disco duro, ya sea con una frase de contraseña débil o sin frase de contraseña en absoluto. Entonces, si la PC se ve comprometida, la clave se ve comprometida. Eso no significa que la autenticación de clave pública sea inútil, pero sus supuestos parecen ser demasiado optimistas.

Los certificados de cliente tampoco eliminan la necesidad de un mecanismo de inicio de sesión. El navegador le pedirá al usuario que elija un certificado e ingrese la frase de contraseña, que no es realmente diferente de un formulario de inicio de sesión estándar (solo que es más feo). Al mismo tiempo, sus usuarios ahora tienen que preocuparse por hacer una copia de seguridad de su clave y su certificado, posiblemente tengan que encontrar una manera de llevarlos a una máquina diferente de manera segura, y necesitan obtener un nuevo certificado si la clave está perdida o comprometida. . Así que en realidad es más trabajo.

También estoy en desacuerdo con su enfoque. La criptografía de clave pública de HTTPS se basa en un modelo de confianza muy específico, a saber, una infraestructura X.509 con CAs de alta resolución. Quizás prefiera un modelo diferente, pero así es como funciona el protocolo, y así es como lo implementan todos los servidores y clientes relevantes. Tratar de "piratear" la validación del certificado probablemente terminará en un desastre (como muestran algunas de las respuestas anteriores). Entonces, no, no hay una salida fácil.

Si espera que los certificados de los clientes sean a la vez súper seguros y súper prácticos, se sentirá decepcionado. Ellos no están. Si bien pueden ser más seguros que las contraseñas, esto tiene un precio: más trabajo para usted, más trabajo para sus usuarios y mucha más complejidad para su aplicación.

Un certificado autofirmado funcionará efectivamente como una clave pública SSH. Tendrá que agregar cada certificado de usuario a su lista de CA confiables. Si un usuario aún no tiene un certificado, puede crearlo utilizando el script java en el navegador durante el registro. Puede solicitar al usuario que almacene sus certificados de clave privada encriptados con contraseñas seguras, por lo que no es exactamente lo mismo que tener una contraseña de texto simple.txt. Los certificados privados se cifrarán y almacenarán y solo se podrán desbloquear con la contraseña. Cuando el sitio web / aplicación web desee autenticarse, usted buscará (o hará que el usuario seleccione el certificado privado apropiado, que es un problema de usabilidad) el certificado correspondiente y se le solicitará al usuario que ingrese su contraseña para el certificado privado que se usará .

¿Es realmente una buena idea?

Sí, podría funcionar, pero ... En caso de un simple MITM , ¿qué ocurrirá?

1. Su servidor no reconocerá el certificado de cliente del pirata informático y volverá a la página de inicio de sesión.
2. El usuario naturalmente volverá a ingresar su credencial y, por lo tanto, podría funcionar normalmente otra vez.
3. Pero a partir de ahí, su servidor aceptará el certificado de pirata informático, siempre que el cliente no intente conectarse nuevamente desde otro lugar.
4. Su seguridad está comprometida.

Por supuesto, el segundo paso no es una evidencia real, pero como ingeniería social sigue siendo la primera forma de fallas de seguridad, ¡no puedes esperar que tus usuarios tengan que preocuparse!

StartSSL proporciona certificados gratuitos de servidor web de Clase 1 (SSL / TLS) & Certificados de cliente y correo (S / MIME). Los uso para mi sitio web y correo electrónico. La verificación se realiza automáticamente y sus clientes a menudo obtendrían los certificados casi al instante.

Esto es mejor que operar una PKI y emitir los certificados usted mismo. Puede comparar el certificado del cliente con el certificado raíz de la CA de StartSSL y validar al usuario en la aplicación (así es como funciona el inicio de sesión de la PKI de StartSSL y cómo funciona sin problemas).

Tener una PKI de terceros también se ocupa de los nuevos clientes que no tienen ningún certificado al redirigirlos automáticamente a través de una autoridad de administración de claves y generación de certificados comprobada como StartSSL.

P.S. No estoy afiliado de ninguna manera con StartCOM o StartSSL. Yo mismo uso sus servicios gratuitos, así que los estoy recomendando en este caso.