Doble factor de autentificación con SSL client-side en Nginx
La autentificación es básica para garantizar la confianza de tus usuarios mediante tu APP o servicios. Para cumplir con este objetivo existen diversos métodos de autentificación que puedes implementar en tus desarrollos APP, que deberás seleccionar y adaptar en relación con la sensibilidad de los datos.
Artículos recomendados antes de seguir la lectura:
- WebAuthn, ¿El estándar que terminará con las contraseñas?
- ¿Qué métodos de autentificación implementar en mí APP?
- ¿Cuál es el mejor método de autentificación en un API REST?
¿Está mi aplicación segura únicamente con un método de autentificación?
Hace unas semanas comentamos los métodos de autentificación que puedes implementar en tu APP o servicios, con soluciones como usuario y contraseña, PIN, Touch ID, Face ID o WebAuthn. Existen muchas soluciones que puedes implementar, aunque tenemos algunos métodos más.
Hoy te presento SSL del lado del cliente (client-side), el cual te permitirá gestionar, al igual que WebAuthn, que dispositivos tienen acceso al servidor web. Todo aquel que no tenga el certificado instalado, el servidor podría devolver un Error HTTP 403, denegando el acceso a todo aquel que no disponga del certificado SSL.
¿Qué es un certificado del lado del cliente (SSL client-side)?
Un certificado del lado del cliente es un mecanismo de autenticación de la capa de transporte que puedes utilizar para verificar un usuario antes de la capa de aplicación.
Es importante comprender que el SSL del lado del cliente solo se encargara de validar la conexión del dispositivo para acceder a la aplicación; Una vez accedido a la aplicación, podrás añadir otros métodos de autentificación de tu aplicación como usuario y contraseña. Además, de poder seguir utilizando HTTPS con un CA (Certificate Authority) público para poder establecer cualquier conexión de forma doblemente segura.
Crear la CA (Certificate Authority)
Primero, debes crear una clave para crear tu Autoridad de certificación (CA); Esta clave la necesitarás para crear el certificado del lado del servidor (SSL client-side) y con la que firmarás todas las solicitudes de certificado del cliente. Es decir, es la "contraseña" maestra para todo el sistema. Manténla a salvo.
Te solicitara cifrar la clave con una contraseña. Asegúrate de anotarlo, ya que la necesitarás cada vez que crees un nuevo certificado o firmes una solicitud de certificado de cliente.
Crear un certificado basado en la CA
A continuación deberás crear un certificado de CA; Este es el certificado del lado del servidor que se enviará a través del servidor TLS al cliente. Ten en cuenta que este certificado es específico para certificados del lado del cliente (client-side) y no substituye el certificado HTTPS de tu conexión.
Tendrás que responder varias preguntas; Ten en cuenta:
- La información introducida para País, Estado, Localidad y Organización; deberá coincidir en el futuro cuando se renueve el certificado.
- No introduzcas ningún nombre común (CN) para el certificado.
- Puedes omitir el correo electrónico.
La renovación del certificado solo requiere ejecutar el mismo comando; para generar un nuevo certificado. Si necesitas revisar la información introducida en el certificado anterior, puedes ejecutar:
Este comando te mostrará toda la información sobre el certificado, incluidos los valores que hemos comentado anteriormente.
Crear un certificado para el cliente (usuarios)
A continuación, deberás crear un certificado de cliente; pero recuerda que es efectivamente un certificado “key” con el que poder llegar a la aplicación que deseas proteger, y si deseas "cambiarla", deberás revocar el certificado. Entonces, piensa en cómo te gustaría gestionar la autenticación: ¿por usuario o por dispositivo? El proceso de creación es indiferente, pero ten en cuenta tu modelo de gestión de claves para evitar problemas en el futuro.
Crear una key y una solicitud de firma de certificado (CSR Certificate Signing Request)
Crea una clave RSA:
Luego, crea una Solicitud de firma de certificado (CSR)
Tendrás que responder varias preguntas; responde a cada una, incluido el nombre común (CN) y la dirección de correo electrónico.
Firmando un CSR
El CSR ahora debe ser firmado por la CA; Esta es la CA que dice "Conozco a esta persona o dispositivo: son quienes dicen ser".
Por lo general, deberías incrementar el número de serie con cada firma. Una vez que el certificado caduca, no es necesario volver a crear una nueva CSR; se puede firmar el mismo, lo que creará un nuevo certificado vinculado a esa clave pública.
¡Todo preparado! Podrás enviar certificado firmado al usuario junto con el certificado de CA (¡no la clave privada!), para la instalación en los dispositivos que creas convenientes, en el siguiente punto revisaremos como unificar estos certificados para facilitar la instalación.
Crear un PKCS12 (PFX)
Ahora, el certificado firmado debe instalarse en un dispositivo de forma que agrupe las claves y el certificado del cliente. El archivo resultante es efectivamente una contraseña, por lo que debes mantenerlo tan seguro como las otras claves privadas.
Para crear el pfx:
Deberás añadir una "contraseña de exportación", y es muy recomendable que se configure una para asegurar que si lo recibe un tercero no tenga la capacidad de añadirlo a su dispositivo.
¡Todo listo! Ahora ya puedes importar el archivo PFX a tu navegador web. Ahora es necesario configurar el servidor web Nginx para la autenticación de certificados para proteger tu APP o servicio.
Configuración de Nginx
Ejemplo de configuración Nginx con SSL client-side:
Ahora, al acceder al servidor Nginx, el navegador te solicitará el certificado de cliente; selecciona el certificado instalado. Si todo es correcto accederás a tu Web APP sin problema. Ahora podrás hacer la misma prueba desde otro dispositivo sin la instalación del certificado y podrás comprobar que el servidor devolverá un error 403 sin ningún tipo de aviso ni información acerca de tu APP.
¿Alterar la lógica de negocio de mi aplicación PHP en función del certificado SSL?
Como habrás visto en la configuración del Nginx, en el caso que el dispositivo que conecta al servidor web no disponga del certificado SSL le devuelve un error 403. Esto lo logramos mediante la verificación de “ssl_client_verify”.
Imagina que dentro de este “if” añadimos variables de entorno de Nginx. Estas variables de entorno las podrás utilizar por ejemplo con tu APP o servicio si está desarrollado en PHP, haciendo que sea una variable PHP que puedes consultar en tu APP. Con lo que podrás gestionar tu propia lógica de negocio con el certificado SSL del lado del cliente.
Un colega, Carles Grau, nos mostró como utilizando esta característica mediante SSL client-side y PHP lograba ofuscar cierta información de su APP para los dispositivos que no disponían del certificado. Garantizando las funcionalidades, pero en este caso ofuscando cierta información si el dispositivo no disponía del certificado SSL.
Conclusión
La elección del método de autentificación debe realizarse de acuerdo a la sensibilidad de la información. Es por ello que existen varios métodos de autentificación de acceso a APPs. Con SSL del lado del cliente podrás garantizar que los dispositivos con acceso a tus APPs o servicios están controlados y que ningún otro sin el certificado SSL podrá acceder a la APP.
Recuerda, el SSL (client-side) es solo una clave con la que poder llegar a la aplicación. Te recomiendo combinar esta configuración junto a conexiones seguras con HTTPS y un método de autentificación seguro en tu aplicación o servicio.
¿Cómo proteges o encriptas las APPs críticas de tu organización? ¿Qué sistema de autenticación aplican tus servicios? ¿Conoces WebAuthn?
Photo by Silas Köhler on Unsplash
Referencias: