CUSTOMIZE Cuando hablamos de "Email Authentication", nos referimos a una técnica que proporciona al destinatario de un mensaje cierto nivel de certeza de que el mensaje realmente se originó en la fuente que se afirma en el mensaje.
Cuando hablamos de “Email Authentication”, nos referimos a una técnica que proporciona al destinatario de un mensaje cierto nivel de certeza de que el mensaje realmente se originó en la fuente reclamada del mensaje. La idea detrás de tales técnicas es lograr algún nivel de defensa contra el correo electrónico fraudulento, como phishing y spoofing, correo que podría erosionar la confianza del destinatario en recibir correo electrónico. Dicho esto, el acto de enviar correo electrónico autenticado no afirma que el correo sea bueno o deseado; solo significa que el correo es tal que se puede establecer de manera confiable una reputación para la parte autenticada y usarse en decisiones de aceptación y ubicación de correo electrónico.
Hoy en día, existen dos formas de autenticación de correo electrónico en uso:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
En la publicación de hoy, cubro qué es DKIM y cómo funciona.
Descripción general de DKIM
A diferencia de su contraparte de autenticación SPF, que proporciona una forma para que un dominio autorice a un host a enviar correo en su nombre, DKIM proporciona una manera para que una entidad (dominio, organización, persona, etc.) se responsabilice de un mensaje, independientemente de la entidad que realmente envió el mensaje. Aunque en muchos casos la entidad responsable y la entidad emisora serán la misma, o al menos estarán estrechamente relacionadas, con DKIM no hay un requisito de que sea así.
Mis objetivos para ti con este artículo son que aprendas y entiendas los siguientes conceptos sobre DKIM:
DKIM es una autenticación "basada en contenido", a diferencia de SPF "basada en ruta".
La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en un encabezado del mensaje.
La validación de DKIM es realizada por el dominio receptor que intenta generar los mismos dos hashes.
La validación de DKIM no se puede completar en muchos casos hasta que el mensaje completo haya sido transmitido por el servidor emisor.
Las fallas de validación pueden ser difíciles de solucionar.
Autenticación basada en “Content-Based”
DKIM Signing y Validation
Las organizaciones que deseen firmar correos con DKIM primero generarán dos claves criptográficas. Una de las claves se mantiene privada y disponible para el servidor de envío para la firma de correos, y la otra se hará pública en DNS para su uso por los dominios receptores en intentos de validar la firma. Los métodos para generar estas claves e instalarlas dependen de la plataforma y están fuera del alcance de esta publicación, aunque más adelante describiré la publicación en DNS de la clave pública DKIM.
El DKIM-Signature Header
Para comenzar a entender DKIM, primero veamos un encabezado DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
El encabezado DKIM-Signature es una serie de pares clave-valor, algunos de más interés para el lector que otros, pero los describiré todos aquí.
Primero, veamos aquellos que son mayormente de interés pasajero para el lector:
v=1; – Especifica la versión DKIM (1 es el único valor válido)
a=rsa-sha256; – El algoritmo usado para construir los hashes criptográficos
c=relaxed/relaxed; – Hay dos conjuntos de reglas respecto a la eliminación de espacios en blanco en los encabezados y el cuerpo que se pueden aplicar al crear los hashes en una firma DKIM; estas reglas se llaman “reglas de canonización” (de ahí la clave c) y los conjuntos de reglas son “relaxed” o “strict”.
t=1454417737; – La marca de tiempo de cuando la firma fue creada.
Estas tres partes del encabezado contienen la información de la firma real:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Este es el hash del cuerpo del mensaje.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Esta es una lista de los encabezados que se usaron para crear los datos de la firma mostrados abajo.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Estos son los datos de la firma DKIM actual
Estas tres partes son de mayor interés para el servidor receptor que estará validando la firma:
d=welcome.foo.com; – Este identifica el dominio que firmó el mensaje
s=notices; – El selector; los dominios pueden tener múltiples selectores que usan al firmar mensajes.
i=@welcome.foo.com; – Esta es la identidad en cuyo nombre se firmó el mensaje. Sintácticamente, esto se verá como una dirección de correo electrónico, e incluso podría ser una; la parte local de la dirección de correo electrónico puede estar vacía, como en este ejemplo, y la parte del dominio debe ser la misma o un subdominio del dominio en la parte d= de la firma.
La razón por la que estas partes son de interés para el servidor receptor es que proporcionan la información necesaria para ayudar al receptor a validar las firmas.
DKIM Validation
Además del requisito mencionado de que el dominio i= debe ser el mismo que o un subdominio del dominio d=, los bits d= y s= son utilizados por el validador para buscar la clave pública DKIM del firmante en DNS. La clave es un registro TXT en DNS, y siempre se encuentra en la ubicación selector._domainkey.domain. Entonces, en nuestro ejemplo aquí, con s=notices y d=welcome.foo.com, la clave pública DKIM se encontraría en DNS en notices._domainkey.welcome.foo.com, y podría parecerse a esto:
notices._domainkey.welcome.foo.com. texto descriptivo "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
El validador utiliza esa clave (los bits p=) para producir su propio conjunto de hashes del mensaje; si esos hashes coinciden, entonces el mensaje no ha sido alterado durante el tránsito, y así el mensaje puede contribuir, y tal vez beneficiarse, de cualquier reputación que esté en vigor para el firmante del mensaje.
Fallo de Validación y Solución de Problemas
Mencioné anteriormente que las fallas de DKIM pueden ser difíciles de solucionar, y explicaré por qué es así aquí.
Algunas fallas en la validación de DKIM tienen causas obvias, como que el mensaje no esté firmado, o que la clave pública del dominio firmante no se encuentre en el DNS o no sea sintácticamente correcta, o tal vez el mensaje haya sido obviamente alterado durante el tránsito. Cuando ocurren ese tipo de fallas, es fácil identificar el problema y recomendar una solución. Sin embargo, las difíciles, y las que conducen a la experiencia de soporte más frustrante, son los casos en que el mensaje fue firmado, la clave pública existe en el DNS y el mensaje no fue obviamente alterado, pero el validador informa que la firma no pasó la validación.
La razón por la que estas fallas son difíciles de solucionar es porque no hay una manera real para que ninguna de las partes reproduzca las condiciones bajo las cuales el mensaje fue firmado y validado. El mensaje tiene en su encabezado DKIM-Signature los hashes que fueron generados por el firmante en el momento de la firma, pero el validador probablemente no tiene acceso a la infraestructura del firmante y, por lo tanto, no puede intentar reproducir la firma bajo las condiciones del firmante. De manera similar, el firmante probablemente no tiene acceso a la infraestructura del validador y, por lo tanto, no tiene manera de intentar validar el mensaje de la misma manera que lo hizo el validador.
Fallos como los que estoy describiendo aquí son eventos raros, y las fallas de validación de DKIM por sí solas generalmente no tienen un impacto en la colocación de entrega. Mientras que DKIM maneja la autenticación de mensajes, implementar técnicas de validación de correo electrónico integrales asegura que estás enviando a direcciones legítimas que pueden recibir y autenticar tus mensajes realmente. En mi experiencia, tales fallos generan más tickets de soporte que cualquier otro tipo de problema relacionado con DKIM.
