¿Por qué SMTP sobre SSL entre servidores de correo electrónico no es tan popular? [cerrado]

11

En mi opinión, la mayoría de los servidores de correo electrónico utilizan SMTP / POP / IMAP sobre SSL para cifrar el correo electrónico.
Admite cifrado cuando el cliente (UA) envía un correo electrónico al servidor (MTA) y UA recibe un correo electrónico de MTA. Sin embargo, no muchos MTA pueden cifrar cuando envían correos electrónicos entre MTA y MTA.
(¿Es correcto mi entendimiento?)

por ejemplo, [email protected] envía un correo electrónico a [email protected]
[PC de Alice] --- encriptado (SMTPS) ---> [servidor de somewhere.com] --- NO ENCRIPTADO (SMTP) ---> [en cualquier lugar. servidor de la organización] --- cifrado (POPS o IMAPS) ---> [PC de Bob]

Si mi comprensión es correcta, ¿por qué la mayoría de los servidores de correo electrónico no admiten SMTP sobre SSL entre servidores de correo electrónico?

Desarrollo una mejor interfaz (menos compleja) para habilitar el cifrado de correo electrónico con PGP / GPG, pero en estos días creo que puede ser mejor usar SMTPS porque PGP / GPG necesita la firma manual de claves para mantener la confiabilidad.

security email ssl smtp Jumpei Ogawa
fuente
¿Qué tiene esto que ver con el cifrado de correo electrónico? correo electrónico medios de cifrado para mí que el correo electrónico se cifra por sí sola ...
Uwe Plonus
?? Lo siento, no entendí lo que quieres decir ... ¿Cómo "el correo electrónico se cifra por sí solo"? Según tengo entendido, el correo electrónico puede ser fácilmente interceptado si lo envía como texto sin formato (sin cifrado).
Jumpei Ogawa
1
Sí, pero enviar un correo electrónico cifrado no tiene nada que ver con el cifrado SSL / TLS del servidor SMTP.
Uwe Plonus
1
Para asegurarse de que solo reciba correo a través de un canal encriptado en su servidor SMTP, deberá forzar el uso de TLS. Por lo tanto, si la otra parte no entiende / no admite TLS, no recibirá su correo. Si permite un respaldo a la comunicación sin cifrar, no logró nada. Esta es la razón por la cual las personas prefieren cifrar el correo en sí mismo y enviarlo a través de un canal no cifrado.
Der Hochstapler
Para aclarar: "correo electrónico encriptado" se refiere a encriptar los contenidos usando algo como PGP incluso antes de enviarlo a su servidor de correo saliente. Eso tiene la ventaja adicional de mantenerlo en secreto de quien ejecuta su MTA. No se refiere a cifrar el correo electrónico entre MTA; el cifrado normalmente se aplica solo en los extremos, no en el medio. Tenga en cuenta también que la comunicación entre UA y MTA a menudo implica la transmisión de algún tipo de contraseña, que de todos modos debe cifrarse.
cpast

Respuestas:

4

Buena pregunta, realmente no he visto ninguna cifra para esto. No estoy seguro, pero creo que muchas grandes empresas ahora admiten SSL / TLS para SMTP entrante y saliente (entrega de correo "MX"). Esto normalmente es opcional y se puede negociar a través de StartTLS en el puerto 25. Sin embargo, la mayoría de los servidores SMTP no requieren TLS de servidor a servidor, ya que significaría que muchos no podrían recibir correo de un MTA que no es compatible o no está configurado para TLS.

Muchos clientes de correo electrónico admiten TLS entre UA y MTA, ya sea SMTP / IMAP sobre SSL o POP3 sobre SSL. Creo que gmail, por ejemplo, requiere SSL / TLS para IMAP y POP3.

Con respecto al cifrado de correo electrónico de extremo a extremo real, esto normalmente se logra usando S / MIME o PGP. Sin embargo, debido a la complejidad de configurarlo y administrarlo, no se ha visto una adopción a gran escala.

lanudo
fuente
Gracias. Así que entiendo el estado actual del cifrado de correo electrónico. ¿Quiere decir que SMTPS de servidor a servidor no es compatible con muchos servidores porque el software de servidor como postfix no lo admite? Si la mayoría del servidor de correo lo admite, ¿se resolverá el problema? (Tal vez no entiendo tu respuesta correctamente ...)
Jumpei Ogawa
Incluso cuando se negocia el cifrado, generalmente no se realiza una verificación estricta de los certificados porque eso bloquearía todos los servidores con certificados autofirmados. Pero sin un control estricto, un ataque de hombre en el medio es fácil (sin mencionar que un MITM podría evitar STARTTLS al intervenir la fase de texto sin formato)
Hagen von Eitzen
RFC 2487 prohíbe que los servidores de correo público requieran TLS: "Un servidor SMTP de referencia pública NO DEBE requerir el uso de la extensión STARTTLS para entregar el correo localmente. Esta regla evita que la extensión STARTTLS dañe la interoperabilidad de la infraestructura SMTP de Internet".
ARX