¿Cómo puede un usuario no técnico verificar que un mensaje se envió "de forma segura"? … O sobre TLS?

Su objetivo es conducir en un tornillo, y usted quiere usar un martillo porque tiene uno a mano y es fácil de usar. Me temo que el resultado más probable es un pulgar dolorido.

TLS se basa fundamentalmente en la seguridad punto a punto. Solo se adjunta a la conexión, no a los datos. El correo electrónico, por otro lado, está diseñado fundamentalmente para rebotar a través de múltiples saltos. Si bien los saltos dejan un sello rastreando sus acciones, dependería de que los hosts no sean maliciosos (cada salto puede falsificar el mensaje completo, incluidos los sellos de sus predecesores), para no ser engañado (por ejemplo, para autenticar a su predecesor). y dejar los sellos que esperas.

Puede dar al destinatario la confianza de que el mensaje se transmitió de manera segura mediante la entrega de un mensaje cifrado firmado por el remitente. TLS no es útil para esto. RFC que puede ayudarlo a incluir RFC 3156 , RFC 4880 (Formato de mensaje OpenPGP), RFC 5750 y RFC 5751 (S / MIME).

En otras palabras: use PGP o S / MIME.

De hecho, no puedes dar ninguna garantía en ningún caso. No puede garantizar de forma fiable que un correo electrónico determinado esté protegido por TLS en cada salto, porque los servidores relevantes lo hacen de manera oportunista, y la lista de servidores relevantes puede cambiar sin previo aviso ( el enrutamiento dinámico, incluso a nivel de SMTP, es común para los servidores altamente utilizados). Incluso para un correo electrónico que se envió , puede saber si las conexiones estaban protegidas por TLS solo en la medida en que los servidores relevantes tuvieron la amabilidad de declararlo (y luego, solo en los encabezados Received: ), y, nuevamente, solo si el mismo servidor tuvo la amabilidad de no mentir al respecto.

El formato de los datos en los encabezados Received: es puramente tradicional, no estándar, y no todos los servidores usan el mismo formato. Este encabezado debe ser legible para los humanos, al menos para una noción de "humano" que coincida con el entorno social de los primeros escritores de RFC. Como ha notado, no se puede esperar que todos los clientes sean "ese tipo de humano".

Un punto aún más importante es que el encabezado Received: solo se puede ver en el correo electrónico que se recibió . Imagina a una persona malvada que quiere leer algunos correos electrónicos enviados por otras personas a otras personas. Si ese individuo malvado es < inserta aquí tu agencia de espías favorita > , entonces solo tiene que sobornar a un interno en uno de los lugares donde se encuentra un servidor SMTP. Pero supongamos que el malo es un freelancer. Querrá interceptar el correo electrónico mientras se transfiere del servidor SMTP G (como "Gahoo") al servidor SMTP Y (como "Ymail") (nombres ficticios, por supuesto). Así que emplea el MitM del hombre pobre, conocido como DNS envenenamiento : se hace pasar por el servidor SMTP Y a los ojos del servidor SMTP G.

G se conecta, los atacantes afirman que no admiten TLS (o que admiten TLS con un certificado incorrecto, o lo que sea); G luego se degrada con gracia a no TLS, y envía el correo electrónico "tal cual". Entonces, el malo no no reconoce la recepción del correo electrónico y, en cambio, interrumpe la conexión de manera abrupta. El servidor SMTP G considera que la ocurrencia es un error de red aleatorio, lo intenta de nuevo, esta vez se conecta al servidor Y real (posiblemente transmitido por el atacante, no importa), hace TLS, envía el correo electrónico. En la parte receptora, no habrá rastro alguno de la transferencia no TLS abortada que terminó en la máquina del atacante. El correo electrónico contiene una gran cantidad de encabezados Received: , todos los cuales afirman que TLS se utilizó en todo momento, porque solo hablan de la conexión de correo electrónico exitosa .

Si bien no puede garantizar que el correo electrónico estuviera bien protegido, podría convencer a un cliente no técnico que estaba bien protegido. Por ejemplo, al no decirle algo de lo anterior ...

La conclusión es que el correo electrónico no es seguro y nunca lo estuvo . Para la seguridad del correo electrónico, necesita una verdadera solución de extremo a extremo, es decir, PGP o S / MIME (suponiendo que se empleen adecuadamente, lo que no es un hecho).

En el caso específico descrito anteriormente, donde está enviando desde un proveedor conocido con capacidad TLS a un receptor conocido con capacidad TLS (sin inconvenientes en los MX de copia de seguridad de terceros), puede confiar en la ruta, pero no hay manera para que un destinatario lo confirme además de dividir los encabezados Received (o registros SMTP en cada salto) si se usó TLS en el camino.

Dada la naturaleza de almacenamiento y reenvío de SMTP, en el caso general , usted (el remitente) no puede saber de antemano que llegará un mensaje específico después de haber usado solo conexiones TLS en cada salto.

Según mi conocimiento, no hay una manera interoperable ¹ para indicar a un servidor SMTP por mensaje que solo use TLS; y no hay un método común para que un MUA lo indique, como un indicador visual DKIM en algunos clientes de correo electrónico. Dado que el formato de encabezado Received varía de MTA a MTA, ese es un problema más difícil que podría parecer.

Con una base de usuarios no técnicos, una alternativa podría ser el PDF encriptado, esto viene con un requisito de secreto compartido ... aunque también puede entrar en conflicto con las políticas de inspección de contenido obligatorias.

Otra alternativa comúnmente utilizada (que de nuevo tiene un requisito de secreto compartido o de autenticación) es enviar por correo electrónico un enlace HTTPS al contenido.

Supongo que mostrarle al usuario cómo cortar y pegar los encabezados también está disponible, aunque incluso mxtoolbox se aleja de analizar los detalles de TLS, en teoría sería posible.

Una solución TLS no encaja bien: es la capa 5 (sesión), intenta proporcionar seguridad de capa de la capa 7 (aplicación) (y sin tragar los tres de la seguridad de confidencialidad , integridad , autenticación píldoras amargas ...)

¹ La SalesForce X-SFDC-TLS-NoRelay header parece ser una forma patentada, aunque supongo que aquí no puedo encontrar su documentación intención.

La solución es no enviar la PII por correo electrónico. Envíe esa información a través de un sitio web donde pueda asegurarse de que esté cifrado TLS y que también sea de fácil acceso para el consumidor y para los agentes de seguros.

Bienvenido al problema del correo electrónico seguro. Veamos sus opciones:

1. SMTP

   A nivel de protocolo, SMTP no tiene ningún concepto de seguridad. Como la mayoría de los primeros protocolos de Internet (estoy viendo tu DNS), fue diseñado asumiendo que no hay servidores maliciosos alrededor. No asuma NADA sobre las cosas enviadas a través de SMTP por razones documentadas en las otras respuestas aquí

2. PGP o S / MIME

   Ambas son capas de aplicación que aseguran capas inferiores inseguras. Eso es genial, pero ambos requieren el efecto de red (de los usuarios) para funcionar, un problema que ambos heredan de su uso inevitable del cifrado asimétrico (el problema PKI). Considerando que el correo electrónico (como una aplicación) tiene el mayor número de usuarios de Internet en el planeta, no veo que eso cambie en el corto plazo. En una situación B2C (incluso en muchas B2C), estás sin suerte.

3. Capa de direccionamiento indirecto (también conocida como "Ilusión de seguridad")

   Esto no brinda seguridad alguna, PERO si intenta cumplir con las leyes de MA sobre el hecho de no enviar PII, es posible que pueda enviar un enlace basado en GUID en un correo electrónico, que cuando se hace clic presenta la información real en un navegador. O use correos electrónicos HTML en los que el texto de PII sea en realidad una imagen cargada a través de SSL dentro del cliente de correo electrónico. Técnicamente no está enviando la PII real a través de un transporte inseguro. No necesito informarle, pero debe consultar a un abogado si esto cubre su riesgo comercial.

4. Modificar el requisito comercial ( < == recomendado )

   Personalmente, esto es lo que yo escogería. Para empezar, evitaría enviar cualquier PII en el correo electrónico. Si se trata de marketing por correo electrónico para nuevos clientes (B2C), en realidad podría asustarlos al poner PII en un correo electrónico frío. Si ya tiene estos clientes (B2C), le recomiendo configurar un centro de mensajería basado en la web detrás de una pantalla de inicio de sesión (suponiendo que su empresa tenga un portal de inicio de sesión para otras cosas). Honestamente, este es el enfoque adoptado por la mayoría de los bancos y hospitales por la razón exacta por la que está experimentando (a nadie le gusta otro portal de mensajería, pero está obligado a hacerlo). De esa manera, puede utilizar el correo electrónico regular sin PII para correos electrónicos masivos, y así poder acceder al portal web para los casos en que se requiera PII. Presupueste el despliegue del portal de mensajería segura (junto con la integración de SSO) y preséntelo a los responsables de la toma de decisiones que crean la necesidad comercial de "debe enviar PII por correo electrónico" y deje que ellos decidan si el precio vale la necesidad.

Tuve la misma pregunta y descubrí que mxtoolbox.com (ahora) proporciona una interfaz para consultar un servidor SMTP e informar si admite TLS. Esa es la única evidencia que parece que podemos presentar que TLS está en su lugar.

Nunca debe enviar PII a través de un correo electrónico de texto simple. Incluso si los saltos de la red están protegidos por TLS, no puede estar seguro de que los datos estén cifrados en reposo. En muchos casos, los datos están disponibles para terceros o cuartos terceros, por ejemplo, Google, en particular, examinará los correos electrónicos de sus usuarios para averiguar qué anuncios mostrarle o detectar patrones en el correo no deseado, y no puede confirmar que todos los sistemas involucrados sean adecuadamente seguros o compatibles. E incluso si lo son, todavía puede sufrir una pérdida de reputación significativa si, por ejemplo, usted le envía un correo electrónico "privado" a uno de sus clientes sobre la disfunción eréctil, entonces, de repente, comienza a ver anuncios de Viagra en todas partes, porque Google filtró una determinada palabra clave en su red de anuncios. .

Dos alternativas vienen a la mente:

1. Asegure el contenido del correo electrónico con un esquema de cifrado como PGP.

2. No pongas el contenido en el correo electrónico en absoluto. En su lugar, proporcione un enlace a un sitio donde el usuario pueda iniciar sesión y ver el contenido. Así es como funciona el servicio de sobre seguro de Citrix, por ejemplo.