El correo electrónico, o e-mail, es un caos maravilloso. Esa es una de las frases que solía utilizar yo cuando hablaba de cómo funcionaba y cómo había evolucionado, durante las charlas que di en el año
2009 con mi querida
Informática 64 en la charla "
Hay una carta para ti". Un caos maravilloso que usamos a diario, pero que tiene muchas lagunas de funcionamiento y apaños, de los que os voy a comenzar a hablar por aquí.
En este artículo, que he dividido en cuatro partes, voy a intentar hacer un recorrido didáctico y somero, sobre todas las vicisitudes que ha ido pasando, y las cosas que hemos ido construyendo sobre él y alrededor de él para terminar con alguna idea nueva. Espero que os guste, y sobre todo que os entretenga la lectura.
La necesidad de comunicación
Comunicarse es una necesidad humana. Lo utilizamos para todo. Para planificar la caza de un animal que diera sustento a toda la banda de
Homo Sapiens en tiempos de nuestra etapa de cazadores-recolectores, o para establecer una cita amorosa con una pareja que nos ha estimulado el sistema químico a través de una
app de contactos en la que nos hemos dado de alta. Necesitamos comunicarnos para trabajar, para demostrar afecto, cariño, y hasta para estar enfadados con el mundo en
Twitter.
El ser humano se comunica, y necesitamos hacerlo por cualquier nuevo medio en el que haya otros como nosotros, nos conozcamos o no. Es por eso que, en cada medio en el que nos hemos ido desenvolviendo a lo largo de nuestras vidas hemos desarrollado sistemas de comunicación en él. Desde mensajes en los árboles, señales de humo, o cartas escritas enviadas por mensajeros a caballo.
En la era moderna, ya con la tecnología de los computadores aquí, también lo hemos hecho. Cuando aparecieron los primeros sistemas de tiempo compartido, en los que muchos usuarios podían utilizar un mismo servidor para ejecutar sus algoritmos, apareció la necesidad de comunicarse entre los usuarios de ese ordenador central. El administrador del servidor debía enviar comunicaciones a los usuarios, tales como normas de comportamiento, periodos de indisponibilidad por mantenimiento, o actualizaciones de información sobre nuevas características en el servicio.
Por supuesto, entre los propios usuarios también aparecieron estas necesidades de comunicación. Estos podrían trabajar en grupos, dentro de proyectos que realizaban conjuntamente, para los que necesitaban compartir ideas, resultados o propuestas. Había que comunicarse a través del medio común, es decir, el servidor que daba vida a ese ecosistema creado alrededor de él.
Del e-mail al Webmail, pasando por SMTP, POP3, IMAP
Los primeros servicios de correo eran muy sencillos. Los requisitos eran bastante sencillos, ya que todos los usuarios estaban en el mismo servidor, así que no intervenían para nada las redes de comunicación en ese momento. Un usuario se conectaba al servidor por medio de un terminal para tener un shell, por lo que todo lo que hacía se producía directamente en el propio servidor. Al final, su terminal no era más que el equivalente a tener una pantalla y un teclado conectado al servidor desde una ubicación remota. Pero para el software del servidor, una vez el usuario iniciaba sesión, era como si el usuario estuviera sentado físicamente al lado de él.
Para crear un sistema de comunicaciones entre usuarios no había que hacer nada especial que incluyera ubicaciones remotas, múltiples servidores, o redes complejas de interconexión con federación de identidad. La autenticación y el enrutamiento de las comunicaciones se simplificaba al estar todos los usuarios en el mismo servidor. Para resolver el problema de comunicación bastaba con crear un pequeño programa que corriera en el servidor y al que decías a qué usuario querías enviarle el mensaje, por ejemplo a a
p0344, cuál era el asunto por el que abrías esa comunicación, y cuál el cuerpo del mensaje.
En ese momento se generaba un fichero y el servicio de
e-mail que corría en el servidor creaba un fichero con esta información en la carpeta de ese usuario
p0344 - dentro del árbol de ficheros de ese usuario - destinada a recibir el correo. Es decir, el buzón de cada usuario era una carpeta con permisos de escritura para el servicio de “
e-mail” donde se le depositaban ficheros de texto con los datos de qué usuario le escribía, cuándo lo hizo, cuál era el asunto y el cuerpo del mensaje. Metadatos que enriquecieran la comunicación electrónica.
Para enviar mensajes el proceso requería hacer algo similar. Había una carpeta de mensajes de salida que el programa, por medio de un “
daemon” en el servidor leía periódicamente para ver si había algo nuevo. Cuando aparecía un nuevo mensaje, el servicio de “
e-mail” lo borraba de esa carpeta, lo ponía en la carpeta de mensajes enviados para que quedara un copia, y el mensaje era copiado también a la carpeta de entrada del usuario destinatario en su estructura de ficheros particular. Sencillo y funcional.
La cosa se complicó cuando aparecieron más computadores. Ya no teníamos solo un mundo sino un ecosistema de servidores en red y teníamos la necesidad de comunicar usuarios de un servidor, por ejemplo llamado “
Albeniz” con otro, por ejemplo llamado “
Zipi”. En ese caso había que hacer un protocolo para que el servicio de
e-mail de del servidor
Albeniz, fuera el que fuera, supiera dónde tenía que enviar el mensaje cuando el usuario no existiera en su mundo y fuera de otro ecosistema, como por ejemplo del servidor "
Zipi".
Para poder identificar a qué ecosistema pertenecía cada destinatario de las comunicaciones, inventamos las direcciones con la
@servidor y creamos un protocolo que comunicaba el enrutamiento de mensajes entre servidores. El famoso y popular
SMTP (Simple Mail Transfer Protocol) que habilitaba cada servicio de
e-mail utilizando un puerto, ahora sí, en la red, en este caso el puerto
25. Así, un usuario “
chema@albeniz.eui.upm.edu” podía enviar un mensaje a “
chema@zipi.fi.upm.edu”. Los servicios de correo electrónico se enviaban los mensajes uno a otro a través de mensajes de red encapsulados en
SMTP.
Pero un día los usuarios dejaron de utilizar plataformas de tiempo compartido como si estuvieran sentados en ellas, es decir, dejaron de conectarse a través de sesiones de terminal, y empezaron a usar sus propias estaciones de trabajo. Eso quería decir que el usuario
chema@albeniz.eui.upm.es tenía en su despacho otro mundo, en el que había otro usuario, otro sistema operativo, y otras funcionalidades. Había una estación de trabajo y no un terminal, donde se ejecutaba un mundo tipo
Solaris, o un
MSDos, o un
DRDOS, un
OS2/Warp o lo que fuera.
Es decir, era otro sistema informático distinto, por lo que si quería enviar correo electrónico utilizando su identidad de
chema@albeniz.eui.upm.edu debía actuar como un servidor remoto más y utilizar el protocolo
SMTP para conectarse con el servicio de enrutamiento de correos electrónicos en su servidor, pero eso no valía para poder leer sus mensajes recibidos. Había que crear un nuevo protocolo para que pudiera conectarse a ver los mensajes que le habían entrado en su buzón. Y así nació
POP3 (Post-Office Protocol v.3), corriendo en la red por el puerto
110.
Al final un puerto no es más que una zona de memoria que comunica a un programa que corre en un servidor con los mensajes que llegan por la red. Cuando arrancamos un programa que enruta mensajes con
SMTP en un servidor, lo que hace este programa es hablar con servicio que recibe el tráfico de red en host y decirle:
"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 25 como destinatario me lo pones en esta zona de memoria".
Esto mismo hace el protocolo
POP3, pero diciendo algo como:
"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 100 como destinatario me lo pones en esta zona de memoria".
Cuando los mensajes le llegan al servicio que gestiona las comunicaciones de red en el servidor, este va colocando los mensajes en diferentes direcciones de memoria para enviárselo a los servicios adecuados en función del número de puerto que venga en el destinatario. Es decir, es como el portero de un edificio en el que viven muchos vecinos y reparte los paquetes de
Amazon en los distintos casilleros de los vecinos en función del puerto, que en ese caso serán
2º A,
3º C o
Bajo C. Como podéis ver por los números de los puertos de los protocolos, la necesidad de conectar servidores nació tiempo antes de la necesidad de descargar el correo del buzón a la estación de trabajo.
Y funcionó. Y se masificaron los usuarios de estos servicios. Cada vez más personas utilizaban el e-mail para todo. Ya no solo trabajo, sino también para socializar entre ellos, lo que hizo que se vieran las limitaciones de estos protocolos creados hasta el momento.
SMTP y
POP3 tenían que ser extendidos y su arquitectura y concepto inicial ya no eran los requisitos de hoy en día. Estos protocolos eran una evolución de la idea inicial de transferir mensajes en texto plano entre carpetas, y por eso no tenían gran funcionalidad.
Pero con la masificación de su uso se requería enviar comandos para hacer cosas en el buzón remotamente sin necesidad de descargar y enviar ficheros de texto. Si necesito crear una carpeta para organizar el correo y mover un mensaje de una carpeta a otra, descargarse mensajes de textos y volver a subirlos no tenía sentido. Por ello se creó una evolución completa para gestionar los buzones de correos, y entre las muchas propuestas, comenzó a emerger el protocolo
IMAP (Internet Message Access Protocol), con una cantidad de evoluciones.
Por supuesto, desde la primera concepción del servicio e-mail en los servidores de tiempo compartido, los clientes de correo electrónico fueron evolucionando. Desde un interfaz basado en comandos, a un interfaz modo texto corriendo en sesiones de terminales, para llegar a los clientes de hoy en día. Con la creación de
SMTP y
POP3 aparecieron las herramientas de gestión de
e-mail en estaciones de trabajo como
(Microsoft Outlook – que no es de las primeras ni mucho menos) para tener clientes de correo electrónico con interfaces gráficos, y con la llegada de
HTTP y las páginas web aparecieron los primeros servicios como
Hotmail o
Gmail. Estos, pasaron rápidamente a utilizar
IMAP y hoy en día es posible
gestionar tu buzón de Gmail con comandos IMAP, como hice yo hace ya muchos artículos.
Los problemas de seguridad
Como os podéis imaginar, con el aumento de la popularidad del correo electrónico, la evolución de la potencia de cómputo de los equipos en clientes y en servidores en
Internet, además de la masificación del número de usuarios conectados y la velocidad de las redes de comunicación, los problemas de seguridad con el correo electrónico fueron infinitos.
SMTP y
POP3 nacieron como protocolos para mover ficheros de texto plano que estaban en carpetas de un servidor. El esquema de amenazas que había cuando todos los usuarios estaban dentro del mismo servidor era mucho más pequeño que cuando tenemos dos o más servidores. Ya hay un medio por el que los mensajes deben pasar. Y deberían estar cifrados.
Así que primero intentamos cifrar las conexiones entre los servidores usando un protocolo como
SSL (Secure Socket Layer) para crear un túnel de cifrado servidor a servidor que impidiera que alguien pudiera interpretar el tráfico si interceptaba la señal en el medio. Así, creamos
SMTP-S y
POP3-S por puertos de rede distintos que la gente ya no se conoce tan de memoria.
Pero también sucedía que el esquema de identificación de remitente y de identificación del host cuando todos los servidores eran confiables y no era fácil conectarse a la red, tampoco valía. Se empezaron a suceder los ataques de suplantación de direcciones
IP en los que una estación de trabajo se hacía pasar por un servidor de correo electrónico, usando técnicas de
Spoofing o atacando al servidor
DNS para cambiar los servidores autorizados para recibir los mensajes de correo de una organización. El esquema de cifrado era inútil frente a ellos, ya que se estaban cifrando las comunicaciones contra el propio atacante, que estaba haciendo un “
man-in-the-middle”, así que pasamos a utilizar sistemas como
Mutual-TLS donde tenemos no solo que cifrar las comunicaciones, sino también firmarlas por los servidores que están allí.
Pero este proceso de enrutamiento de comunicaciones por la red solo por tramos cifrados no es obligatorio para que el
e-mail funcione, y una vez que el usuario ha recibido un mensaje de correo electrónico no sabe realmente si el mensaje va a acabar cifrado en el buzón del destinatario o no, y si la comunicación por la que ha venido era un canal cifrado o no. Y por supuesto, ya que se puede suplantar a un servidor de correo electrónico con una estación de trabajo, se puede suplantar a cualquier dirección de remitente que estuviera en ese servidor. Es decir, podrían aparecer mensajes como
chema@albeniz.eui.upm.edu que no hubieran sido enviados ni desde
albeniz.eui.ump.edu, ni desde luego por
chema.
Para ello, sería necesario que el cifrado y la firma de los correos electrónicos fuera extremo a extremos y robusta. Necesitamos no solo garantizar la comunicación de los servidores, sin la comunicación entre remitente y destinatario, para lo que utilizamos sistemas de firma digital como
PGP o los certificados digitales de
e-mail S/MIME.
Por desgracia, estos sistemas de certificados digitales son bastante poco usados, ya que tienes que generar certificados en entidades confiables, configurarlos en los diferentes clientes de
e-mail que uses (computadoras, ordenadores portátiles, tabletas, diferentes navegadores de
Internet) , hay que renovarlos, hay que intercambiarlos antes de establecer una comunicación segura, etc... Demasiadas barreras de usabilidad para la gran mayoría de las personas que utilizan mensajería
e-mail por
Internet, por lo que la mayoría de la comunicación por medio de correos electrónicos ni se cifra ni se firma.
Google intentó avisar a los usuarios cuando los correos venían cifrados en tránsito o no,
con un candadito rojo como respuesta a las filtraciones de
Edward Snowden en las que descubrió que la
NSA estaba capturando el tráfico sin cifrar. Y, además, todos los clientes de correo electrónico marcan con un icono especial si el mensaje viene cifrado y/o firmado desde el emisor.
Al final, como la realidad es que casi ningún mensaje llega firmado y cifrado extremo a extremo, los usuarios ven normal que un banco o su jefe les envíen un mensaje sin cifrar o firmar. Con lo que se abre el campo para los ataques de suplantación del remitente y de
Phishing o los más peligrosos
Spear-Phishing que se utilizan en los ataques dirigidos a personas concretas.
A todo esto hay que sumar problemas inherentes al sistema de correo electrónico más, y es que, al ser un sistema de comunicación de coste cero, se ha aprovechado para hacer captura masiva de clientes por medio de mensajes publicitarios, para hacer campañas de estafas masivas engañando a víctimas (
Scam), para dar de alta sin autorización en listas de correos, o para simplemente molestar.
Necesitamos más seguridad pero... ¿Será suficiente?
Tras la creación del servicio de e-mail, vimos que la necesidad de usabilidad nos llevó a crear
SMTP,
POP3 e
IMAP, y que las primeras amenazas nos llevaron a aplicar capas de seguridad como
SSL, y mecanismos de firma digital y cifrado extremo a extremo sobre sobre el servicio de
e-mail, como
PGP o
S/MIME, pero aún estamos lejos de que poder proteger al servicio de correo electrónico de todos los problemas que se fueron creando, así que hay que hacer más.
En la siguiente parte de este artículo veremos cómo se empezaron a intentar soluciones como
Sender Policy Framework,
Sender ID,
DKIM, o los
Filtros Anti-Spam basados en todo tipo de algoritmos, desde listas blancas y listas negras, hasta
Inteligencia Artificial pasando por los
Filtros Bayesianos o la colaboración de usuarios para detectar
Scams, Spam, Spear Phishing, y otros ataques a las personas. Pero aún así... no será bastante, así que habrá que ver qué alternativas han aplicado personas y empresas para lidiar con el
e-mail.
Saludos Malignos!
********************************************************************************************************
********************************************************************************************************
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
