Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 14 de febrero de 2013
Archivos de la lista de correo de BulletProof.
Repositorio Mercurial de BulletProof.
BulletProof es un programa escrito en Python y que debería funcionar en casi cualquier sistema que disponga de un intérprete Python. El programa se ha probado en Microsoft Windows y en diversos sistemas Unix, pero no dispongo de ningún sistema Apple Macintosh para poder probarlo también en esas máquinas.
BulletProof nació para dar respuesta a la necesidad de poder tener conversaciones absolutamente privadas y confidenciales a través de una infraestructura ajena como puede ser una red de IRC. Administro varios servidores de IRC y sé perfectamente que no se graban conversaciones, pero cuando se está haciendo una entrevista de trabajo, se están discutiendo temas de empresa o ligando :-), y nuestras conversaciones atraviesan decenas de líneas de datos y de máquinas, toda prevención es poca.
He aprovechado mis conocimientos y experiencia en el mundo de la criptografía para crear un producto que garantiza confidencialidad incluso cuando se usan redes "enemigas".
El programa está escrito en Python porque es un lenguaje que me encantó desde el primer momento que lo ví, y me asegura una portabilidad muy simple entre diferentes plataformas. La prueba de ello es que el mismo código BulletProof funciona tanto en máquinas con MS Windows, como en máquinas Unix (incluyendo Linux, Solaris, etc). No he podido probarlo en Macintosh, desgraciadamente.
|
Debemos instalar el Python completo, incluyendo el soporte TCL/TK, si estamos trabajando en Windows.
A partir de la versión 1.118, se soporta "SOCKS 4", "SOCKS 5" y "Proxy HTTP". En las descripciones siguientes, cuando se lea "SOCKS 4" deberá considerarse equivalente en el caso de "SOCKS 5" y "Proxy HTTP".
BulletProof escucha, por defecto, en la IP 127.0.0.1. Esa IP se corresponde con la propia máquina, y se utiliza para permitir conexiones locales, únicamente. Es decir, que sólo podrán utilizar BulletProof aquellos programas que se ejecuten en la propia máquina.
En algunos casos puede interesar que BulletProof admita conexiones exteriores, ya sea para utilizarlo como "bouncer" o para, por ejemplo, dar servicio a toda una red local, sin necesidad de que los usuarios lo instalen en todas las máquinas. En una situación así, es conveniente instalar el programa en una máquina, y configurar BulletProof para que escuche en su IP de la red local, y no en 127.0.0.1. Naturalmente este cambio supone unos riesgos de seguridad (acceso a BulletProof por parte de usuarios no autorizados) que la persona responsable del sistema debe valorar.
BulletProof permite que se le indique la IP en la que escuchar a través de la variable ip_listen. Para cambiar su valor por defecto (127.0.0.1), procedemos de la siguiente manera:
Aparte del soporte SOCKS 4 nativo, estas versiones disponen de capacidades adicionales:
Podemos utilizar BulletProof para que actúe como proxy, conectándonos automáticamente a un servidor de IRC determinado cuando nos conectamos a 127.0.0.1. Ello obliga a configurar BulletProof adecuadamente, y cambiar dicha configuración si deseamos cambiar de servidor.
Para cambiar la configuración por defecto, que nos conecta a IRC hispano a través del puerto 6667 local, hacemos:
Para conectarnos al IRC utilizando esta opción, una vez configurada, sólo tenemos que indicar al cliente de IRC que se conecte a la máquina 127.0.0.1. BulletProof capturará dicha conexión y la enviará automáticamente al servidor IRC que se haya especificado en la configuración (podemos usar la configuración por defecto, como ya se ha dicho). Si hemos configurado un puerto local distinto del estándar (6667), debemos indicar también dicho puerto en la orden de conexión del cliente IRC.
Si nuestro cliente de IRC está dentro de una red que emplea SOCKS 4 para conectarse al servidor de IRC, nuestro cliente tendrá activada ya la configuración SOCKS 4 hacia su pasarela actual, y no podemos instalar BulletProof con la configuración estándar, ya que no sabrá cómo conectarse a Internet.
Si éste es el caso, debemos configurar nuestro cliente de IRC para que emplee BulletProof como proxy SOCKS 4 y configurar BulletProof para que use el proxy SOCKS 4 de la red para salir a Internet.
Para ello, configuramos el cliente de la manera explicada y, a continuación, hacemos:
Si BulletProof entra en conflicto con puertos utilizados en la máquina del cliente IRC, no funcionará correctamente. En casos así, BulletProof permite modificar los puertos utilizados.
El puerto SOCKS 4 por defecto es el 1080. Si dicho puerto es utilizado por otras aplicaciones, hay que cambiarlo. Para ello:
El puerto IRC por defecto es el 6667. Si dicho puerto es utilizado por otras aplicaciones, hay que cambiarlo. Para ello:
BulletProof interactúa con el usuario a través de comandos que se introducen a través del cliente IRC que se esté utilizando.
Los detalles dependen del cliente de IRC concreto, pero lo normal es enviar comandos a BulletProof utilizando el modo "raw". Es decir, si queremos ver la versión de BulletProof que estamos utilizando, podemos hacer "/raw bulletproof version". Todos los comandos siguen el mismo esquema, con el "raw", y el comando "bulletproof".
Los comandos disponibles son:
Nos informa de la versión de BulletProof que estamos empleando.
Ejemplo: "/raw bulletproof version".
Si no se indica ningún objeto, nos proporciona la lista completa de claves. Indicando una serie de objetos, se mostrarán exclusivamente las claves asociadas a los mismos. Esta última funcionalidad está disponible a partir de la versión 1.69.
Las claves no aparecen en ningún orden concreto. En cada línea se muestra la clave empleada y el objeto que estamos protegiendo con ella (un nick o un canal).
Ejemplo: "/raw bulletproof list".
Si una clave está deshabilitada, nos aparecerá el texto "DISABLED" al lado de la clave.
Con este comando ponemos una clave a un objeto determinado. Los objetos pueden ser nicks o canales. La clave en sí puede tener cualquier longitud; más que una palabra, se pueden utilizar frases enteras.
Ejemplo: "/raw bulletproof add #pruebas esto es una prueba".
Eliminamos la clave de un objeto determinado.
Ejemplo: "/raw bulletproof del jcea"
Los mensajes que nos remita el objeto siguen descifrándose, pero los que nosotros le enviemos van en texto claro.
Ejemplo: "/raw bulletproof disable jcea"
Vuelve a activar la clave, tanto para cifrar como para descifrar.
Ejemplo: "/raw bulletproof enable jcea"
El sistema funciona de la siguiente manera:
Vemos si tenemos alguna clave para ese canal, e intenta descifrar el mensaje con ella.
Vemos si tenemos clave para el remitente del mensaje, e intentamos descifrarlo con ella.
Si no tenemos una clave para el objeto en cuestión, o la clave que tenemos no coincide con la clave empleada para cifrar el texto, BulletProof nos mostrará el texto cifrado, tal cual.
Para distinguir entre texto cifrado y texto sin cifrar, se sigue la siguiente convención: el texto no protegido (no cifrado) se imprime "tal cual", mientras que el texto protegido (cifrado) se imprime con un apóstrofe (´) al principio de la línea. Si la clave de descifrado está marcada como deshabilitada, el texto protegido se imprimirá con apóstrofe-asterisco-apóstrofe (´*´).
De esta forma sabemos lo que nos llega protegido y lo que no.
No es mi trabajo hacer scripts, pero pongo un ejemplo para que se vean las posibilidades de integración sencilla con los clientes típicos:
En los "pop-up", añadimos:
- BulletProof: .list: .raw bulletproof list o bien .list: .raw bulletproof list $active .version: .raw bulletproof version .del: .raw bulletproof del $active .add: .raw bulletproof add $active $? .enable: .raw bulletproof enable $active .disable: .raw bulletproof disable $active
Detalles técnicos de funcionamiento
BulletProof utiliza RC4 como mecanismo de cifrado y descifrado. Se eligió ese sistema por ser muy eficiente y seguro, y no incrementar el tamaño del texto cifrado respecto al texto sin cifrar (algo que sí ocurriría si emplease un cifrado de "bloque").
Lamentablemente RC4 es un cifrado en flujo ("stream") y exige que el emisor y el receptor estén perfectamente sincronizados, lo que no es posible en un entorno IRC en el que puede haber split, lag, varios emisores enviando al mismo canal simultaneamente, etc.
El enfoque adoptado consiste en inicializar el sistema RC4 en cada línea transmitida y recibida, para sincronizar el transmisor y el receptor. Ello incrementa ligeramente el tamaño de los datos intercambiados, pero se logra que el sistema funcione sin que el emisor y el receptor tengan que cumplir ninguna restricción en absoluto.
Los detalles de implementación del cifrado son los siguientes:
De esta manera nos aseguramos de que el resultado sea compatible con las redes de IRC actuales.
La expansión que produce esta codificación es del 12.5%, en media.
A la hora de decodificar, procedemos a la inversa:
Si la verificación falla, mostramos el mensaje cifrado original, ya que la clave parece ser incorrecta.
La estructura del paquete de datos, prescindiendo de la codificación para hacerlo transparente al IRC, es la siguiente:
inicialización RC4 verificación
+-----------------------+ +---------+
[aleatorio1] [aleatorio2] [texto original] [aletorio1]
4 bytes 4 bytes n bytes 4 bytes
+-----------------------+ +--------------------------+
no cifrado cifrado
ATENCIÓN:
A partir de la versión 1.71, se incluye una admiración cerrada ("!") al principio de cada línea codificada, a modo de control de versión del programa. Ello permite ampliar en el futuro el programa para que soporte una gran variedad de sistemas de autentificación, cifrado, intercambio de clave, etc.
La codificación y decodificación se realiza exactamente igual que se ha descrito más arriba, salvo por la adición de una admiración cerrada al principio de la línea transmitica, una vez cifrada y codificada.
CLAVE DE LÍNEA
La clave se forma concatenando la clave del usuario y los 64 bits de salt.
Se toma la concatenación de la clave de usuario y los 64 bits de salt. La clave de línea se forma concatenando el hash MD5 y el hash SHA-1 del valor anterior.
Disponible a partir de la versión 1.123, para solucionar un problema de mal uso del RC4.
Esta versión se puede considerar "release candidate" oficial.
Documento también la instalación sobre Mac OS X y sobre OS/2.
La principal novedad de esta versión es el corregir el uso vulnerable de RC4 que estábamos haciendo. Ello supone que que esta versión es incompatible con las anteriores.
Para evitar interrumpir el servicio, lo que hago es que esta versión puede recibir tanto formato antiguo como nuevo, sin problemas. A la hora de enviar, envía en formato antiguo hasta la fecha en la que caduca la versión anterior, y en formato nuevo a partir de ese momento.
Además, me deshago de un problema de licencias. Ahora el código es 100% mío.
Estas dos funcionalidades están documentadas en el fichero config.txt.
ATENCIÓN: El uso de esta característica supone unos riesgos de seguridad que deben valorarse antes de utilizarla de forma activa.
A la hora de dividir el texto en dos, intenta cortar por un espacio, si es posible.
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
