Sin embargo, que yo sepa, cuando se trata de comunicaciones de servidor de correo a servidor de correo, la mayoría de los correos electrónicos todavía se transfieren en texto plano y no encriptados, lo que hace posible que cualquier persona en la red lea su contenido.
Correcto. SMTP, como HTTP, es texto sin formato por defecto.
En la actualidad, muchos servidores de correo admiten TLS (anteriormente conocido como SSL) para SMTP. (Esto incluye Gmail.) Sin embargo, tiene los mismos problemas que con HTTP [S]: los certificados emitidos por CA reconocidas cuestan dinero, y los autofirmados no tienen valor 1 para protegerse contra los ataques MitM . Si su servidor de correo realiza una validación estricta del certificado del receptor (como lo hacen los navegadores web), es posible que no entregue mensajes a los servidores que utilizan certificados autofirmados o CA internas. Si no es así , no puede estar seguro de que está hablando con el servidor correcto y no con un impostor .
Además, TLS es una adición relativamente reciente a SMTP, por lo que incluso cuando el servidor de correo del destinatario admite TLS, es posible que el remitente no lo haga o que esté deshabilitado de forma predeterminada.
1 (A menos que el servidor remitente sea compatible con DANE (TLSA) y el administrador del servidor receptor se preocupe por publicar los registros TLSA en DNS. Esto rara vez se hace y es algo tedioso).
¿Existen tecnologías que brinden al usuario algunas garantías de que sus correos electrónicos se envían de forma segura de principio a fin?
Dos estándares de seguridad de correo electrónico más comunes:
OpenPGP , basado en web de confianza y de uso gratuito. La implementación de código abierto es GnuPG ( para Windows , para Thunderbird ), y el PGP original se ha convertido en el PGP Desktop comercial .
Para los clientes de correo electrónico basados en la web, FireGPG es una posibilidad , maldita sea
S / MIME , basado en la infraestructura X.509. Implementado por la mayoría de los clientes de escritorio (incluidos Outlook, Thunderbird, Mail.app). Sin embargo, relativamente impopular debido a la misma estructura basada en la autoridad que TLS / SSL: los certificados firmados cuestan dinero y los autofirmados no pueden validarse de manera confiable.
En ambos casos, el cifrado requiere que el destinatario ya esté usando el sistema y haya generado / obtenido un par de claves. (Para firmar , se utiliza el par de claves del remitente . La práctica normal es firmar y cifrar mensajes).
¿Por qué no informar al usuario cuando el cifrado no es compatible y dejar que elija si desea que su correo electrónico se entregue aún?
Por lo general, los mensajes enviados se ponen en cola , y ni el usuario ni el MTA pueden saber si el próximo salto admite TLS o no, hasta que se envíe el mensaje , momento en el cual no hay una forma confiable de pedirle confirmación al usuario. (Pueden estar AFK, fuera de línea, dormidos o un script / programa. Si envié el mensaje, quiero que se entregue lo antes posible).
Además, con SMTP nunca se sabe si el próximo salto es final o si solo retransmitirá el correo en otro lugar. No es raro que un MX de respaldo esté en una red completamente diferente.
Por lo tanto. la seguridad de extremo a extremo solo es posible cuando ambas partes usan OpenPGP o S / MIME.