Introduccion
Los modernos sistemas de filtrado de contenido corporativo de fabricantes tan eminentes como Cisco, BlueCoat y FireEye tienen mucho en común con sus contrapartes más potentes: sistemas DPI que se están implementando intensamente a nivel nacional. La esencia del trabajo de ambos es buscar el tráfico de Internet entrante y saliente y, sobre la base de listas en blanco y negro, tomar la decisión de prohibir la conexión a Internet. Y dado que ambos se basan en principios similares en los fundamentos de su trabajo, las formas de eludirlos también tendrán mucho en común.
Una de las tecnologías que permite evitar de manera bastante eficiente tanto el DPI como los sistemas corporativos es la tecnología de dominio frontal. Su esencia radica en el hecho de que vamos a un recurso bloqueado, escondiéndonos detrás de otro dominio público, con una buena reputación, que obviamente no será bloqueado por ningún sistema, por ejemplo google.com.
Ya se han escrito muchos artículos sobre esta tecnología y se han dado muchos ejemplos. Sin embargo, las tecnologías DNS sobre HTTPS y SNI cifrado, así como las tecnologías discutidas recientemente, así como la nueva versión del protocolo TLS 1.3, brindan la oportunidad de considerar otra variante del dominio frontal.
Nos ocupamos de la tecnología.
Primero, decidamos un poco sobre los conceptos básicos para que todos comprendan quién es quién y por qué se necesita todo esto. Mencionamos el mecanismo eSNI, cuyo trabajo se discutirá más adelante. El mecanismo eSNI (Indicación de nombre de servidor encriptado) es una versión segura de SNI, disponible solo para el protocolo TLS 1.3. El punto principal es cifrar, incluida la información sobre a qué dominio se envía la solicitud.
Ahora veamos cómo funciona el mecanismo eSNI en la práctica.
Supongamos que tenemos un recurso de Internet que está bloqueado por una solución DPI moderna (tome, por ejemplo, el famoso rastreador de torrents - rutracker.nl). Cuando intentamos acceder al sitio del rastreador de torrents, vemos el código auxiliar estándar del proveedor de que el recurso está bloqueado:
En el sitio web de ILV, este dominio aparece en la lista de paradas:
Cuando solicita whois, puede ver que el dominio en sí está "oculto" detrás del proveedor de la nube Cloudflare.
Pero a diferencia de los "especialistas" de ILV, los empleados más expertos en tecnología (o enseñados por la amarga experiencia de nuestro famoso regulador) no prohibieron estúpidamente el sitio por dirección IP, sino que ingresaron el nombre de dominio en la lista de parada. Esto es fácil de verificar si observa qué otros dominios se esconden detrás de la misma dirección IP, visite uno de ellos y vea que el acceso no está bloqueado:
¿Pero cómo sucede? ¿Cómo descubre el proveedor de DPI a qué dominios va mi navegador, porque todas las comunicaciones se realizan a través del protocolo https y parece que todavía no notamos la sustitución de certificados https desde la línea de acceso? ¿Es clarividente o me está siguiendo?
Intentemos responder esta pregunta observando el tráfico a través de wireshark
La captura de pantalla muestra que primero el navegador recibe la dirección IP del servidor a través de DNS, luego hay un protocolo de enlace TCP estándar con el servidor de destino y luego el navegador intenta establecer una conexión SSL al servidor. Para hacer esto, envía el paquete Hello Client SSL, que contiene el nombre del dominio de origen en texto claro. Este campo es requerido por el servidor front-end cloudflare para enrutar correctamente la conexión. Aquí es donde el proveedor DPI nos atrapa, rompiendo nuestra conexión. Al mismo tiempo, no recibimos ningún código auxiliar del proveedor, y vemos un error estándar del navegador como si el sitio estuviera desconectado o simplemente no funciona:
Ahora habilitemos el mecanismo eSNI en el navegador, como se describe en las instrucciones para
Firefox :
Para hacer esto, abrimos la página de configuración de Firefox
sobre: config y activamos la siguiente configuración:
network.trr.mode = 2; network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query network.security.esni.enabled = true
Después de eso, verificaremos la corrección de la configuración en el sitio web de Cloudflare usando el
enlace e intentaremos enfocar nuevamente con nuestro rastreador de torrents.
Voila Nuestro rastreador favorito se abrió sin ninguna VPN o proxy. Veamos ahora el vertedero de tráfico en Wirehark, lo que sucedió.
Esta vez, el paquete hello del cliente SSL no contiene explícitamente el dominio de destino, sino que apareció un nuevo campo en el paquete - encrypted_server_name - aquí es donde está contenido el valor de rutracker.nl, y solo el servidor front-end cloudflare puede descifrar este campo. Y si es así, el proveedor DPI no tiene más remedio que lavarse las manos y permitir ese tráfico. Pero no hay otras opciones con cifrado.
Entonces, ¿cómo funciona la tecnología en el navegador? Ahora intentemos aplicarlo para cosas más específicas e interesantes. Y para empezar, enseñaremos el mismo curl para usar eSNI para trabajar con TLS 1.3, y al mismo tiempo veremos cómo funciona el dominio front-end basado en eSNI.
Dominio Front End con eSNI
Debido al hecho de que curl usa la biblioteca estándar de openssl para conectarse a través de https, en primer lugar, debemos proporcionar soporte eSNI allí. Todavía no hay soporte para eSNI en las ramas maestras de openssl, por lo que debemos descargar la rama especial de openssl, compilarla e instalarla.
Clonamos el repositorio del github y compilamos como de costumbre:
$ git clone https://github.com/sftcd/openssl $ cd openssl $ ./config $ make $ cd esnistuff $ make
A continuación, clonamos el repositorio con curl y configuramos su compilación utilizando nuestra biblioteca openssl ensamblada:
$ cd $HOME/code $ git clone https://github.com/niallor/curl.git curl-esni $ cd curl-esni $ export LD_LIBRARY_PATH=/opt/openssl $ ./buildconf $ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug
Es importante indicar correctamente todos los directorios donde se encuentra openssl (en nuestro caso, es / opt / openssl /) y asegurarse de que el proceso de configuración no tenga errores.
En caso de configuración exitosa, veremos la línea:
ADVERTENCIA: esni ESNI habilitado pero marcado EXPERIMENTAL. ¡Usar con precaución! $ make
Después de compilar con éxito el paquete, utilizaremos un archivo bash openssl especial para configurar y ejecutar curl. Cópielo al directorio con curl por conveniencia:
cp /opt/openssl/esnistuff/curl-esni
y ejecute una solicitud https de prueba al servidor cloudflare, mientras escribe simultáneamente paquetes DNS y TLS en Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/
En la respuesta del servidor, además de mucha información de depuración de openssl y curl, obtenemos una respuesta HTTP con el código 301 de cloudflare.
HTTP/1.1 301 Moved Permanently < Date: Sun, 03 Nov 2019 13:12:55 GMT < Transfer-Encoding: chunked < Connection: keep-alive < Cache-Control: max-age=3600 < Expires: Sun, 03 Nov 2019 14:12:55 GMT < Location: https://www.cloudflare.com/
lo que indica que nuestra solicitud fue entregada con éxito al servidor de destino, escuchada y procesada.
Ahora echemos un vistazo al vertedero de tráfico en wireshark, es decir lo que vio el proveedor DPI en este caso.
Se puede ver que el primer rizo se dirigió al servidor DNS para obtener la clave pública eSNI para el servidor cloudflare: solicitud DNS TXT a _esni.cloudflare.com (paquete No. 13). Luego, utilizando la biblioteca openssl, curl envió una solicitud TLS 1.3 al servidor cloudflare en el que el campo SNI se cifró con la clave pública obtenida en el paso anterior (paquete No. 22).
Pero, además del campo eSNI, como parte del paquete SSL-hello, también se insertó un campo con el SNI abierto habitual, que podemos especificar en cualquier orden (en este caso, www.hello-rkn.ru ).Este campo del SNI abierto no se tuvo en cuenta al procesar en servidores cloudflare y fue solo un disfraz para el DPI del proveedor. El servidor cloudflare recibió nuestro paquete ssl-hello, descifró el eSNI, extrajo el SNI original de allí y lo procesó como si nada hubiera pasado (hizo todo exactamente como estaba planeado durante el desarrollo del eSNI).
Lo único en este caso es que puede aferrarse en términos de DPI, la consulta DNS principal en _esni.cloudflare.com. Pero abrimos la consulta DNS solo para mostrar cómo funciona este mecanismo desde adentro.
Para finalmente eliminar el suelo de debajo del DPI, utilizamos el mecanismo de DNS sobre HTTPS ya mencionado. Una pequeña explicación, DOH, un protocolo que te permite protegerte de un hombre en medio del ataque enviando una consulta DNS a través de HTTPS.
Volveremos a ejecutar la solicitud, pero esta vez obtendremos las claves públicas eSNI utilizando el protocolo https, no el DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/
El volcado de tráfico de solicitud se presenta en la siguiente captura de pantalla:
Se ve que el primer curl accede al servidor mozilla.cloudflare-dns.com usando el protocolo DoH (conexión https al servidor 104.16.249.249) para obtener valores de clave pública para el cifrado SNI de ellos, y luego al servidor de destino, escondiéndose bajo el dominio
www.hello-rkn.ru .
Además del Mozilla.cloudflare-dns.com resolver DoH especificado anteriormente, podemos utilizar otros servicios DoH populares, por ejemplo, de la famosa corporación malvada.
Ejecutamos la siguiente solicitud:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/
Y obtenemos la respuesta:
< HTTP/1.1 301 Moved Permanently < Date: Sun, 03 Nov 2019 14:10:22 GMT < Content-Type: text/html < Transfer-Encoding: chunked < Connection: keep-alive < Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure < Location: https://rutracker.nl/forum/index.php < CF-Cache-Status: DYNAMIC < Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" < Server: cloudflare < CF-RAY: 52feee696f42d891-CPH
En este caso, recurrimos al servidor bloqueado rutracker.nl, usando el dns.google DoH resolver (no hay error tipográfico, ahora la famosa corporación tiene su propio dominio de primer nivel) y nos cubrimos con otro dominio, que está estrictamente prohibido por todos los DPI para bloquear por miedo a la pena de muerte. Según la respuesta, puede comprender que nuestra solicitud se procesó con éxito.
Como verificación adicional de que el DPI del proveedor responde a un SNI abierto, que pasamos como una cubierta, podemos ejecutar una solicitud a rutracker.nl detrás de algún otro recurso prohibido, por ejemplo, otro rastreador de torrents "bueno":
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/
No recibiremos una respuesta del servidor, ya que nuestra solicitud será bloqueada por el sistema DPI.
Una pequeña conclusión a la primera parte.
Entonces, pudimos mostrar la salud de eSNI usando openssl y curl y probar el funcionamiento del front-end basado en dominio basado en eSNI. Del mismo modo, podemos adaptar nuestras herramientas favoritas utilizando la biblioteca openssl para trabajar "bajo cubierta" de otros dominios. Más sobre esto en nuestros próximos artículos.