Cuando se trata de la autenticación en la web estamos casi todos familiarizados con la contraseña-rey de la colina, infame tanto por sus defectos, así como su ubicuidad. Fuera de la contraseña, a menudo se ejecutan en esquemas de autenticación como el uso compartido de tokens (por ejemplo, tokens de OAuth o RSA). Otro método que verá con poca frecuencia es la forma de certificado de cliente humilde de autenticación. Los certificados de cliente están relacionados con los certificado de servidor mucho más populares y existen en el mismo protocolo de enlace TLS. En otras palabras, la misma conexión inicial de su navegador web que pregunta al servidor si tiene un certificado SSL, también involucra al servidor preguntando al navegador si tiene un certificado SSL. La adopción de la primera ha sido significativa en la última década debido a su uso en HTTPS. Los certificados de cliente solo son útiles para la autenticación, por lo que, por comparación, su adopción ha sido más limitada que los certificados de servidor. A pesar de su falta de popularidad y algunos aspectos complicados, el CERT del cliente es compatible con los navegadores de escritorio modernos y servidores Web. Para algunos casos de uso, tiene sentido renunciar a la conveniencia absoluta de la contraseña para la seguridad absoluta de los certificados SSL.
Poner todo junto
Hay algunos defectos desagradables que tenemos que cubrir, pero no quiero desalentarlos por ser demasiado técnico temprano. En su lugar, vamos a trabajar hacia atrás y echar un vistazo a cómo todo esto debe reunirse.
en la imagen de arriba se puede ver que el administrador de certificados de Firefox tiene la capacidad de almacenar Certificados personales. Al utilizar la autenticación de certificado de cliente, el explorador del usuario tendría un certificado de una entidad emisora de certificados de confianza. En la foto, se puede ver que tengo dos, uno de comodo para mi correo electrónico, y un certificado de autofirma para auth. Vamos a entrar en el bit autofirmado más adelante, pero esto no representa el mismo riesgo que los certificados de servidor autofirmados. Suponiendo que tiene un certificado de cliente en su navegador (todavía no, pero no se preocupe volveremos a eso), su navegador lo enviará automaticly al servidor al realizar el mismo protocolo de enlace TLS utilizado para negociar HTTPS. Esto es suponiendo que el servidor realmente pide un certificado de cliente.La configuración anterior de nginx es un fragmento de la configuración de este sitio Web. Las líneas 2-11 y 17 son prácticamente las configuraciones básicas de HTTPS. Incluyo ésos para la integridad puesto que negoating el HTTPS es un requisito previo para que la autenticación del certificado del cliente trabaje; pero, honestamente espero que ya estés haciendo eso. Las líneas 13, 14 y 15 son la carne real y las patatas de la configuración del servidor;
ssl_verify_client – Esto se establece en opcional, lo que significa que pedimos al explorador para un certificado de cliente si tiene uno, y validarlo si se suministra, pero nginx no fallará el protocolo de enlace TLS si el explorador no proporciona uno.
ssl_client_certificate – Esta configuración indica a nginx qué autoridades certifican confiar. Al igual que los navegadores web mantienen una lista de CAs de confianza, esto permite que su servidor tenga una lista similar. Nginx enumerará estas entidades de certificación por nombre durante el protocolo de enlace.
ssl_verify_depth – por último, esta configuración permite a nginx saber cuántos certificados intermedios para permitir. Los certificados de cliente raramente son firmados directamente por el certificado raíz del certificado Authorit; por lo tanto, estableciendo esto en 2 acomoda 1 firmante intermedio además del certificado raíz, que es bastante típico.
Los tres elementos de configuración anteriores son todo lo que se requiere para habilitar los certificados de cliente en nginx. Hay dos que quedan considerando; ¿Cómo generamos estos certificados y cómo imponemos una forma significativa de autenticación? Hablemos de esto primero.
Autenticación de usuario
Una cosa es pedirle al navegador que proporcione un certificado, es algo más que autentificar a un usuario. En la sección anterior, establecemos ssl_verify_client en opcional. La razón de esto es que la mayoría de los sitios web tienen una mezcla de contenido público y privado. No querrá impedir que los usuarios accedan al contenido público, simplemente porque carecen del certificado necesario para las porciones privadas. Incluso las aplicaciones totalmente privadas desearán exponer algún tipo de página personalizada para aquellos que no están autenticados actualmente-por ejemplo, una página de inicio de sesión o registro. Por todas estas razones, la recomendación es dejar ssl_verify_client a opcional y controlar cualquier lógica adicional en la aplicación o en las reglas de ubicación de nginx. Nginx proporciona dos variables que son útiles para la aserción de Authentication-ssl_client_verify y ssl_client_raw_cert. La variable ssl_client_verify, en su forma más básica, es igual a SUCCESS cuando se ha presentado un certificado de cliente y coincide con la lista de entidades emisoras de certificados de confianza del servidor (como se establece con ssl_client_certificate). Puede hacer referencia a la documentación de nginx para otros valores que contiene, pero para la mayoría de los casos de uso es suficiente simplemente probar la igualdad o desigualdad a SUCCESS. Por ejemplo; El extracto anterior se toma de la configuración de nginx de este sitio Web. En este ejemplo, puede ver que ssl_client_verify se compara con SUCCESS para cualquier persona que intente acceder a la página de inicio de sesión de WordPress de este sitio. El suministro de un certificado de cliente válido pasará la solicitud a WordPress para la autenticación basada en contraseña regular-por lo que no hay desviación de la configuración estándar allí. Sin embargo, para esos navegadores sin un certificado de cliente válido, su conexión se terminará inmediatamente con un 404-error de acceso denegado.
en este caso de uso, la autenticación de certificado de cliente solo proporciona una capa adicional de seguridad. Una gran necesidad de uno, teniendo en cuenta el número rampante de intentos de hacking automatizado realizado contra sitios de WordPress. Esta medida de seguridad también asume que la validación simple del certificado es suficiente para filtrar el Riff-Raff. Esto funciona porque nginx está configurado para confiar sólo en una lista de entidades de certificación (consulte la ssl_client_certificate discusión anterior)-en mi caso mi propia CA. Para un control más detallado, la variable ssl_client_raw_cert permite la inspección del propio certificado de cliente. Esta variable está codificada en PEM y, por lo tanto, requiere un procesamiento adicional para que sea útil. Por este motivo, es mejor pasar esta variable en el servidor ascendente para la inspección a nivel de aplicación. En otras palabras, vamos a rellenar esta variable en un encabezado HTTP y permitir Ruby, node. js, .NET, Java, etc. para procesar el certificado con formato PEM en el nivel de aplicación y permitir o rechazar la solicitud.
El fragmento de código anterior ilustra cómo esta variable puede reenviar al servidor ascendente. Por Convención el encabezado HTTP que comienza con “X” es costumbre, y allí una sola vez libre elegir el nombre que deseamos, apenas mientras nginx y la aplicación ascendente convengan en la Convención de nombramiento.
Arriba es un ejemplo de lo que el contenido de ese encabezado se verá como-un certificado codificado PEM. Es totalmente hasta la aplicación cliente sobre cómo manejar las cosas desde este punto en adelante. Para la comparación, sin embargo, esto no es conceptualmente muy diferente de manejar la autenticación basada en contraseña. El nivel de aplicación debe tener lógica para validar el nombre de usuario y la contraseña proporcionados y para responder en consecuencia. Del mismo modo, una aplicación que hace uso de la autenticación de certificado de cliente debe tener lógica para procesar el certificado codificado PEM, extraer los campos que considere relevantes (probablemente el nombre común) y responder en consecuencia. La aplicación no necesita validar el certificado, ya que la validación era el identificador controlado por Nginx antes de reenviar la solicitud.
Los detalles feos
Claves y certificados-decir esas palabras a la mayoría de los desarrolladores y que se Cringe. Con razón, hay poco en el camino de los usuarios sin amigos-verdaderamente un producto de la función sobre la forma. Los aman, o los odian, son una necesidad en nuestro mundo moderno. Habiendo resistido las presiones de décadas de Criptoanálisis, son la prioridad número uno es asegurar la asistencia digital, no necesariamente haciendo la vida del desarrollador más fácil. Es por estas razones que decidí cubrir este tema por última vez.
Si realmente desea omitir esta sección, siempre es Bienvenido a comprar un certificado comercial. Venders como comodo venden billetes de autenticación de cliente para el precio de una cena para dos-aunque esto es una cuota anual. Aparte del costo, las desventajas de un certificado comercial son que la simple validación con ssl_client_verify, como vimos anteriormente, no es tan práctico. En ese ejemplo, mostré cómo este mismo blog utiliza la validez del certificado solo como un Gatekeeper. Esto funciona para mi blog porque está validando contra mi propia autoridad de certificación. Ya que no genero certificados para todos, sé que si alguien tiene un certificado auténtico que muy probable que me. A diferencia de los certificados de servidor, hay poco desventajas para los certificados de cliente autofirmados. Los peligros en torno a los certificados de servidor autofirmados provienen del aspecto de confianza del cliente. Confiar en cualquier certificado se reduce a confiar en una o varias autoridades de certificación para emitir certificados de forma segura y correcta. Los navegadores confían en las entidades emisoras de certificados basándose en una lista bien vetada de CAs empaquetadas en cada navegador. Cuando se enfrenta a un certificado de aspecto válido de otro modo, los navegadores rechazarán la conexión si no de una CA de confianza. Los usuarios pueden invalidar este comportamiento, pero este comportamiento se desaconseja debido a los peligros de un usuario que confía inadvertidamente en el certificado incorrecto. La probabilidad de un ataque de hombre en el medio es demasiado alta, y la mayoría de los sitios web no utilizan certificados autofirmados. En esto yace los peligros. Cuando se distribuyen correctamente, los certificados autofirmados pueden ser tan seguros como los certificados comerciales-pero eso es un BIG si para los certs del servidor. Para los certificados del cliente los riesgos son virtualmente elimenated. A los navegadores no les importa quién emite sus certificados de cliente, ya que conservan la clave pública y privada. El servidor, presumiblemente operado por la misma persona u organización que es auto-firma de certificados puede inherentemente confiar en sí mismos-espero. Basta de estancamiento de mi parte, echemos un vistazo a cómo generamos estos certificados. El primer paso es que debemos convertirnos en una autoridad certificadora. El uso de OpenSSL es relativamente fácil. Primero, marque la configuración del dir en la sección [ca_default] de la configuración de OpenSSL-usted encontrará típicamente esto en el/etc/SSL. La configuración dir debe apuntar a CA, haciendo la ruta de acceso completa/etc/SSL/CA-que es la ruta de acceso que estos ejemplos usarán. Si la ruta de acceso no coincide, actualice la configuración de OpenSSL o las siguientes secuencias de comandos para que coincidan entre sí. Con esto verificado, es hora de crear nuestra autoridad certificadora.
El guión de arriba se encarga de todo el levantamiento pesado. Se le pedirá una contraseña para el certificado de la CA-por favor recuerde esto, no es algo que usted querrá olvidar. Con esta configuración de una vez completa, ahora estamos listos para crear uno o varios certificados de cliente. Esto también se puede automatizar en un simple script.
El nombre de usuario del cliente debe suministrarse como primer argumento al llamar a este script. Dado que somos nuestra propia CA, este nombre de usuario puede ser cualquier cosa que queramos-incluso una dirección de correo electrónico. El único requisito es que es único dentro de nuestra propia CA. Cuando se complete el script Create-User, tendrá una contraseña para proteger PKCS #12 certificado de cliente formateado listo para importar en su navegador. Lo has hecho-adelante e impórtelo. Las rutas de ubicación de nginx protegidas en secciones anteriores ahora deberían ser accesibles.
En envolver
Autenticación de certificado de cliente, aunque no es práctico para todos los escenarios, es una herramienta valiosa para tener a su disposición. Con soporte construido a la derecha en los navegadores de escritorio modernos y nginx, la configuración se puede completar en pocos minutos, pero aún así proporcionar protección muy superior a las contraseñas regulares. Con mucho, las desventajas más grandes de esta técnica es su falta de soporte en los navegadores móviles y las molestias asociadas con la distribución inicial del certificado de cliente. No esperes que esto Reemplace las contraseñas, pero es una opción ideal para la seguridad añadida en las páginas de administración privadas para pequeñas empresas o sitios web personales.
