Ahora se habla muy alegremente de encriptación por todas partes y en todos los servicios, pero no, así no ha sido con todos los servicios siempre. Al principio HTTP no era encriptado y luego se estándarizó la encriptación punto a punto, entre el navegador y el servidor web, una conexión punto a punto, aquí es muy fácil, se puede vertificar la identidad del servidor y se puede encriptar, algo maravilloso sin duda.

Pero el correo electrónico tiene un funcionamiento bien distinto, por un lado es asíncrono y el tráfico no va de un origen a un destino, el tráfico, el correo, va pasando de servidor en servidor que lo va almacenando y luego lo va reenviado hasta que llega al final, ¿habéis visto alguna vez una cabecera de un correo electrónico?, ahí tenéis el camino completo.

En este caso no podemos determinar una conexión extremo a extremo básicamente porque no existe, tenemos un montón de conexiones yuxtapuestas entre si, así que como veis el método utilizado en HTTP no nos sirve para el correo electrónico.

Hola a todos, yo soy Eduardo, esto es eduardocollado.com y hoy en el capítulo 170 vamos a hablar de la encriptación de correo electrónico con STARTTLS..

Como ya os he comentado tenemos un montón de conexiones de servidores que almacenan y luego reenvían el correo, en otras palabras, el sistema funciona con múltiples man in the middle, así que con esta premisa es bastante complicado el ofrecer un servicio seguro extremo a extremo.

Los protocolos involucrados en el correo electrónico son básicamente 3, por un lado SMTP, POP y finalmente IMAP.

SMTP es el protocolo que permite aceptar conexiones entrantes, estas conexiones originalmente se aceptan por el puerto 25, y el correo llega en texto plano y sin ningún tipo de cifrado.

POP es un protocolo que permite a los clientes aceptar correos de sus servidores de correo, por eso el nombre (Post Office Protocol), y originalmente funciona sobre el puerto 110, también en texto plano y sin encriptar, el correo se descarga al cliente y se borra del servidor.

IMAP (Internet Message Access Protocol) es un protocolo curioso porque no descarga correo, sino que gestiona remotamente el correo del servidor, es decir, con este protocolo se ve el correo del servidor. Aquí el puerto utilizado es el 143.

Aquí el objetivo es securizar las conexiones de los protocolos que acabamos de indicar, y tenemos que ver cómo hacerlo, para ello podemos tomar el ejemplo de HTTPS, cómo lo hace y cual es su funcionamiento.

HTTPS utiliza el puerto 443 para gestionar las conexiones encriptadas con SSL o TLS, pues en el correo vamos a hacer exactamente lo mismo, SMTP utilizará el puerto 465, POP utilizará el 995 e IMAP el 993, perfecto, ya tenemos asignados los puertos para gestionar las conexiones encriptadas.

Aquí surgió el problema que el puerto 465 encriptado de SMTP podía ser utilizado para comunicación entre servidores (MTAs) o entre cliente y servidor, así que se asignó otro puerto para conexiones cliente servidor, este era el puerto 567, seguramente el que tengáis configurado en vuestros clientes de correo.

La diferencia entre los puertos 465 y 587 para el SMTP consiste en el tipo de protocolo criptográfico a utilizar, mientras en el puerto 465 la encriptación SSL se inicia antes de cualquier comunicación SMTP. Con el puerto 587 la encriptación se puede iniciar con STARTTLS.

Pero si os dais cuenta no hay encriptación extremo a extremo en ningún momento con esta arquitectura, ya que la encriptación es entre cliente y servidor y entre MTAs, con lo que la encriptación va a tener en todo momento, como ya os he comentado antes elementos intermedios que podrán leer nuestros correos por muy encriptado que esté y claro, el camino se encripta, pero a trozos, con lo que en cualquiera de esos nodos intermedios el correo es perfectamente legible, ¿esto es lo que nosotros queremos cuando hablamos de encriptación de correo? obviamente no, pero es sin duda un gran avance al envío de correo en texto plano que ha existido toda la vida, así que algo es algo.

Pero también tenemos que tener en cuenta que la encriptación entre MTAs no tiene por qué producirse, si se soporta se encripta, pero si no se sigue transmitiendo en texto plano.

A día de hoy por suerte la mayoría de los servidores de correo soportan STARTTLS, en concreto el 89%, pero por desgracia muchos de ellos todavía no validan los certificados por mala configuración, aquí está el punto más importante y que trataremos en un momento, así que tenemos una encriptación, pero no validamos siempre los certificados. Es algo parecido a cuando entráis en una web con el candado roto y te dice el navegador que no ha podido validar el certificado, por ejemplo porque se ha utilizado un certificado autofirmado, y nosotros le damos alegremente al botón que dice que nos creemos la validez del certificado, la conexión se encripta, pero no hemos validado que el servidor sea quien dice ser, pues algo parecido. Exactamente lo mismo pasa con los certificados entre clientes de correo y servidores, puede ser que por cualquier motivo el certificado falle y que haya que decir manualmente que se acepte.

Ahora lo digo de memoria, pero recuerdo haber configurado clientes de correo que tenían la opción de aceptar todos los certificados, es decir, no validar certificado alguno. Obviamente esta configuración depende del cliente de correo, del PC, del móvil o de donde se esté consultando el correo y no tiene nada que ver con el servidor, es decir, en este punto la opción de no validar certificados depende única y exclusivamente del usuario.

Antes os he comentado que por mala configuración no se validan certificados muchas veces, pues para solucionar eso ha nacido StartTLS Everywhere, que es una iniciativa de la EFF (Electronic Frontier Foundation), una asociación que tal vez no os suene mucho, pero si os digo que hace un tiempo lanzó otra iniciativa llamada Let’s Encrypt seguro que ya os empezáis a situar un poco.

StartTLS Everywhere es a los servidores de correo lo mismo que Let’s Encrypt a los servidores web, se encarga entre otras cosas que los certificados sean válidos y que no tengamos los problemas derivados a la no validación de los certificados.

Y si lo que queréis es encriptar vuestro correo electrónico extremo a extremo, ¿qué podéis hacer?, pues lo mismo que se lleva haciendo durante años y que por alguna razón no se usa de forma masiva, y es el uso de GNUPG, pero eso ya es tema para otro capítulo del podcast.

Leer más en:

Comparte esto: Twitter

Telegram

WhatsApp

LinkedIn

Facebook

Pocket

