Hispanopedia WikiLa autenticación o validación del correo electrónico es un conjunto de técnicas destinadas a proporcionar información verificable sobre el origen de los mensajes de correo electrónico mediante la validación de la propiedad del dominio de cualquier agente de transferencia de mensajes (MTA) que haya participado en la transferencia y posible modificación de un mensaje.
El protocolo SMTP (Protocolo Simple de Transferencia de Correo ) original, basado en Internet , no cuenta con esta función, por lo que las direcciones de remitente falsificadas en los correos electrónicos (una práctica conocida como suplantación de identidad por correo electrónico ) se han utilizado ampliamente en el phishing , el spam y diversos tipos de fraude. Para combatir esto, se han desarrollado numerosas propuestas de autenticación de correo electrónico. Para 2018Tres de ellos se habían adoptado ampliamente: SPF , DKIM y DMARC . [ 1 ] [ 2 ] Los resultados de dicha validación se pueden utilizar en el filtrado automatizado de correo electrónico o pueden ayudar a los destinatarios a seleccionar una acción apropiada.
Este artículo no trata sobre la autenticación de usuarios para el envío y la recuperación de correos electrónicos.
Razón fundamental
A principios de la década de 1980, cuando se diseñó el Protocolo Simple de Transferencia de Correo (SMTP), este no contemplaba una verificación real del usuario o sistema remitente. Esto no suponía un problema mientras los sistemas de correo electrónico eran gestionados por empresas y universidades de confianza, pero desde la comercialización de Internet a principios de la década de 1990, se ha constatado que el correo electrónico se utiliza cada vez más para el spam , el phishing y otros delitos.
La autenticación del correo electrónico es un primer paso necesario para identificar el origen de los mensajes y, por lo tanto, para que las políticas y las leyes sean más aplicables.
La dependencia de la propiedad del dominio es una postura que surgió a principios de la década de 2000. [ 3 ] [ 4 ] Implica una autenticación de grano grueso, dado que los dominios aparecen en la parte derecha de las direcciones de correo electrónico, después del signo @ . La autenticación de grano fino, a nivel de usuario, se puede lograr por otros medios, como Pretty Good Privacy y S/MIME . En la actualidad, cada individuo debe, en última instancia, gestionar su propia identidad digital .
Una razón fundamental para la autenticación de correo electrónico es la capacidad de automatizar el filtrado de correo electrónico en los servidores receptores. De esta manera, los mensajes falsificados pueden rechazarse antes de que lleguen a la bandeja de entrada del usuario. Si bien los protocolos se esfuerzan por idear formas de bloquear de manera confiable el correo no confiable, los indicadores de seguridad pueden etiquetar los mensajes no autenticados que aún llegan a la bandeja de entrada. Un estudio de 2018 muestra que los indicadores de seguridad pueden reducir la tasa de clics en más de diez puntos: del 48,9 % al 37,2 % de los usuarios que abren mensajes falsificados. [ 5 ]
Naturaleza del problema
SMTP define el transporte de mensajes , no el contenido del mensaje . Por lo tanto, define el sobre del correo y sus parámetros, como el remitente del sobre , pero no la cabecera (excepto la información de seguimiento ) ni el cuerpo del mensaje en sí. STD 10 y RFC 5321 definen SMTP (el sobre), mientras que STD 11 y RFC 5322 definen el mensaje (cabecera y cuerpo), conocido formalmente como formato de mensaje de Internet .
SMTP define la información de rastreo de un mensaje, que se guarda en el encabezado utilizando los siguientes dos campos: [ 6 ]
- Recibido : cuando un servidor SMTP acepta un mensaje, inserta este registro de seguimiento en la parte superior del encabezado (de último a primero).
- Return-Path : cuando el servidor SMTP de entrega realiza la entrega final de un mensaje, inserta este campo en la parte superior del encabezado.
Un agente de usuario de correo (MUA) conoce el servidor SMTP de correo saliente a partir de su configuración. Un MTA (o servidor de retransmisión) normalmente determina a qué servidor conectarse consultando el registro de recursos DNS MX (Mail eXchange) para el nombre de dominio de cada destinatario .
La ruta representada a continuación se puede reconstruir a partir de los campos de encabezado de rastreo que cada host agrega a la parte superior del encabezado cuando recibe el mensaje: [ 6 ]
Return-Path: <author@example.com> Recibido: de D.example.org por E.example.org con SMTP ; mar., 05 feb. 2013 11:45:02 -0500 Recibido: de C.example.net por D.example.org con SMTP ; mar., 05 feb. 2013 11:45:02 -0500 Recibido: de B.example.com ( b.example.com [ 192.0.2.1 ]) por C.example.net (que soy yo) con ESMTP id 936ADB8838C para <different-recipient@example.net> ; mar., 05 feb. 2013 08:44:50 -0800 (PST) Recibido: de A.example.com por B.example.com con SMTP ; Mar, 05 Feb 2013 17:44:47 +0100 Recibido: de [ 192.0.2.27 ] por A.example.com con SMTP ; Mar, 05 Feb 2013 17:44:42 +0100Las primeras líneas en la parte superior del encabezado suelen ser de confianza para el destinatario. Estas líneas son escritas por máquinas en el Dominio de Administración Administrativa ( ADMD ) del destinatario, que actúan según su mandato explícito. Por el contrario, las líneas que prueban la participación de A y B , así como del supuesto agente de correo del autor , podrían ser falsificadas por C. El Received:campo que se muestra arriba es una parte fundamental del encabezado. El campo Return-Path:es escrito por E , el agente de entrega de correo (MDA), basándose en el sobre del mensaje . Campos de rastreo adicionales, diseñados para la autenticación de correo electrónico, pueden completar la parte superior del encabezado.
Normalmente, los mensajes enviados por el ADMD del autor van directamente al MX del destino (es decir, B → D en las figuras). El ADMD del remitente solo puede agregar tokens de autenticación si el mensaje pasa por sus buzones. Los casos más comunes se pueden esquematizar de la siguiente manera:
Envío desde dentro de la red de ADMD (MUA 1)
- El MSA de ADMD autentica al usuario, ya sea en función de su dirección IP o mediante algún otro método de autenticación SMTP. Dependiendo de la dirección del destinatario, el mensaje puede seguir la ruta normal o pasar por una lista de correo o un servicio de reenvío. [ nota 1 ] B puede ser un proxy SMTP de salida o un servidor de reenvío (smarthost ) . [ nota 2 ]
- Si la red local no bloquea las conexiones salientes del puerto 25, [ nota 3 ] el usuario puede implementar algún software "directo a mx". [ nota 4 ] Por lo general, los zombies y otros hosts maliciosos se comportan de esa manera.
- Si el MUA está mal configurado, también puede utilizar un relé diferente, como un relé abierto obsoleto , que a menudo no autentica al usuario.
Usuario itinerante (MUA 2)
- En la mayoría de los casos, todavía es posible utilizar el propio MSA de ADMD. [ nota 5 ]
- Las conexiones salientes al puerto 25 pueden ser interceptadas y redirigidas a un proxy transparente. [ nota 4 ]
- Un MUA puede configurarse para usar un relé SMTP que el proveedor de red local ofrece como ventaja adicional. [ nota 4 ]
Usuario desconectado
- Una tarjeta electrónica puede enviar correos electrónicos en nombre de un cliente que haya escrito direcciones de correo electrónico en el teclado local; algunos formularios web pueden considerarse que funcionan de manera similar. [ nota 4 ]
Notas de la sección
- ↑ Por ejemplo, un destinatario puede indicarle a Gmail que reenvíe los mensajes a una dirección de correo electrónico diferente. El remitente no necesariamente lo sabe.
- ↑ Los proxies configurados correctamente aparecen como parte del ADMD del autor.
- ↑ Algunos ADMD bloquean las conexiones salientes al puerto 25 (SMTP) para evitar esto. Esta técnica proactiva se describe en la RFC 5068. Además, algunos bloquean las conexiones SMTP entrantes desde direcciones IP clasificadas como de acceso telefónico /DSL/cable.
- 1 2 3 4 En este caso, el ADMD del autor no está involucrado en absoluto.
- ↑ Algunos ISP bloquean el puerto 587, aunque el RFC 5068 dice claramente:
Los proveedores de acceso NO DEBEN bloquear el acceso de los usuarios a Internet externo mediante el puerto de ENVÍO 587.
Métodos de autenticación de uso generalizado
FPS
SPF permite al receptor verificar que un correo electrónico que supuestamente proviene de un dominio específico procede de una dirección IP autorizada por los administradores de ese dominio. Normalmente, un administrador de dominio autoriza las direcciones IP utilizadas por sus propios MTA salientes, incluidos los servidores proxy o smarthost. [ 7 ] [ 8 ]
La dirección IP del MTA remitente está garantizada como válida por el Protocolo de Control de Transmisión , ya que establece la conexión comprobando que el host remoto es accesible. [ 9 ] El servidor de correo receptor recibe el comando HELOSMTP poco después de que se establece la conexión, y un Mail from:al principio de cada mensaje. Ambos pueden contener un nombre de dominio. El verificador SPF consulta el Sistema de Nombres de Dominio (DNS) para obtener un registro SPF coincidente, que, si existe, especificará las direcciones IP autorizadas por el administrador de ese dominio. El resultado puede ser "aprobado", "fallido" o algún resultado intermedio, y los sistemas generalmente lo tendrán en cuenta en su filtrado antispam. [ 10 ]
DKIM
DKIM verifica el contenido del mensaje , implementando firmas digitales . En lugar de usar certificados digitales, las claves para la verificación de firmas se distribuyen a través del DNS. De esta manera, un mensaje se asocia a un nombre de dominio. [ 11 ]
Un administrador de dominio compatible con DKIM genera uno o más pares de claves asimétricas , luego entrega las claves privadas al MTA firmante y publica las claves públicas en el DNS. Las etiquetas DNS se estructuran como selector._domainkey.example.com, donde selector identifica el par de claves, y _domainkeyes una palabra clave fija, seguida del nombre del dominio firmante para que la publicación ocurra bajo la autoridad del ADMD de ese dominio. Justo antes de inyectar un mensaje en el sistema de transporte SMTP, el MTA firmante crea una firma digital que cubre campos seleccionados del encabezado y el cuerpo (o solo su comienzo). La firma debe cubrir campos de encabezado sustantivos como From:, To:, Date:, y Subject:, y luego se agrega al encabezado del mensaje mismo, como un campo de rastreo. Cualquier número de relés puede recibir y reenviar el mensaje y en cada salto, la firma se puede verificar recuperando la clave pública del DNS. [ 12 ] Siempre que los relés intermedios no modifiquen partes firmadas de un mensaje, sus firmas DKIM permanecen válidas.
DMARC
DMARC permite especificar una política para mensajes autenticados. Se basa en dos mecanismos existentes: Sender Policy Framework (SPF) y DomainKeys Identified Mail (DKIM).
Permite al administrador de un dominio publicar una política en sus registros DNS para especificar qué mecanismo (DKIM, SPF o ambos) se utiliza al enviar correos electrónicos desde ese dominio; cómo comprobar el From:campo que se muestra a los usuarios finales; cómo debe gestionar el receptor los fallos, y un mecanismo de informes para las acciones realizadas en virtud de esas políticas.
Otros métodos
Se han propuesto otros métodos, pero actualmente están obsoletos o aún no cuentan con un amplio respaldo. Entre ellos se incluyen Sender ID , Certified Server Validation , DomainKeys y los siguientes:
ADSP
ADSP permitía especificar una política para los mensajes firmados por el dominio del autor. Un mensaje debía pasar primero por la autenticación DKIM; luego, ADSP podía exigir un trato más severo si el mensaje no estaba firmado por el/los dominio(s) del autor, según el From:campo de encabezado. [ 13 ]
ADSP fue relegado a la categoría de histórico en noviembre de 2013. [ 14 ]
VBR
VBR añade una garantía a una identidad ya autenticada. Este método requiere autoridades reconocidas internacionalmente que certifiquen la reputación de los dominios.
Un remitente puede solicitar una referencia a una autoridad certificadora. Si se acepta, la referencia se publica en la rama DNS gestionada por dicha autoridad. Un remitente certificado debe añadir un VBR-Info:campo de encabezado a los mensajes que envía. También debe añadir una firma DKIM o utilizar algún otro método de autenticación, como SPF. Un receptor, tras validar la identidad del remitente, puede verificar la certificación solicitada VBR-Info:consultando la referencia. [ 15 ]
iprev
Las aplicaciones deben evitar usar este método como medio de autenticación. [ 16 ] Sin embargo, a menudo se lleva a cabo y sus resultados, si los hay, se escriben en el Received:campo de encabezado además de la información TCP requerida por la especificación SMTP.
La resolución inversa de IP, confirmada mediante la búsqueda de la dirección IP del nombre encontrado, solo indica que la IP se configuró correctamente en el DNS. La resolución inversa de un rango de direcciones IP puede delegarse al ADMD que las utiliza [ 17 ] o puede seguir siendo gestionada por el proveedor de red. En este último caso, no se puede obtener ninguna identidad útil relacionada con el mensaje.
DNSWL
Consultar una lista blanca basada en DNS ( DNSWL ) puede proporcionar una evaluación del remitente, incluyendo posiblemente su identificación.
Resultados de autenticación
RFC 8601 define un campo de encabezado de seguimiento Authentication-Results:donde un receptor puede registrar los resultados de las comprobaciones de autenticación de correo electrónico que realizó. [ 16 ] Se pueden informar varios resultados para varios métodos en el mismo campo, separados por punto y coma y ajustados según corresponda.
Por ejemplo, el siguiente campo supuestamente está escrito por receiver.example.orgy reporta los resultados de SPF y DKIM :
Resultados de autenticación: receiver.example.org ; spf=pass smtp.mailfrom = example.com ; dkim=pass header.i=@example.comEl primer token después del nombre del campo receiver.example.orges el ID del servidor de autenticación, conocido como authserv-id . Un receptor compatible con RFC 8601 es responsable de eliminar (o renombrar) cualquier encabezado falso que afirme pertenecer a su dominio para evitar confusiones en los filtros posteriores. Sin embargo, estos filtros aún deben configurarse, ya que necesitan saber qué identidades puede usar el dominio.
Para un agente de usuario de correo (MUA), resulta algo más difícil determinar en qué identidades puede confiar. Dado que los usuarios pueden recibir correos electrónicos de múltiples dominios (por ejemplo, si tienen varias direcciones de correo electrónico), cualquiera de esos dominios podría permitir Authentication-Results:el paso de campos por considerarlos neutrales. De esta forma, un remitente malintencionado puede falsificar un ID de servidor de autenticación que el usuario consideraría fiable si el mensaje proviniera de un dominio diferente. Un ID legítimo Authentication-Results:suele aparecer justo encima de un Received:campo del mismo dominio desde el que se reenvió el mensaje. Received:Pueden aparecer campos adicionales entre este y la parte superior del encabezado, ya que el mensaje se transfirió internamente entre servidores pertenecientes a ese mismo dominio de administración de correo (ADMD) de confianza.
La Autoridad de Números Asignados de Internet (INA) mantiene un registro de parámetros de autenticación de correo electrónico . Sin embargo, no es necesario registrar todos los parámetros. Por ejemplo, existen valores de "política" locales diseñados exclusivamente para el uso interno de un sitio, que corresponden a la configuración local y no requieren registro.
Véase también
- Cifrado de correo electrónico
- Ident – Protocolo de Internet que ayuda a identificar al usuario de una conexión TCP específica.
- Mensajería segura : método para intercambiar información de forma segura.
Referencias
- ↑ Hang Hu; Peng Peng; Gang Wang (2017). "Hacia la adopción de protocolos anti-suplantación". arXiv : 1711.06654 [ cs.CR ].
- ↑ kerner, Sean Michael (2 de enero de 2018). "La adopción de la seguridad del correo electrónico DMARC crece en el gobierno de EE. UU." . eWeek . Consultado el 24 de noviembre de 2018 .
- ↑ "Cumbre de autenticación de correo electrónico" . Taller . Comisión Federal de Comercio . 9 y 10 de noviembre de 2004. Archivado del original el 3 de junio de 2012. Consultado el 4 de febrero de 2013.
Sin embargo, el informe identificó la autenticación a nivel de dominio como un desarrollo tecnológico prometedor
. - ↑ Michael Hammer (14 de agosto de 2020). "Autorización de terceros" . dmarc-ietf (Lista de correo) . Consultado el 14 de agosto de 2020 .
- ↑ Hang Hu; Gang Wang (15 de agosto de 2018). Mediciones de extremo a extremo de ataques de suplantación de correo electrónico . págs. 1095–1112 . ISBN 9781939133045.
{{cite book}}:|work=ignorado ( ayuda ) - 1 2 John Klensin (octubre de 2008). "Información de rastreo" . Protocolo simple de transferencia de correo . IETF . sec. 4.4. doi : 10.17487/RFC5321 . RFC 5321. Recuperado el 1 de febrero de 2013.
Cuando el servidor SMTP acepta un mensaje, ya sea para reenvío o para entrega final, inserta un registro de rastreo (también denominado indistintamente "línea de marca de tiempo" o línea "Recibido") en la parte superior de los datos del correo. Este registro de rastreo indica la identidad del host que envió el mensaje, la identidad del host que recibió el mensaje (y está insertando esta marca de tiempo), y la fecha y hora en que se recibió el mensaje. Los mensajes reenviados tendrán varias líneas de marca de tiempo.
- ↑ Scott Kitterman (abril de 2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 . IETF . doi : 10.17487/RFC7208 . RFC 7208 . Consultado el 26 de abril de 2014 .
Hay tres lugares donde se pueden usar técnicas para mejorar las fallas no deseadas de SPF con mediadores.
- ↑ J. Klensin (octubre de 2008). "Alias" . Protocolo simple de transferencia de correo . IETF . sec. 3.9.1. doi : 10.17487/RFC5321 . RFC 5321. Consultado el 15 de febrero de 2013 .
- ↑ La falsificación de direcciones IP es posible, pero generalmente implica un nivel menor de comportamiento delictivo (allanamiento, escuchas telefónicas, etc.), que son demasiado arriesgados para un hacker o spammer típico, o servidores inseguros que no implementan RFC 1948, ver también Protocolo de control de transmisión#Secuestro de conexión .
- ↑ Scott Kitterman (21 de noviembre de 2009). "¿Qué tan confiable es bloquear/rechazar en caso de fallo de SPF?" . spf-help . gossamer-threads.com.
Creo que generalmente está bien siempre que ofrezcas un mecanismo para incluir en la lista blanca a los reenviadores que no sean SRS.
- ↑ D. Crocker; T. Hansen; M. Kucherawy, eds. (septiembre de 2011). DomainKeys Identified Mail (DKIM) Signatures . IETF . doi : 10.17487/RFC6376 . RFC 6376. Consultado el 18 de febrero de 2013.
DomainKeys Identified Mail (DKIM) permite que una persona, rol u organización reclame cierta responsabilidad por un mensaje al asociar un nombre de dominio con el mensaje, el cual están autorizados a usar.
- ↑ Dave Crocker (16 de octubre de 2007). "Preguntas frecuentes sobre DKIM" . DKIM.org. Archivado del original el 29 de septiembre de 2017. Consultado el 17 de febrero de 2013 .
- ↑ E. Allman; J. Fenton; M. Delany; J. Levine (agosto de 2009). Prácticas de firma de dominio de autor (ADSP) de DomainKeys Identified Mail (DKIM) . IETF . doi : 10.17487/RFC5616 . RFC 5616. Consultado el 18 de febrero de 2013 .
- ↑ Barry Leiba (25 de noviembre de 2013). "Cambiar el estado de ADSP (RFC 5617) a Histórico" . IETF .
- ↑ P. Hoffman; J. Levine; A. Hathcock (abril de 2009). Vouch By Reference . IETF . doi : 10.17487/RFC5518 . RFC 5518. Consultado el 18 de febrero de 2013 .
- 1 2 Murray Kucherawy (mayo de 2019). Campo de encabezado de mensaje para indicar el estado de autenticación del mensaje . IETF . doi : 10.17487/RFC8601 . RFC 8601. Recuperado el 12 de junio de 2023 .
- ↑ H. Eidnes; G. de Groot; P. Vixie (marzo de 1998). Delegación IN-ADDR.ARPA sin clases . IETF . doi : 10.17487/RFC2317 . RFC 2317. Consultado el 18 de febrero de 2013 .
- Spam
- Autenticación de correo electrónico
- fraude por internet
