SMTP y SSL / TLS

El SSL oportunista disuadirá a los atacantes pasivos que solo espían en la línea. También levanta ligeramente el nivel de los atacantes activos: para poder alterar los datos transmitidos (por ejemplo, para inyectar un correo electrónico falsificado en la transmisión), el atacante ahora debe hacer un MitM completo con un certificado falso. y descifrar / volver a cifrar toda la conexión.

Pero, en realidad, eso es para las relaciones públicas. Los servidores de retransmisión de correo grande como Gmail utilizan SSL / TLS cuando pueden sobre todo demostrar que son responsables y hacen un esfuerzo por "más seguridad". En última instancia, esto no es un mal movimiento: si la moda se afianza y se convierte en tradición, entonces podemos esperar que en algún momento SSL / TLS se convierta en obligatorio . Si los servidores SMTP deciden usarlo correctamente (es decir, con la validación adecuada del certificado de pares, completo con las revisiones de revocación), la seguridad general habrá aumentado.

SMTP es intrínsecamente un protocolo retransmitido, y cualquier retransmisión que no pertenezca al dominio de origen o destino es un hombre en el medio. SMTP se acercaría a la confidencialidad ofrecida por HTTPS si un servidor SMTP controlado por su organización buscara un servidor de correo de los registros DNS MX del dominio de destino y luego solo transmitiera el correo electrónico a través de TLS a ese servidor.

Obviamente, esto excluiría todo correo web, donde el cliente Javascript entrega el correo a través de HTTPS al servidor HTTPS del proveedor de correo web, que luego lo desencripta y luego lo almacena / transfiere en texto sin cifrar a sus servidores SMTP y luego puede o puede no lo envíe a través de TLS al servidor SMTP del dominio de destino.