¿Los relés de correo siempre deben indicar el uso de cifrado en el campo del encabezado “Received:”?

Navega tus respuestas
3

Cuando se envía un mensaje de correo electrónico con cifrado de transporte, puede indicarlo desde el campo "Recibido:" que el relevo de correo receptor agrega al encabezado del mensaje. 

> Received: from [...].google.com ([...]) by
> [...].mail.protection.outlook.com ([...]) with Microsoft
> SMTP Server (TLS) id [...] via Frontend Transport; [...] +0000

Me pregunto si este es siempre el caso (por ejemplo, porque es requerido por algún tipo de estándar).

Aquí hay un extracto del encabezado de un mensaje que recibí recientemente de un servicio de atención al cliente. 

> Received: from freshdesk.com (ec2-[...].compute-1.amazonaws.com [...])
>         by ismtpd[...]iad1.sendgrid.net (SG) with ESMTP id [...]
>         for <[...]>; [...] +0000 (UTC)

Y aquí hay otro, quizás más preocupante, del reenviador de correo electrónico de ACM. 

> Received: from in-007.lax.mailroute.net
>        by acmsmtp01.acm.org (ACM Email Forwarding Service) with ESMTP id [...]
>        for <[...]>; [...] -0500

¿Puedo estar seguro en estos casos de que los mensajes se transmitieron en texto claro?

    
pregunta ȷ̇c 10.12.2015 - 10:09
fuente

3 respuestas

5
  

Me pregunto si este es siempre el caso (por ejemplo, porque es requerido por algún tipo de estándar).

En realidad no. La RFC más reciente para SMTP RFC 5321 describe el formato del encabezado recibido, pero esto no incluye dicha información. probablemente también porque STARTTLS para SMTP es un estándar adicional. Este estándar se describe en RFC 3207 y no proporciona información sobre lo que debe agregarse al encabezado recibido tampoco.

En general, la información se almacena dentro de las partes de comentarios del encabezado Recibido (que se puede insertar en casi cualquier lugar) y parece que no se adhiere a un solo formato específico. Por lo tanto, depende principalmente del servidor de correo, si esto se incluye en el encabezado Recibido y de qué manera diferentes servidores de correo lo manejan de manera diferente.

Aparte de eso, no hay pruebas de que el mensaje se haya transmitido realmente con TLS, incluso si encuentra este encabezado. Este encabezado se acaba de insertar por el servidor que puede poner cualquier cosa dentro de él. También podría ser modificado o eliminado por otros servidores de correo en la ruta. Ninguna si la información allí puede ser completamente confiable, ya que no están protegidos contra la eliminación, falsificación o modificación de ninguna manera.

    
respondido por el Steffen Ullrich 10.12.2015 - 10:49
fuente
1

Sí

rfc5321 sección 3.7.2 dice:

  

La puerta de enlace DEBE indicar el entorno y el protocolo en la "vía"   cláusulas de los campos de encabezado recibidos que proporciona

por lo tanto, es posible que un servidor de correo no proporcione la "cláusula with" (esto queda aún más claro en el ANTLR de la sección 4.4, consulte Opt-info), en cuyo caso no tiene datos

... pero si especifica que el transporte fue ESMTP, entonces sí, afirmaría que se transmitió en texto claro. De lo contrario, deberían haber utilizado el tipo de protocolo ESMTPS ( ver Registro de la IANA ). No conozco ningún MTA que admita ESMPTS, pero lo registra como ESMTP en el encabezado recibido.

OTOH puede encontrar un transporte registrado, pero con una palabra clave para la que tiene que adivinar si fue transportado de forma segura o no. Tu primer extracto es un buen ejemplo. Yahoo también utiliza un transporte personalizado internamente.

    
respondido por el Ángel 24.02.2016 - 00:50
fuente
0

No puede estar seguro de nada de los encabezados "Recibidos". Pueden alterarse o forjarse completamente fácilmente.

    
respondido por el jknappen 10.12.2015 - 10:21
fuente

Lea otras preguntas en las etiquetas

Implicaciones de la extensión SGX de Intel para la detección de malware y la ingeniería inversa de sombrero blanco ¿Cómo puedo crear una clave aleatoria segura para AES?