La versión 0.4 de CoyIM está a la vuelta de la esquina. Como habrás visto en otras publicaciones, este lanzamiento vendrá con muchas mejoras importantes. Y como estamos hablando de todos estos cambios, decidimos que es importante contarles la historia de por qué se creó CoyIM. No simplemente nos sentamos y pensamos que sería bueno tener otra aplicación de mensajería. Había razones específicas que nos hicieron sentir que existía un agujero en el ecosistema. En este y los siguientes artículos, nos gustaría contarte algunas de esas razones.
Para nosotros, el factor desencadenante realmente provino de dos perspectivas diferentes. La primera se refiere al entrenamiento de personas no técnicas para que utilicen mejores prácticas de seguridad operativa. La segunda proviene de la observación sobre lo que algunas personas de la comunidad de la seguridad estaban usando. En ese momento, el equipo STRIKE (uno de los grupos precursores de CAD) acababa de formarse, y esos dos factores llevaron a la decisión de crear varios componentes diferentes que eventualmente allanarían el camino para CoyIM.
Así que volvamos a estos dos factores desencadenantes. En ese momento, y durante varios años, los miembros del equipo habían estado dando la vuelta al mundo regularmente, encontrándose con personas en riesgo y ayudándolas de diversas maneras. La mayoría de las veces esta ayuda tomó la forma de talleres prácticos, analizando varias cosas que estas personas podrían hacer para mejorar su seguridad operativa inmediatamente. Entre los aspectos más importantes estaba fortalecer sus prácticas de comunicación. Enseñarles a usar XMPP y OTR fue el método principal para esto. La idea principal es que las cuentas XMPP son fáciles de obtener, se puede distribuir las cuentas en muchos servidores diferentes, es un protocolo normal utilizado por millones de personas en todo el mundo para diversos fines, por lo que no resultaría extraño para los atacantes de la red. Al mismo tiempo, OTR tiene algunas propiedades de seguridad que lo hacen significativamente mejor que el correo electrónico cifrado, por ejemplo. Lo que es aun más importante, OTR rota las llaves regularmente, asegurándose de que incluso si las llaves están comprometidas en algún momento, estas no se puedan usar para descifrar mensajes anteriores, y tampoco para descifrar mensajes futuros, a menos que el ataque continúe. Al mismo tiempo, OTR proporciona denegabilidad, lo que significa que para las personas en las situaciones más riesgosas, incluso un compañero de conversación no podría probar que alguien más dijo algo. Para cierto tipo de situaciones, este tipo de enfoque prudente de la seguridad es necesario. Tener una solución integral para esto usando OTR y XMPP era extremadamente poderoso. Además de todo esto, solíamos agregar Tor a la mezcla, asegurándonos de que los atacantes no pudieran conectar las comunicaciones con sus direcciones IP reales. Si se combinaban estos conceptos básicos con algunos consejos sobre compartimentación y sobre cómo generar cuentas XMPP anónimas, se podía llegar a una situación en la que incluso personas sin conocimientos técnicos podrían comunicarse de una manera extremadamente segura. Y, dado que la mayoría de las personas que necesitaban asesoramiento no eran técnicos, esto era extremadamente importante. Por supuesto, el hecho de que Tails admitiera de forma nativa esta configuración hizo que fuera aún más fácil mostrar cómo mantener comunicaciones seguras.
Pero la segunda parte de esta historia es un poco más triste. Específicamente, para enseñar esta combinación básica de protocolos, teníamos que usar un cliente XMPP existente con soporte para OTR. Debido a las condiciones de la época, la mayor parte del tiempo este terminó siendo Pidgin, especialmente porque Tails usaba Pidgin, para empezar. Pero esto significaba que para enseñar a las personas cómo usar esto correctamente, había una serie de pasos que tendrían que seguir. Primero, tendrían que instalar Pidgin. Luego, Tor. Tendrían que configurar Pidgin para usar Tor. Entonces, habría que instalar el plugin de OTR. Luego, tendrían que configurar correctamente el plugin de OTR. Y después habían muchas más cosas pequeñas que tendrían que configurar para mejorar la seguridad de su situación. Por ejemplo, si tenían más de una cuenta configurada, tenían que recordar establecer el nombre de usuario y la contraseña de SOCKS5 para Tor aleatoriamente, con el fin de forzar diferentes circuitos Tor para cada cuenta. Además, debían recordar escribir algo al azar en la sección del recurso. Y luego, si su servidor usaba servicios cebolla (onion), tendrían que recordar cómo configurar esto correctamente. Y, por supuesto, las personas con las que hablaban tenían que hacer lo mismo.
Al final de todo este proceso, tendrían una forma razonablemente segura de comunicarse. Asumiendo que Pidgin, el plugin de OTR y la librería de OTR estuviesen libres de errores. Dado que todos estos componentes estaban escritos en C, casi cualquier tipo de error podía ser potencialmente usado para explotar y atacar la aplicación de forma remota. Y dado que Pidgin es una aplicación muy grande, con soporte para muchos protocolos diferentes y muchos tipos diferentes de complejidad, había muchas posibilidades de que este tipo de errores existieran. En general, la cantidad de errores en una aplicación es proporcional a las líneas de código que posee. Y con algo escrito en C, esto puede ser catastrófico. Pidgin tenía errores críticos de seguridad que eran reportados regularmente durante este período de tiempo. Todos los que trabajábamos dando consejos de seguridad buscábamos alternativas que pudieran ser mejores. Pero por varias razones, esa configuración de Pidgin seguía considerándose la alternativa más segura en ese momento. Así que estábamos atascados, promoviéndola y enseñándola, a pesar de que conocíamos los potenciales riesgos.
Durante este mismo período de tiempo, varias personas de la comunidad de la seguridad comenzaron a usar una solución
diferente. Esta estaba basada en una aplicación llamada xmpp-client. Estaba escrita en Golang, un lenguaje con
protección de memoria, y además contenía su propia implementación de OTR. La parte realmente buena de este programa era
que OTR estaba integrado directamente en la aplicación, y el código fuente era lo suficientemente mínimo como para que
fuera fácil revisarlo y comprender todo lo que estaba haciendo. Y como fue escrito en un lenguaje más seguro, el riesgo
de errores era menor; incluso si existieran errores, era menos probable que condujeran a resultados de seguridad
catastróficos. Sin embargo, había un gran inconveniente con esta aplicación. Era una aplicación de línea de comando con
la que te comunicabas usando comandos de texto. Sin ventanas, sin gráficos. Sólo texto. Para gente con una mentalidad
técnica, esto a menudo puede ser una experiencia agradable, pero no es algo que podamos esperar de la mayoría de las
personas sin conocimientos técnicos. Peor aún, requería conocimiento y disciplina para administrar de manera segura. Una
vez más, era algo que funcionaba para un pequeño segmento de la población, sin que se pudiera esperar tener una
aceptación mayoritaria. Así que ahí es donde estábamos atrapados. Enseñando una solución subóptima para las personas
a las que queríamos ayudar, mientras nosotros usábamos otra solución, ya que no esperábamos poder
distribuirla ampliamente.
Así estaban las cosas cuando se formó el equipo STRIKE en Quito, Ecuador. Y precisamente por eso, uno de los primeros
proyectos en el que este equipo decidió trabajar fue crear una implementación completa de OTR para el lenguaje de
programación Golang. La implementación de OTR utilizada en xmpp-client era buena, pero carecía de varias
funcionalidades importantes. Lo que es más importante aún, no tenía soporte para la versión 3 del protocolo
OTR. Entonces, el equipo decidió agregar esto último, pero pronto se hizo evidente que simplemente era mejor reescribir
la librería tomando inspiración en la implementación de xmpp client. Esto también nos permitió probar la implementación
desde cero, asegurándonos que cada uno de sus componentes funcionara como esperábamos que lo hiciera.
Algunas iteraciones más tarde, el equipo asumió la tarea de agregar una interfaz gráfica de usuario a xmpp-client. Al
inicio, se mantuvo gran parte del código básico de xmpp-client. Pero con la interfaz gráfica de usuario, el soporte
para múltiples cuentas y la integración de la nueva librería de OTR, teníamos suficientes funcionalidades como para
lanzarlo como un nuevo producto, llamado CoyIM. Desde entonces, se ha incorporado una gran cantidad de
funcionalidades. El código ha sido refactorizado muchas veces y mejorado en el proceso. Hoy por hoy, queda muy poco de
xmpp-client dentro de CoyIM, a no ser por la perspectiva histórica.
En las próximas publicaciones describiremos algunas de las razones más importantes por las que sentimos que era necesario crear una nueva aplicación en lugar de trabajar con una existente. Las tres más importantes son el lenguaje de programación, la seguridad por defecto y la minimización de funciones.
Estamos muy orgullosos de la versión 0.4, pues esta continúa el camino que comenzó hace mucho tiempo descrito en esta publicación. Nosotros creemos que es, por mucho, el lanzamiento más importante de CoyIM hasta el momento. Continúa leyendo acerca de porqué existe CoyIM y luego pruébalo!