GlobalSign Blog

Autenticación del correo electrónico - Los pormenores de la protección de su bandeja de entrada

Autenticación del correo electrónico - Los pormenores de la protección de su bandeja de entrada

Correos electrónicos: no se puede vivir con ellos, no se puede vivir sin ellos, ¿verdad?

El empleado medio de una oficina recibe unos 121 al día, así que no es de extrañar que los trabajadores hayan tenido que idear sus propios mecanismos para decidir a qué correos electrónicos deben prestar atención y a cuáles no. Hace algunos años, solía ocurrir lo mismo con el buen y viejo correo "físico". ¿Cuántos anuncios había que revisar para llegar a los más importantes?

Curiosamente, la decisión de abrir o tirar un correo -digital o físico- se basa a menudo en un único factor: El nombre del remitente que aparece en el sobre.

Autenticación del remitente para el correo electrónico

Pero, ¿es ésta realmente una forma razonable de hacer una distinción? ¿Cómo podemos saber que el nombre del sobre no ha sido falsificado?

La respuesta es: Sin un examen más detallado, no podemos. En el caso del correo físico, existen garantías como las firmas, los sellos, los precintos y el debido proceso para quienes manejan nuestro correo. Pero incluso así, de vez en cuando, aparecen falsificaciones muy creíbles de documentos oficiales, ya que los delincuentes hacen todo lo posible por estafar a la gente y quedarse con su dinero.

Nos puede pasar a los mejores. Hace algunos años, recibí unas facturas de mi transportista. Pagué, pero unas semanas después recibí la misma factura. En un segundo vistazo se vio que el número de cuenta de la segunda factura era diferente. Después de llamar al transportista me enteré de que se trataba de una estafa, una estafa inteligente, ya que la propia carta era completamente indistinguible de la real.

En el caso del correo electrónico, existen otros mecanismos para determinar si el mensaje es legítimo o no. Y esas herramientas deberían utilizarse, ya que no se requieren grandes conocimientos técnicos para falsificar la dirección del remitente (nombre y dirección de correo electrónico que se muestra al destinatario). En términos técnicos, esto se llama spoofing. No te fíes de mi palabra, echa un vistazo aquí:

FakeEmailAddressVideo.jpg

 

 

 

 

 

 

 

Entonces, ¿de qué mecanismos disponemos para prevenir y detectar los correos electrónicos falsos?

DKIM, SPF y DMARC

El Correo Identificado por Clave de Dominio (DKIM), el Marco de Política de Remitentes (SPF) y la Autenticación, Notificación y Conformidad de Mensajes Basados en el Dominio (DMARC) son mecanismos basados en el DNS cuyo objetivo es evitar la falsificación de dominios de correo electrónico.

Veamos cada uno de ellos con más detalle, cubriendo cómo funcionan y lo que pueden y no pueden hacer.

SPF

La idea detrás de SPF es simple. Cuando se configura el SPF para un dominio, se crea un registro TXT de DNS específico para ese dominio. Un servidor de correo correctamente configurado en el extremo receptor, que procese un envío de correo desde el dominio del remitente, encontrará el registro SPF en una búsqueda de DNS.

Veamos la primera parte del registro de globalsign.com para entenderlo mejor:

v=spf1 ip4:114.179.250.0/30 ip4:211.123.204.251/32 ip4:27.121.42.215/32 [...] -all

La lógica aquí es bastante sencilla. v=spf1 declara que esta entrada se refiere al SPF. El rango de direcciones IP denota todas las direcciones IP que un servidor de correo receptor debe aceptar como origen para un correo con el dominio globalsign.com. Y -all significa que si cualquier otra dirección IP está enviando un correo en nombre de globalsign.com, el servidor de correo del destinatario debería poner el correo en cuarentena o rechazarlo por completo.

La entrada completa sería un poco más larga e incluiría una lista de dominios permitidos que pueden enviar en nombre de globalsign.com, pero lo anterior es prácticamente todo. Sin embargo, hay algunas limitaciones con el SPF. Cuando se trata de correos reenviados y de suplantación avanzada que también manipula la dirección IP del remitente, el SPF puede fallar. En ese caso, se necesitan otros mecanismos para crear mayores niveles de seguridad.

DKIM

Por eso se creó DKIM. Proporciona un mayor nivel de garantía para la autenticidad de la parte del dominio de un correo electrónico del remitente. El mayor nivel de garantía proviene de una firma criptográfica (un poco como S/MIME, pero no del todo... ya llegaremos a eso), por lo que un requisito para configurar DKIM es crear un par de claves públicas/privadas. La clave pública se anota entonces en la zona DNS del dominio y puede ser recuperada por el servidor de correo del destinatario para validar los correos electrónicos enviados desde ese dominio, que son firmados con la clave privada para que coincidan.

Veamos de nuevo una de las entradas de globalsign.com

"v=DKIM1;k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1vhugV30ayqwRy2mu+m6QyxvdVtHee/Chr

UqtrPflazjf3LfuGryocUGTZ66DsHZeTpjqdcRXms1+xpVsqeiXipw4jNPwx9VpyIyg0suI/2QYsIjKyj0

OFYWe22Ilgp/zjXXJUxJ4fTqT5ae0cAX5u3GNsj6dA8u9n3atIlwIDAQAB"

Al igual que con SPF, v=DKIM1 declara que esta entrada está destinada a DKIM. k=rsa permite al servidor de correo del destinatario saber que este par de claves es de tipo RSA y p=[...] es la propia clave pública. De nuevo, algo bastante sencillo. Ahora, cuando se envía un correo de globalsign.com, el servidor de correo de globalsign.com utilizará la clave privada DKIM para firmar el correo criptográficamente haciendo un hash del correo, cifrando el hash con la clave privada y adjuntándolo al correo. El servidor de correo del destinatario puede entonces hacer el hash del correo de nuevo y descifrar el hash cifrado con la clave pública que obtiene de la entrada DNS. Si ambos hash coinciden, se garantiza que el correo procede de globalsign.com y no ha sido manipulado.

DMARC

DMARC es una combinación de SPF y DKIM con algunas reglas adicionales para que el servidor de correo del destinatario sepa qué hacer con los correos electrónicos que no se ajustan a ninguna de las políticas anteriores.

Veamos la entrada de globalsign.com una vez más:

v=DMARC1; p=reject; rua=mailto:dmarc@globalsign.com

Al igual que con SPF y DKIM, v=DMARC1 simplemente declara que esta entrada TXT de DNS está declarando políticas DMARC. P=reject es la política para los correos que no cumplen lo anterior, "reject" significa que el servidor de correo del destinatario debe rechazar siempre estos correos. "Cuarentena" significaría que los correos deberían ser movidos a algún tipo de cuarentena, como carpetas de spam o similares. Y "Ninguno" permitiría al servidor de correo del destinatario su propio juicio sobre si los correos deben ser rechazados, puestos en cuarentena o permitidos.

rua=mailto:dmarc@globalsign.com especifica una o más direcciones de correo electrónico que deben ser notificadas cuando falla la validación SPF o DKIM. Esto puede ser útil para combatir los esfuerzos organizados de los malos actores para suplantar un dominio, lo que es especialmente útil para los dominios que con frecuencia son objeto de suplantación.

Cerrar las brechas con S/MIME

Aunque SPF, DKIM y DMARC suponen una mejora significativa en la seguridad del correo electrónico, no son el paquete completo. Hay al menos tres puntos débiles:

  1. Todas estas políticas se basan en el DNS y, por lo tanto, se pueden eludir, por ejemplo, falsificando la búsqueda del DNS en el extremo de los destinatarios o simplemente utilizando direcciones de correo electrónico homogéneas/alternas para la dirección del remitente que no comparten las políticas del dominio real.

  2. La autenticidad del correo electrónico se limita a la parte del dominio del correo, lo que significa que, aunque hay cierta seguridad de que el correo procede realmente de un determinado dominio, la parte no relacionada con el dominio puede ser falsificada. Esto puede hacer que el remitente sea vulnerable, por ejemplo, a que personas malintencionadas de dentro de la empresa falsifiquen el correo en nombre de otro departamento o persona interna.

  3. Dado que las firmas DKIM sólo son aplicadas por el servidor de correo del remitente y son validadas por el servidor de correo del destinatario, la garantía de la integridad del contenido y la autenticidad del remitente no es totalmente de extremo a extremo. El mensaje queda vulnerable entre el cliente y el servidor de correo tanto para el remitente como para el destinatario. Esto se puede mitigar con una implementación adecuada de TLS tanto para el servidor de correo del remitente como del destinatario, pero este es otro tema que va más allá del alcance de este artículo.

EmailAuth_ServerGraphic.pngFigura 1: Visión general simplificada de cómo se enruta un correo electrónico estándar, incluyendo las búsquedas DNS pertinentes

Aquí es donde S/MIME hace el trabajo mejor que SPF, DKIM y DMARC:

  • Las firmas S/MIME son aplicadas directamente por el cliente de correo electrónico y sólo son validadas por el cliente de correo electrónico de los destinatarios. Esto significa que no puede producirse ninguna manipulación del mensaje, ni siquiera entre el servidor de correo y el cliente de correo.

  • La clave pública para la validación de la firma se adjunta al certificado que acompaña al correo, por lo que el cliente de correo electrónico no necesita depender de una entrada DNS.

  • La organización del remitente en el certificado también ha sido verificada por la CA que emite el certificado S/MIME. Por lo tanto, un actor malintencionado que utilice una dirección de correo electrónico homogénea no podrá utilizar el nombre de la organización del dominio original.

  • Y, por último, el nombre RFC 822 del certificado debe coincidir exactamente con la dirección de correo electrónico "friendly-from", lo que significa que la autenticidad del remitente está ahora garantizada a nivel de dirección de correo electrónico y no sólo a nivel de dominio. Esto mitiga significativamente los puntos débiles enumerados anteriormente.

Bueno, mejor, aun mejor: ¿qué elegirá para la seguridad de su correo electrónico empresarial?

¿Significa eso que todas las organizaciones deben elegir S/MIME en lugar de SPF, DKIM y DMARC? La respuesta es claramente "no".

Las organizaciones deberían tener su SPF, DKIM y DMARC correctamente configurados - honestamente, esto debería ser lo mínimo - pero como se ha señalado anteriormente, no llegan hasta el final. Para aquellos que quieran ofrecer el máximo nivel de seguridad a los destinatarios de su correo electrónico, los certificados S/MIME deberían ser la herramienta elegida. Recuerde que S/MIME puede permitir el cifrado de extremo a extremo del correo electrónico, algo que queda totalmente fuera de la consideración de SPF, DKIM y DMARC.

El correo electrónico ha experimentado un increíble resurgimiento en los últimos dos años, sin duda ayudado por el crecimiento del comercio electrónico y el cambio hacia el trabajo a distancia que hemos presenciado durante la pandemia. De hecho, cada día se envían y reciben más de 306.000 millones de correos electrónicos (Statista, 2021, vía Hubspot).

Desgraciadamente, los hackers también están tomando nota, buscando nuevas y sofisticadas formas de infiltrarse en los datos corporativos y causar estragos. Las empresas inteligentes armarán a sus empleados con los métodos de seguridad de correo electrónico más fuertes disponibles y, en este momento, eso significa S/MIME.

Por suerte, los métodos de despliegue y gestión de certificados S/MIME han mejorado y se han hecho más fluidos con el tiempo.

Share this Post

Últimos blogs