Introdución
Os modernos sistemas de filtrado de contido corporativo de fabricantes tan recoñecidos como Cisco, BlueCoat, FireEye teñen moito en común cos seus homólogos máis potentes: os sistemas DPI, que se están implementando activamente a nivel nacional. A esencia do traballo de ambos é inspeccionar o tráfico de Internet entrante e saínte e, baseándose en listas brancas/negras, tomar a decisión de prohibir a conexión a Internet. E dado que ambos se basean en principios similares nos conceptos básicos do seu traballo, os métodos para evitalos tamén terán moito en común.
Unha das tecnoloxías que che permiten evitar de forma bastante efectiva tanto os sistemas DPI como os corporativos é a tecnoloxía de dominio. A súa esencia é que imos a un recurso bloqueado, escondido detrás doutro, de dominio público con boa reputación, que obviamente non será bloqueado por ningún sistema, por exemplo google.com.
Xa se escribiron bastantes artigos sobre esta tecnoloxía e deron moitos exemplos. Non obstante, as populares e recentemente discutidas tecnoloxías DNS sobre HTTPS e SNI cifrado, así como a nova versión do protocolo TLS 1.3, permiten considerar outra opción para o fronting de dominio.
Comprensión da tecnoloxía
En primeiro lugar, imos definir un pouco os conceptos básicos para que todos teñan unha comprensión de quen é quen e por que é necesario todo isto. Mencionamos o mecanismo eSNI, cuxo funcionamento se comentará máis adiante. O mecanismo eSNI (encrypted Server Name Indication) é unha versión segura de SNI, dispoñible só para o protocolo TLS 1.3. A idea principal é cifrar, entre outras cousas, a información sobre a que dominio se envía a solicitude.
Agora vexamos como funciona o mecanismo eSNI na práctica.
Digamos que temos un recurso de Internet que está bloqueado por unha solución DPI moderna (poñamos, por exemplo, o famoso rastreador de torrents rutracker.nl). Cando tentamos acceder ao sitio web dun rastreador de torrent, vemos o código estándar do provedor que indica que o recurso está bloqueado:
No sitio web de RKN este dominio aparece realmente nas listas de paradas:
Cando consultas whois, podes ver que o propio dominio está "oculto" detrás do provedor de nube Cloudflare.
Pero a diferenza dos "especialistas" de RKN, os empregados máis expertos tecnicamente de Beeline (ou ensinados pola amarga experiencia do noso famoso regulador) non prohibiron estúpidamente o sitio por enderezo IP, senón que engadiron o nome de dominio á lista de paradas. Podes verificalo facilmente se miras que outros dominios se agochan detrás do mesmo enderezo IP, visitas un deles e observas que o acceso non está bloqueado:
Como ocorre isto? Como sabe o DPI do provedor en que dominio está o meu navegador, xa que todas as comunicacións se realizan a través do protocolo https e aínda non notamos a substitución dos certificados https de Beeline? ¿É clarividente ou me seguen?
Tentemos responder a esta pregunta mirando o tráfico a través de wireshark
A captura de pantalla mostra que primeiro o navegador obtén o enderezo IP do servidor a través de DNS, despois prodúcese un enlace TCP estándar co servidor de destino e, a continuación, o navegador tenta establecer unha conexión SSL co servidor. Para iso, envía un paquete SSL Client Hello, que contén o nome do dominio de orixe en texto claro. Este campo é necesario polo servidor frontend de cloudflare para enrutar correctamente a conexión. Aquí é onde nos atrapa o provedor DPI, rompendo a nosa conexión. Ao mesmo tempo, non recibimos ningún esbozo do provedor e vemos o erro estándar do navegador como se o sitio estivese desactivado ou simplemente non funcionase:
Agora imos habilitar o mecanismo eSNI no navegador, tal e como está escrito nas instrucións para :
Para iso abrimos a páxina de configuración de Firefox sobre: config e activa os seguintes axustes:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Despois diso, comprobaremos que a configuración funciona correctamente no sitio web de cloudflare. e volvamos a probar o truco co noso rastreador de torrents.
Voila. O noso rastreador favorito abriuse sen VPN nin servidores proxy. Vexamos agora o vertedoiro de tráfico en Wireshark para ver que pasou.
Esta vez, o paquete ola do cliente ssl non contén explícitamente o dominio de destino, senón que apareceu un novo campo no paquete - encrypted_server_name - aquí é onde se contén o valor de rutracker.nl e só o servidor frontend de cloudflare pode descifrar isto. campo. E se é así, entón o provedor DPI non ten máis remedio que lavarse as mans e permitir ese tráfico. Non hai outras opcións co cifrado.
Entón, miramos como funciona a tecnoloxía no navegador. Agora intentemos aplicalo a cousas máis específicas e interesantes. E primeiro, ensinarémoslle ao mesmo curl a usar eSNI para traballar con TLS 1.3 e, ao mesmo tempo, veremos como funciona o propio dominio baseado en eSNI.
Fronte de dominio con eSNI
Debido ao feito de que curl usa a biblioteca estándar openssl para conectarse mediante o protocolo https, primeiro necesitamos proporcionar soporte eSNI alí. Aínda non hai soporte eSNI nas ramas mestras de openssl, polo que necesitamos descargar unha rama especial de openssl, compilala e instalala.
Clonamos o repositorio desde GitHub e compilamos como sempre:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
A continuación, clonamos o repositorio con curl e configuramos a súa compilación usando a nosa biblioteca openssl compilada:
$ 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
Aquí é importante especificar correctamente todos os directorios onde se atopa openssl (no noso caso, este é /opt/openssl/) e asegurarse de que o proceso de configuración transcorre sen erros.
Se a configuración é correcta, veremos a liña:
AVISO: esni ESNI habilitado pero marcado como EXPERIMENTAL. Use con precaución!
$ makeDespois de construír o paquete con éxito, usaremos un ficheiro bash especial de openssl para configurar e executar curl. Copiamos no directorio con curl para maior comodidade:
cp /opt/openssl/esnistuff/curl-esni e fai unha solicitude https de proba ao servidor cloudflare, mentres grava simultáneamente paquetes DNS e TLS en Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Na resposta do servidor, ademais de moita información de depuración de openssl e curl, recibiremos unha resposta HTTP co 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/
o que indica que a nosa solicitude foi entregada correctamente ao servidor de destino, escoitada e procesada.
Agora vexamos o vertedoiro de tráfico en wireshark, é dicir. o que o provedor DPI viu neste caso.
Pódese ver que curl recorreu primeiro ao servidor DNS para obter unha clave eSNI pública para o servidor cloudflare: unha solicitude de DNS TXT a _esni.cloudflare.com (paquete número 13). Despois, usando a biblioteca openssl, curl enviou unha solicitude TLS 1.3 ao servidor cloudflare no que se cifraba o campo SNI coa clave pública obtida no paso anterior (paquete #22). Pero, ademais do campo eSNI, o paquete SSL-hello tamén incluía un campo co habitual - open SNI, que podemos especificar en calquera orde (neste caso - ).
Este campo SNI aberto non se tivo en conta de ningún xeito cando o procesaron os servidores cloudflare e só serviu como máscara para o DPI do provedor. O servidor cloudflare recibiu o noso paquete ssl-hello, descifrou o eSNI, extraeu o SNI orixinal de alí e procesouno coma se nada pasase (fixo todo exactamente como estaba previsto ao desenvolver eSNI).
O único que se pode captar neste caso desde o punto de vista de DPI é a solicitude de DNS principal a _esni.cloudflare.com. Pero fixemos a solicitude de DNS aberta só para mostrar como funciona este mecanismo desde dentro.
Para finalmente sacar a alfombra de baixo DPI, usamos o mecanismo DNS sobre HTTPS xa mencionado. Unha pequena explicación: DOH é un protocolo que che permite protexerte contra un ataque de man-in-the-middle enviando unha solicitude DNS a través de HTTPS.
Imos executar a solicitude de novo, pero esta vez recibiremos claves eSNI públicas a través do protocolo https, non DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/O volcado de tráfico da solicitude móstrase na seguinte captura de pantalla:
Pódese ver que curl accede primeiro ao servidor mozilla.cloudflare-dns.com a través do protocolo DoH (conexión https ao servidor 104.16.249.249) para obter deles os valores das claves públicas para o cifrado SNI, e despois ao destino. servidor, escondido detrás do dominio .
Ademais da resolución de DoH anterior mozilla.cloudflare-dns.com, podemos usar outros servizos de DoH populares, por exemplo, da famosa corporación malvada.
Imos executar a seguinte consulta:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/E obtemos a resposta:
< 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
Neste caso, recorremos ao servidor rutracker.nl bloqueado, utilizando o resolvedor DoH dns.google (aquí non hai erros de ortografía, agora a famosa corporación ten o seu propio dominio de primeiro nivel) e cubrimos con outro dominio, que é estrictamente prohibido para todos os DPI bloquear baixo pena de morte. Segundo a resposta recibida, pode entender que a nosa solicitude foi procesada correctamente.
Como verificación adicional de que o DPI do provedor responde ao SNI aberto, que transmitimos como tapa, podemos facer unha solicitude a rutracker.nl baixo o pretexto dalgún outro recurso prohibido, por exemplo, outro rastreador de torrent "bo":
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Non recibiremos resposta do servidor porque... a nosa solicitude será bloqueada polo sistema DPI.
Unha pequena conclusión á primeira parte
Así, puidemos demostrar a funcionalidade de eSNI usando openssl e curl e probar o funcionamento do fronting de dominio baseado en eSNI. Do mesmo xeito, podemos adaptar as nosas ferramentas favoritas que usan a biblioteca openssl para que funcionen "baixo a aparencia" doutros dominios. Máis detalles sobre isto nos próximos artigos.
Fonte: www.habr.com