Lo que necesitas saber sobre el uso de SSL/TLS para cifrar las conexiones realizadas por tus servidores de correo electrónico

Cuando se me propuso
el tema para esta entrada del blog, acepté encantado. He aquí una paráfrasis
de cómo se desarrolló:

«¿Podrías
escribir un post sobre la importancia de TLS en los servidores de correo electrónico?», preguntó Patrick.

«Claro», dije.

¡Ay, esa fue una conversación
loca de revivir! Como un torbellino!

Después me puse a pensar un poco en ello. ¿Realmente hay servidores de correo electrónico que no usan encriptación para el tránsito? No me refiero a la encriptación de extremo a extremo como hemos cubierto en el pasado (S/MIME, PGP, etc). Me refiero a la encriptación de servidor a servidor o todo lo que está en medio para proteger los datos a lo largo de la ruta de tránsito.

Seguramente, en estos tiempos, nadie dejaría su correo entrante/saliente en texto plano atravesando Dios sabe qué ruta para ser interceptado y aprovechado. Mucha gente utiliza servicios de correo electrónico y es imposible que excluyan el cifrado en tránsito de su servicio. Las filtraciones de datos les cuestan millones en
demandas y pérdida de negocio y vergüenza……Hmmmm…..

Volví a Patrick
con una pregunta.

«¿Tenemos estadísticas
o información sobre los servidores de correo electrónico que no utilizan cifrado? Mi opinión es que sería
baja. En otras palabras, ¿qué le ha llevado a preguntarme por este artículo?»

Patrick respondió: «En realidad, no lo sé. Pensé que sería un buen tema teniendo en cuenta la importancia
del correo electrónico y todos los aspectos necesarios para la seguridad.»

Ok. Eso tiene sentido. Probablemente haya algunos servidores de correo electrónico que no lo utilicen en absoluto, aunque sin duda un porcentaje mucho mayor puede estar utilizando protocolos desfasados o certificados caducados y puede que sólo necesiten una actualización.

Este artículo repasará
dónde estamos con el correo electrónico y el cifrado de tránsito para asegurarse de que está
operando en un nivel de seguridad óptimo que está disponible.

Encriptación en Servidores de Correo Electrónico

En este punto, probablemente tenemos una comprensión general de cómo funciona TLS pero vamos a resumir en caso de que seas nuevo en esto.

Persona A quiere enviar
comunicación segura Humano B. Persona A y Humano B tienen un certificado preestablecido
. La Persona A utiliza el certificado para cifrar la información y envía
la información cifrada al Humano B. La información es ilegible hasta que el Humano
B utiliza el certificado para descifrar la información cifrada.

Si el Humano B quiere
responder a la Persona A con información cifrada, entonces el Humano B utilizaría el
certificado para cifrar los datos y la Persona A utilizaría el certificado para
descifrar el mensaje.

Así es como funciona generalmente el
encriptar/desencriptar. Ahora sustituye las personas que aparecen en este ejemplo por
servidores y otras conexiones de este tipo. El mismo concepto.

Ahora, si el Humano B quiere responder a la Persona A con información encriptada, entonces el Humano B utiliza la clave simétrica que se acaba de generar y ahora pueden tanto encriptar como enviar, y recibir y desencriptar datos entre sí.

Así es como funciona generalmente el cifrado/descifrado con SSL/TLS. Ahora sustituye las personas que aparecen en este ejemplo por servidores y otras conexiones de este tipo. El mismo concepto. Así es como funciona TLS con el correo electrónico, que es un poco diferente de cómo facilita una conexión HTTPS debido a que el correo electrónico utiliza protocolos diferentes. Pero, todavía hay algunas similitudes distintas:

• Se produce un apretón de manos
• Se produce la autenticación (aunque ambas partes se autentican en este contexto)
• Se utilizan claves de sesión para transmitir el flujo de correos electrónicos.

Flujo (de correo)

El siguiente paso a este
«entender por qué a» artículo es la parte de «entender cómo».

En resumen, un cliente de correo electrónico envía un correo electrónico al servidor de salida. El servidor de salida hará una búsqueda de DNS, basada en el dominio de correo electrónico de destino, y el registro MX de ese DNS determinará a qué servidor enviar el correo electrónico y, posiblemente, ese servidor determinará si necesita ser reenviado hasta que llegue al agente de entrega de correo (MDA) de la bandeja de entrada de destino.

No es suficiente con
confiar en los registros MX de DNS, que es una cuestión de confianza totalmente distinta, sino que el servidor SMTP
(correo que sale, MTA, etc) y el correo que entra (a través de POP3, IMAP,
Exchange) deben ser capaces de identificarse mutuamente y tener las claves correctas para
comunicarse entre sí. Y, dependiendo de la ruta, puede haber más
que sólo una comunicación de servidor de correo electrónico de un salto. A lo largo de la ruta puede haber intercambiadores de correo, servidores proxy, etc. Cada salto (debería) requerir un enlace encriptado. A menudo, lo hace. A veces, no. Los usuarios preferirían que la información sensible estuviera encriptada a lo largo del camino. La encriptación de extremo a extremo
ayuda a asegurar que hay algún tipo de encriptación en todo el camino, pero
las capas de seguridad son siempre, eh, mejores.

Respeto a tu Securi-Tie

Para que conste,
Securi-Tie no es una palabra real. Sólo me inventé esa palabra porque rimaba. Es
un juego de palabras con la palabra seguridad.

Para saltar a la sección anterior, debemos hablar de las opciones de seguridad que, mientras que
se establecen desde el lado del cliente, en realidad proporcionan algunas instrucciones
al lado del servidor de correo para fines relacionados con la seguridad.

Cuando se configura un
cliente de correo (Outlook, Thunderbird, etc), el valor por defecto es una configuración sin cifrar
. Pero, como es el objetivo de este artículo, normalmente queremos optar por la opción encriptada. En cierto sentido, no depende totalmente del cliente: depende de lo que el servidor pueda soportar. Suponiendo que tus servidores de entrada
y salida puedan soportar la encriptación, ¿por qué no ibas a hacerlo? Si pides un
filete en un restaurante y te ofrecen solomillo a elegir o filete de Kobe(wagyu)
al mismo precio, ¿por qué no ibas a pedir el corte de mejor calidad?

Entonces, si quieres usar
TLS/SSL en tu correo electrónico (esto es para la parte de tránsito y no la parte de extremo a extremo,
S/MIME que se discute en otras entradas del blog), actívalo. Utilice los puertos 465
o 587 para SMTP (‘miembro, correo saliente) y 993 (IMAP) o 995 (POP3) para
el tráfico entrante.

Hay un
interesante protocolo de encriptación que todavía se utiliza entre los servidores de correo electrónico. Tiene sus cosas buenas con sus cosas malas como es el caso de la mayoría de las cosas. En definitiva, diría que
sus intenciones son buenas pero la aplicación en el mundo real no es todo lo ideal que podría. Señoras y señores, ese protocolo es STARTTLS.

STARTTLS es un protocolo de seguridad
que básicamente es SSL/TLS. Sencillamente, STARTTLS tomará una conexión de
texto plano existente y, por lo tanto, insegura, e intentará convertirla en una conexión segura utilizando TLS (o SSL). Por lo tanto, el nivel de seguridad de
STARTTLS frente a SSL/TLS no es diferente. Si todo está bien configurado, ambos encriptarán la información usando TLS (o SSL).

La principal diferencia se
basa en el estado de una conexión y/o el inicio de la comunicación. STARTTLS
no garantiza la comunicación cifrada. Básicamente significa, ‘si la
conexión está sin encriptar y eres capaz de hacerlo, conviértela en una
conexión segura’. Si el nodo de conexión (probablemente un servidor) es incapaz de convertir la
conexión en una conexión encriptada, puede depender del extremo del cliente para
decidir cómo manejarlo a partir de ahí.

Aunque utilicé el término de
calificación de STARTTLS como «útil», podría considerarse menos seguro
que la selección de SSL/TLS. La selección estándar de SSL/TLS es básicamente, «Usa
encriptación o revienta». STARTTLS está diciendo, «Um, si puedes, por favor hazlo. Si
no, podemos proceder basándonos en otras instrucciones».

Aquí hay algunas declaraciones concluyentes

A menudo, lo obvio necesita ser declarado y tal vez
exagerado. Así que aquí está, ejem: Utiliza la encriptación. Especialmente para algo que
es tan importante, tan crucial y está integrado en, aparentemente, la gran mayoría de
cualquier estructura organizativa que puede llevar a hacer o deshacer la información. No es necesario poner mucho esfuerzo en ello. Utilice tanto el cifrado de extremo a extremo como el cifrado en tránsito. Dos es mejor que uno.

Si alguien cree que el esfuerzo extra de configurar un servidor de correo electrónico
para que esté encriptado frente a uno sin encriptar no merece la pena, entonces ese alguien no
merece la pena. Esto es simplemente exagerar lo obvio. El cifrado de extremo a extremo, como S/MIME, requiere un enfoque más complicado, pero también merece la pena cuando se añaden capas y capas de
seguridad. Pero, no hay excusa para no tomarse el tiempo de configurar y mantener
enlaces seguros.

Cuando la visibilidad lo permita, cualquier ruta de correo electrónico que no parezca segura o comprometida debe ser sometida a escrutinio. Y con esto, sean felices en su escrutinio por un internet más seguro. Saludos!

*** Este es un blog sindicado de Security Bloggers Network de Hashed Out by The SSL Store™ cuyo autor es Ross Thomas. Lea el post original en: https://www.thesslstore.com/blog/encryption-and-email-servers/