Junto con la privacidad, la seguridad es una de nuestras prioridades clave. Trabajamos muy duro para brindarles a nuestros usuarios la experiencia más privada y segura al usar Mailfence. Muchos usuarios, tales como periodistas o disidentes, usan nuestro servicio para comunicaciones delicadas. Suelen ser objeto de amenazas persistentes avanzadas. Durante los últimos años, hemos lanzado una diversidad de nuevas funcionalidades para mejorar la seguridad de todos los usuarios de Mailfence.
Desde DANE hasta MTA-STS, WKD y VKS, demos un vistazo a nuestras mejoras de seguridad que contribuyen a proteger sus datos.
DANE y MTA-STS
Por qué le conviene
El DNS-based Authentication of Named Entities (o DANE; en español: Autenticación Basada en DNS de Entidades Denominadas) y el Mail Transport Agent Strict Transport Security (o MTA-STS; en español: Seguridad Estricta de Transporte para Agentes) son dos protocolos independientes que abordan fundamentalmente el mismo problema, que se suele conocer como ataque de degradación. En pocas palabras, el atacante es capaz de eliminar la capa de cifrado durante el transporte de correos electrónicos. Por tanto, es importante contar con un mecanismo que garantice la permanencia del cifrado en el transporte cuando los correos electrónicos van de una cuenta a otra.
En los primeros tiempos de internet, los servidores enviaban y recibían correos electrónicos en texto simple, sin cifrado de capa de transporte. Esto significaba que cualquier persona que estuviese monitoreando la red podría leer o modificar el mensaje. Después del advenimiento de TLS el estándar de correo electrónico fue adaptado para incluir cifrado de transporte si tanto el servidor que envía como el que recibe ofrecen compatibilidad para este. Sin embargo, los atacantes aún tienen la posibilidad de engañar al servidor remitente para que deje pasar correos de texto simple si anuncia que el servidor no es compatible con cifrado de capa de transporte.
Cómo funciona
MTA-STS es un protocolo que garantiza la entrega de correo electrónico usando el cifrado de transporte (no confundir con el cifrado de extremo a extremo) si el servidor receptor tiene compatibilidad para ello. El servidor de correo electrónico remitente busca y encuentra la política MTA-STS del servidor de correo destinatario. Dependiendo de cuál sea la política del servidor receptor MTA-STS, este rechazará cualquier intento de eliminar la capa de cifrado de transporte. El servidor remitente se basa en un largo tiempo de caché para evitar los ataques transitorios. Sin embargo tiene una desventaja: cada servidor de correo electrónico deve mantener su propia caché. Además, el propietario de un dominio puede establecer una política de MTA-STS, pero no tiene como hacerla cumplir.
DANE usa registros de DNS para informarles a otros servidores de correo electrónico acerca del soporte para cifrado TLS. Además, le dice al servidor receptor que espere un cierto certificado al conectarse al servidor remitente, defendiéndose así contra los atacantes que poseen un certificado TLS del servidor remitente, que sería válido para todos los efectos. Sin embargo, se basa en la seguridad del sistema de DNS, lo que significa que requiere de Extensiones de Seguridad DNS (DNSSEC), que a su vez producen un nivel limitado de adopción (esto último está cambiando).
Brindar soporte para DNSSEC (como prerrequisito para brindar compatibilidad a DANE) también aporta ventajas de seguridad adicionales. Algunos ejemplos incluyen la protección contra ataques de envenenamiento de caché de DNS y contra dominios personalizados que usan los registros MX de Mailfence, especialmente si el dominio personalizado implementa DNSSEC.
Tanto MTA-STS como DANE tengan sus pros y contras. Cada uno puede proteger contra los ataques de degradación de cifrado para entrega de correo. Así que hemos implementado ambos para mailfence.com.
Descubrimiento e intercambio de claves de OpenPGP (WKD y VKS)
Mailfence ofrece cifrado y firmas OpenPGP para correos electrónicos. Hemos sido interoperables con otros servicios compatibles con OpenPGP desde el comienzo, y les brindamos a nuestros usuarios un control total sobre las claves de OpenPGP. Sin embargo, el descubrimiento e intercambio de claves ha representado (durante mucho tiempo) un desafío para el ecosistema de OpenPGP, porque es difícil saber si se puede confiar en las claves que se reciben de un servidor de claves públicas.
Web Key Directory (WKD)
Ahora Mailfence brinda compatibilidad con un nuevo enfoque, llamado Web Key Directory (WKD, en español: “Directorio Web de Claves”), que usa internet para permitirle a un dominio servir sus propias claves mediante HTTPS. Esto implica que cuando usted genera un par de claves de OpenPGP o lo importa al depósito de claves de su cuenta de Mailfence, la clave pública respectiva (incluyendo la dirección de correo electrónico y el nombre) estarán públicamente disponibles en nuestro servidor de Directorio de Claves Web si:
- La dirección de correo electrónico asociada está basada en un nombre de dominio de mailfence.com.
- Se hace una asociación de dirección de usuario de correo electrónico con el ID de usuario de la clave. Un ícono en forma de llave al lado de la dirección “De” en el redactor de mensaje la representa.
- La clave está asociada a la dirección principal o de alias de la cuenta de Mailfence.
La clave pública solo se usa para, y con, un paquete solicitado de ID de usuario para no exponer otros paquetes de ID de usuario (por motivos de privacidad y para evitar el correo no deseado). No ofrecemos compatibilidad con el protocolo Web Key Service (WKS).
Los usuarios también pueden descargar claves públicas de OpenPGP desde dominios (o servicios) externos que sean compatibles con WKD en el depósito de claves de su cuenta de Mailfence. El propietario del dominio personalizado tendrá que configurarlo para el dominio propio o para usar WKD como servicio.
Validating Key Server (VKS)
Anteriormente hemos utilizado el fondo Synchronizing Key Server (SKS). Después de la implementación del RGPD en el 2018, estábamos buscando alternativas a causa de los problemas de privacidad conocidos con el fondo SKS (que terminó por cerrarse el 21-06-2021). Evaluamos una gran cantidad de servidores de claves públicas, y nos decidimos por keys.openpgp.org. Puede leer más al respecto aquí.
Permiten que la información de identidad (ID de usuario: nombre de visualización y dirección de correo electrónico) se distribuya solamente con autorización y también permite su eliminación. Consulte su politica de privacidad para más información.
Podrá encontrar las claves públicas usando una dirección de correo electrónico. Tenga presente que las claves sin ID de usuario (nombre de visualización y/o dirección de correo electrónico) no son procesables por nuestra parte. Tenemos la intención de resolver esto en el futuro.
Orden de búsqueda de claves
Nuestro objetivo era usar un mecanismo de descubrimiento de claves que permitiese:
- Confirmación positiva de propiedad de claves / Resistencia al vandalismo
- Resistencia a la censura
- Descentralización
No encontramos un medio que fuese compatible con los tres puntos antes mencionados, así que decidimos brindar compatibilidad con múltiples mecanismos. Cuando un usuario busca una clave pública, la plataforma de -Mailfence emplea el siguiente orden de búsqueda de claves:
- Web Key Directory (WKD): el dominio actúa como un ancla de confianza para la confirmación positiva de propiedad de las claves (mediante el modelo TOFU). Si se halla una clave pública, el proceso de búsqueda de claves se detiene.
- Validating Key Server (VKS): la propiedad de la dirección de correo electrónico se realiza mediante la validación de doble inscripción. No ser controlado/gestionado por un propietario de claves públicas que ofrece un nivel de resistencia a la censura.
La validación de las firmas y la actualización del estado de las claves públicas siempre se hace mediante VKS (no hace falta emplear órdenes de búsqueda).
No pudimos hallar un mecanismo idóneo que ofreciese el nivel deseado de descentralización (uno de los valores clave de OpenPGP), así que seguiremos esforzándonos para hallar una solución a esto.
Otros
- Hemos comenzado a implementar la política DMARC de remitentes. Aquí encontrará más información.
- Comenzamos a usar el registro DNS CAA. Esto ayuda a evitar que las autoridades de certificados emitan un certificado de Mailfence ilegítimo.
- Para mantenernos al tanto de cualquier problema de conectividad TLS durante la entrega de correos electrónicos, estamos atentos a los informes enviados mediante el estándar TLSRPT.
- o protect our users from identity impersonation attacks, and our service from abuse, we have decided to forbid deletion of Mailfence domain name based alias addresses. Este cambio se aplicará el 01 de enero de 2022. Aquí encontrará más información.
Como siempre, seguiremos mejorando nuestra seguridad para brindarles la mejor experiencia a nuestros usuarios. Nunca dejaremos de trabajar para que Mailfence sea cada vez más privado y seguro. Usted puede ayudarnos contribuyendo con nuestros esfuerzos.
Síganos en twitter/reddit y manténgase actualizado en todo momento.
