El código de los clientes de Telegram se
agregó con la capacidad de disfrazarse como HTTPS (TLS + HTTP / 2.0).
Para usar esta función, agregaron un nuevo prefijo secreto:
"ee" . Además, agregaron la capacidad de codificar un secreto en la dirección del servidor proxy como base64, además de hexadecimal.
Antes de profundizar en los detalles, intentemos descubrir cómo se desarrolló el soporte de los servidores proxy en Telegram.
Antecedentes
- Telegram inicialmente apoyó los servidores proxy SOCKS. Esto ayudó a evitar el bloqueo del servidor IP, pero el protocolo se notó en el tráfico y la contraseña se transmitió en texto claro.
- Hace aproximadamente un año, lanzaron un proxy oficial que trabajaba en el nuevo protocolo MTProto. A diferencia de SOCKS, la contraseña en MTProto no se transmitió en texto claro. En el protocolo, se deshicieron de cualquier encabezado de servicio por el cual uno pudiera entender que realmente era él. También agregamos la posibilidad de mostrar anuncios a los usuarios del servidor proxy
- Resultó que los proxies que ejecutan el protocolo MTProto pueden ser detectados por la longitud de los paquetes. Cuando se establece una conexión, el cliente y el servidor proxy intercambian paquetes de cierta longitud y, durante la operación, paquetes del mismo módulo de longitud 4. Esta función comenzó a ser utilizada por grandes proveedores para bloquear el mensajero. Los desarrolladores de Telegram reaccionaron modificando el protocolo agregando una cantidad de bytes aleatorios a cada paquete. Dado que el cambio rompió la compatibilidad, tuve que complementar el formato secreto con el prefijo especial "dd", lo que significa usar un protocolo modificado:
tg://proxy?server=178.62.232.110&port=3256&secret=dd00000000000000000000000000000000 - Al estudiar las características del bloqueo del servidor proxy en China e Irán, resultó que los supervisores usan ataques de repetición para la detección. En implementaciones alternativas de servidores proxy en Python, Erlang y Go, ha aparecido una protección parcial contra este tipo de ataque. Para esto, los servidores proxy almacenan los datos transmitidos en la etapa inicial de establecer una conexión y no permiten reconectarse con los mismos datos. El enfoque tiene un problema con los servidores proxy grandes, ya que la memoria requiere una gran cantidad de RAM
- En China e Irán, se utilizan las siguientes tácticas: si se desconoce el protocolo, por si acaso, la velocidad de su trabajo se ve severamente reducida. En la práctica, esto significa la posibilidad de usar Telegram solo para enviar mensajes de texto, sin imágenes ni videos. Y en China supieron cómo hacerlo durante mucho tiempo, pero en Irán lo aprendieron hace relativamente poco. Rusia aún no ha aprendido, pero la ley ya ha sido aprobada . Un intento de los desarrolladores de mensajería para enmascarar el tráfico bajo algún protocolo popular en este contexto parece natural.
¿Qué ha cambiado?
En el protocolo entre el cliente Telegram y el servidor proxy, se agregó otra capa de encapsulación sobre TCP. En lugar de enviar datos a través de TCP, los datos se envuelven en las siguientes entradas de TLS:
Al comienzo del trabajo, se agregó la fase de emulación de apretón de manos TLS. El paquete del cliente al servidor proxy tiene la siguiente estructura:
Casi todos los campos no tienen sentido para los clientes de Telegram y solo son necesarios para pretender ser TLS. La función más importante la lleva el campo
Aleatorio , donde el resultado
HMAC del secreto compartido y los datos en el paquete se colocan, lo que permite al cliente demostrar que conoce el secreto. Además, el cliente altera los últimos 4 bytes del campo Aleatorio con su tiempo en formato unixtime, lo que permite al servidor proxy determinar cuándo se generó el paquete. Esto es útil para protegerse contra ataques de repetición. Si el paquete se generó hace mucho tiempo o en el futuro, el servidor proxy puede descartarlo de inmediato.
Cuando un cliente se conecta, el servidor proxy verifica el HMAC transmitido. Si coincide con el calculado, el proxy responde con un paquete con la siguiente estructura:
El campo
Aleatorio en él tampoco es aleatorio, sino que es el resultado del HMAC del secreto compartido y los datos en el paquete, y al calcular el HMAC, el valor aleatorio enviado por el cliente se asigna antes que los datos del paquete en sí. Al transmitir los datos en sí, el cliente ignora el primer mensaje, lo que le permite enviarle datos de una longitud aleatoria para complicar aún más la detección.
Donde probar
Para la demostración, el
servidor proxy en Python fue modificado y elevado, al que puede conectarse al último cliente de escritorio Telegram y ver el tráfico transmitido usando Wireshark:
tg://proxy?server=178.62.232.110&port=3256&secret=7gAAAAAAAAAAAAAAAAAAAABnb29nbGUuY29t
Además, el soporte de enmascaramiento TLS se ha agregado
al servidor proxy Erlang . Lo más probable es que, en un futuro próximo, esta funcionalidad se agregue a otras implementaciones de servidores proxy.