Empezamos por ‘el rey’:
MSN / Messenger
Sin duda el protocolo mas empleado y con mas cuota de usuarios en España. El protocolo MSN no es un protocolo estático, va mutando periódicamente y Microsoft va sacando actualizaciones en las que varia ligeramente su funcionamiento. Dado que sus internals no son públicos, toca ‘reversear’ y deducir como funciona. A día de hoy la última especificación de la que se cuenta con información es esta y la parte que mas nos interesa es la que concierne a como se realiza la autenticación.
A grosso modo:
- El cliente lanza la petición de login al servidor MSN,
- El servidor MSN facilita un ‘reto’ (un montón de caracteres aleatorios para generar entropía) y un servidor ‘de tickets’
- El cliente envía el Login + Password + Reto mediante una conexión SSL al servidor de tickets y, en caso de ser válida, obtiene un ticket
- El cliente envía ese ticket al servidor MSN
Una vez completada esta secuencia, el resto de la comunicación se realiza en texto plano sin codificación alguna
Gtalk (cliente oficial)
Como es bien sabido, Google para implementar su sistema de mensajería se ha decidido por una implementación basada en XMPP / Jabber. El problema es que Jabber aun siendo un protocolo estandarizado admite mil y una forma de hacer las cosas (algunas mas seguras, otras mas inseguras). En concreto, Google en su implementación ofrece como formas de hacer auth dos posibilidades, una llamada Google-Token (totalmente fuera de especificación y propietaria de Google) y otra basada en TLS. El cliente oficial, como es lógico, emplea Google-Token y ciertamente debilita mucho la seguridad del sistema. Funciona de la siguiente manera:
- El cliente se conecta vía SSL a Google para hacer el auth
- Google entrega un token al cliente
- El cliente usa ese token como método de autenticación
Terminada esta fase, el resto de la comunicación va en texto plano
Gtalk (clientes XMPP / Jabber alternativos)
Si obviamos el cliente oficial de Google y nos decantamos por alternativas como Gajim o Pidgin (necesario si empleas una plataforma como Linux), la cosa cambia radicalmente. El método empleado está completamente basado en TLS.
- El cliente inicia la comunicación con el servidor XMPP
- Se negocia un túnel TLS
- Se envían las credenciales
A partir de ahí toda la comunicación va cifrada
Facebook
Recientemente Facebook ha abierto su chat públicamente mediante una plataforma basada en XMPP / Jabber. Como ya decía anteriormente, las formas en las que se puede hacer auth en XMPP son increíblemente versátiles. En el caso de Facebook han optado por un método basado en Digest SASL. SASL es un protocolo ampliamente utilizado para autenticación en servicios como IMAP o SMTP. Para hacerlo aun mas divertido, SASL soporta tres modos de autenticación en función de la seguridad que se quiera aplicar. El primero llamado ‘auth’ únicamente sirve para intercambiar credenciales de forma segura basado en retos, el servidor genera una cadena aleatoria y el cliente debe responder con un hash de sus credenciales + el reto. El segundo modo ‘auth-int’ añade una capa de integridad añadiendo a cada intercambio un ‘código de integridad’ empleando HMAC. El tercero, ‘auth-conf’ añade a todo eso una capa de cifrado. ¿Cual método ha elegido Facebook? auth normal.
Después de eso la conversación continua en texto plano
Conclusiones
Una vez explicado como funciona cada protocolo, a modo resumen una tabla con los riesgos potenciales que podemos sufrir si una sesión de chat es interceptada.
Los criterios de evaluación han sido
[ ] Crackeable: La posibilidad de que un atacante que capture la autenticación pueda aplicar fuerza bruta sobre lo interceptado para averiguar la contraseña
[ ] Usuario deducible: Se evalúa si durante la fase de autenticación un atacante podría averiguar el login / dirección de correo ej: [email protected]
[ ] Sniffing conversación: El hecho de que los mensajes de chat intercambiados sean susceptibles de leerse en texto plano
** En el caso de Gtalk solo se contempla en formato ‘cliente alternativo’
