En las últimas versiones, la seguridad de 4D se ha extendido significativamente, en particular en el área de los certificados. Esto incluye certificados autogenerados para la comunicación cliente-servidor, soporte para certificados ECDSA y, con 4D 20 R7, la validación de la autoridad del certificado para la comunicación cliente-servidor de aplicaciones autónomas. Algunos clientes exigen el máximo nivel de seguridad, lo que resalta la importancia de estas funcionalidades.
Sin embargo, la seguridad puede ser compleja, y es por esto que útil explicar cómo funciona una conexión TLS/SSL y el rol de los certificados. Por eso, antes de profundizar en las nuevas funciones, conviene desglosar los conceptos básicos de seguridad y sus interacciones.
Cifrado, autenticación y certificados
En el núcleo de la seguridad hay dos conceptos clave: cifrado y autenticación. El cifrado protege los datos codificándolos, lo que impide el acceso no autorizado entre un servidor y un cliente, mientras que la autenticación garantiza que tanto el cliente como el servidor sean quienes dicen ser. Los certificados cubren estos dos conceptos, ya que se componen de 2 elementos (y, como tales, 2 archivos): una clave que se mantiene privada y se utilizará para cifrar la comunicación y un certificado público que se utiliza para la autenticación.
cifrado simétrico
La forma más sencilla de cifrado es el cifrado simétrico, en el que el cliente y el servidor comparten la misma clave para cifrar su comunicación. El cifrado simétrico es ventajoso porque garantiza tanto el cifrado como la autenticación: el servidor es válido porque utiliza la clave correcta, y el cliente es válido por la misma razón. El principal inconveniente del cifrado simétrico es la necesidad de copiar la clave tanto en el servidor como en el cliente, lo que requiere un canal de comunicación separado y seguro.
Cifrado asimétrico
El cifrado asimétrico está muy extendido en Internet y se basa en un concepto sencillo: tanto el cliente como el servidor tienen llaves públicas y privadas. La llave pública cifra la comunicación, mientras que la privada la descifra. El servidor y el cliente pueden distribuir libremente sus llaves públicas sin preocuparse de posibles interceptaciones, ya que la llave pública sólo permite el cifrado. Sin la llave privada, el descifrado de la comunicación no es posible.
En 4D, el cifrado asimétrico se utiliza para el servidor HTTP, el cliente HTTP y la comunicación entre 4D Server y 4D Remote. Para el servidor HTTP, el certificado y su correspondiente llave deben colocarse en la carpeta del proyecto. Para la comunicación entre 4D Server y 4D Remote, el certificado y la llave pueden almacenarse en la carpeta Resource de 4D Server, o bien 4D Server puede generar su certificado automáticamente. El cliente HTTP y el 4D Remote generan sus certificados automáticamente.
A diferencia de la encriptación simétrica, la encriptación asimétrica asegura la encriptación pero no la autenticación. Esto significa que no puede garantizar que el servidor con el que se está comunicando sea el servidor previsto. Esta vulnerabilidad puede dar lugar a ataques de suplantación del servidor y de intermediario (en los que un atacante intercepta la comunicación entre el cliente y el servidor).
Prevención de suplantaciones de servidores y MITM: validación de autoridades de certificación
Para evitar los ataques «man-in-the-middle», el cliente y el servidor necesitan una forma de autenticarse mutuamente. Para el cliente, generalmente se utiliza un diálogo clásico de inicio de sesión/contraseña, ya que más que una máquina lo que se quiere es autenticar a un usuario.
Uno de los métodos más comunes para autenticar servidores es utilizar un certificado emitido por una autoridad de certificación de confianza. Las autoridades de certificación son entidades reconocidas a nivel mundial cuyas firmas se integran en las aplicaciones como los navegadores web. Cuando un servidor presenta un certificado emitido por una autoridad de certificación, el cliente puede verificar su autenticidad comparando la firma de la autoridad de certificación almacenada con la del certificado.
Introducción a la validación de autoridades de certificación en 4D 20 R7
Ahora, exploremos la nueva funcionalidad en 4D 20 R7: validación de autoridad de certificación para aplicaciones autónomas. Esta actualización permite a los clientes 4D verificar el certificado que reciben del servidor 4D, asegurando la identidad del servidor y proporcionando protección contra ataques «man-in-the-middle» (MITM).
Para implementar esto, es necesario añadir dos valores al archivo buildApp.4DSettings cuando se crea la aplicación cliente: la ubicación de un archivo que contiene firmas de autoridades de certificación de confianza que se copiará en la aplicación cliente y el nombre de dominio del certificado del servidor. Con esta información, la aplicación cliente puede comprobar que el certificado enviado por el servidor ha sido emitido por una autoridad de certificación válida y que el nombre de dominio coincide con el esperado. Si hay alguna discrepancia, se rechazará la conexión.
En los casos en los que intervienen varios clientes, crear una aplicación distinta para cada uno de ellos puede resultar complicado. Para solucionarlo, se puede proporcionar una lista de nombres de dominio válidos. Aunque este enfoque es menos seguro que especificar un único nombre de dominio, sigue requiriendo que cualquier posible intermediario posea un certificado de uno de los clientes, lo que no es fácil de conseguir. Alternativamente, el campo de nombre de dominio puede dejarse en blanco, en cuyo caso 4D sólo comprobará que el certificado procede de una autoridad de certificación válida.
Para las aplicaciones que se comunican a través de Internet u otras redes no fiables, esta función ofrece una capa esencial de protección para las comunicaciones cliente-servidor.
La asistencia está siempre disponible, no dude en publicar cualquier pregunta en el foro de 4D.