Frontage de domaine basé sur TLS 1.3

introduction

Les systèmes modernes de filtrage de contenu d'entreprise de fabricants renommés tels que Cisco, BlueCoat, FireEye ont beaucoup en commun avec leurs homologues plus puissants - les systèmes DPI, qui sont activement mis en œuvre au niveau national. L'essence du travail des deux consiste à inspecter le trafic Internet entrant et sortant et, sur la base de listes noires/blanches, à prendre la décision d'interdire la connexion Internet. Et comme les deux s’appuient sur des principes similaires dans les bases de leur travail, les méthodes permettant de les contourner auront également beaucoup en commun.

L'une des technologies qui vous permet de contourner assez efficacement à la fois le DPI et les systèmes d'entreprise est la technologie de front de domaine. Son essence est que nous accédons à une ressource bloquée, en nous cachant derrière un autre domaine public de bonne réputation, qui ne sera évidemment bloqué par aucun système, par exemple google.com.

De nombreux articles ont déjà été écrits sur cette technologie et de nombreux exemples ont été donnés. Cependant, les technologies DNS-over-HTTPS et cryptées-SNI populaires et récemment discutées, ainsi que la nouvelle version du protocole TLS 1.3, permettent d'envisager une autre option pour le domain fronting.

Comprendre la technologie

Tout d'abord, définissons quelques concepts de base afin que chacun comprenne qui est qui et pourquoi tout cela est nécessaire. Nous avons évoqué le mécanisme eSNI, dont le fonctionnement sera discuté plus loin. Le mécanisme eSNI (encrypted Server Name Indication) est une version sécurisée de SNI, disponible uniquement pour le protocole TLS 1.3. L'idée principale est de chiffrer, entre autres, les informations sur le domaine auquel la demande est envoyée.

Voyons maintenant comment fonctionne le mécanisme eSNI dans la pratique.

Disons que nous avons une ressource Internet bloquée par une solution DPI moderne (prenons, par exemple, le célèbre tracker torrent rutracker.nl). Lorsque nous essayons d’accéder au site Web d’un tracker torrent, nous voyons le stub standard du fournisseur indiquant que la ressource est bloquée :

Sur le site RKN, ce domaine est en fait répertorié dans les listes d'arrêt :

Lorsque vous interrogez whois, vous pouvez voir que le domaine lui-même est « caché » derrière le fournisseur de cloud Cloudflare.

Mais contrairement aux «spécialistes» de RKN, des employés plus avertis techniquement de Beeline (ou instruits par l'amère expérience de notre célèbre régulateur) n'ont pas bêtement interdit le site par adresse IP, mais ont ajouté le nom de domaine à la liste d'arrêt. Vous pouvez facilement le vérifier si vous regardez quels autres domaines sont cachés derrière la même adresse IP, visitez l'un d'eux et voyez que l'accès n'est pas bloqué :

Comment cela peut-il arriver? Comment le DPI du fournisseur sait-il sur quel domaine se trouve mon navigateur, puisque toutes les communications se font via le protocole https et que nous n'avons pas encore remarqué la substitution des certificats https de Beeline ? Est-il clairvoyant ou est-ce que je suis suivi ?

Essayons de répondre à cette question en examinant le trafic via WireShark.

La capture d'écran montre que le navigateur obtient d'abord l'adresse IP du serveur via DNS, puis une négociation TCP standard se produit avec le serveur de destination, puis le navigateur tente d'établir une connexion SSL avec le serveur. Pour ce faire, il envoie un paquet SSL Client Hello, qui contient le nom du domaine source en texte clair. Ce champ est requis par le serveur frontal cloudflare afin d'acheminer correctement la connexion. C'est là que le fournisseur DPI nous surprend, rompant notre connexion. Dans le même temps, nous ne recevons aucun stub du fournisseur, et nous voyons l'erreur standard du navigateur comme si le site était désactivé ou ne fonctionnait tout simplement pas :

Activons maintenant le mécanisme eSNI dans le navigateur, comme indiqué dans les instructions pour Firefox :
Pour ce faire, nous ouvrons la page de configuration de Firefox about: config et activez les paramètres suivants :

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

Après cela, nous vérifierons que les paramètres fonctionnent correctement sur le site cloudflare. lien et essayons à nouveau l'astuce avec notre tracker torrent.

Voilà. Notre tracker préféré s'est ouvert sans VPN ni serveur proxy. Examinons maintenant le vidage du trafic dans Wireshark pour voir ce qui s'est passé.

Cette fois, le package hello du client SSL ne contient pas explicitement le domaine de destination, mais à la place, un nouveau champ est apparu dans le package - approved_server_name - c'est là que la valeur de rutracker.nl est contenue, et seul le serveur frontal cloudflare peut le déchiffrer. champ. Et si tel est le cas, le fournisseur DPI n’a d’autre choix que de se laver les mains et d’autoriser un tel trafic. Il n'y a pas d'autres options de cryptage.

Nous avons donc examiné le fonctionnement de la technologie dans le navigateur. Essayons maintenant de l'appliquer à des choses plus spécifiques et intéressantes. Et d'abord, nous apprendrons au même curl à utiliser eSNI pour travailler avec TLS 1.3, et en même temps nous verrons comment fonctionne le domaine fronting basé sur eSNI lui-même.

Fronting de domaine avec eSNI

Étant donné que curl utilise la bibliothèque openssl standard pour se connecter via le protocole https, nous devons tout d'abord y fournir le support eSNI. Il n'y a pas encore de support eSNI dans les branches principales openssl, nous devons donc télécharger une branche openssl spéciale, la compiler et l'installer.

Nous clonons le référentiel depuis GitHub et compilons comme d'habitude :

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

Ensuite, nous clonons le référentiel avec curl et configurons sa compilation à l'aide de notre bibliothèque openssl compilée :

$ 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

Ici, il est important de spécifier correctement tous les répertoires où se trouve openssl (dans notre cas, il s'agit de /opt/openssl/) et de s'assurer que le processus de configuration se déroule sans erreur.

Si la configuration réussit, nous verrons la ligne :

AVERTISSEMENT : esni ESNI activé mais marqué EXPERIMENTAL. Utiliser avec précaution!

$ make

Après avoir construit avec succès le package, nous utiliserons un fichier bash spécial d'openssl pour configurer et exécuter curl. Copions-le dans le répertoire avec curl pour plus de commodité :

cp /opt/openssl/esnistuff/curl-esni 

et effectuez une requête https de test au serveur cloudflare, tout en enregistrant simultanément les paquets DNS et TLS dans Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

Dans la réponse du serveur, en plus de nombreuses informations de débogage d'openssl et curl, nous recevrons une réponse HTTP avec le code 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/

ce qui indique que notre demande a été transmise avec succès au serveur de destination, entendue et traitée.

Regardons maintenant le vidage du trafic dans Wireshark, c'est-à-dire ce que le fournisseur DPI a vu dans ce cas.

On peut voir que curl s'est d'abord tourné vers le serveur DNS pour obtenir une clé eSNI publique pour le serveur cloudflare - une requête DNS TXT à _esni.cloudflare.com (paquet n° 13). Ensuite, à l'aide de la bibliothèque openssl, curl a envoyé une requête TLS 1.3 au serveur cloudflare dans laquelle le champ SNI a été chiffré avec la clé publique obtenue à l'étape précédente (paquet n°22). Mais, en plus du champ eSNI, le paquet SSL-hello comprenait également un champ avec le SNI ouvert habituel, que nous pouvons spécifier dans n'importe quel ordre (dans ce cas - www.hello-rkn.ru).

Ce champ SNI ouvert n'était en aucun cas pris en compte lors du traitement par les serveurs cloudflare et servait uniquement de masque au fournisseur DPI. Le serveur cloudflare a reçu notre paquet SSL-hello, a déchiffré l'eSNI, en a extrait le SNI d'origine et l'a traité comme si de rien n'était (il a tout fait exactement comme prévu lors du développement de l'eSNI).

La seule chose qui peut être détectée dans ce cas du point de vue DPI est la requête DNS principale adressée à _esni.cloudflare.com. Mais nous avons ouvert la requête DNS uniquement pour montrer comment ce mécanisme fonctionne de l’intérieur.

Pour enfin couper l'herbe sous le pied du DPI, nous utilisons le mécanisme DNS-over-HTTPS déjà mentionné. Une petite explication - DOH est un protocole qui vous permet de vous protéger contre une attaque de l'homme du milieu en envoyant une requête DNS via HTTPS.

Exécutons à nouveau la requête, mais cette fois nous recevrons les clés publiques eSNI via le protocole https, pas DNS :

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

Le vidage du trafic de la demande est illustré dans la capture d'écran ci-dessous :

On voit que curl accède d'abord au serveur mozilla.cloudflare-dns.com via le protocole DoH (connexion https au serveur 104.16.249.249) pour en obtenir les valeurs des clés publiques pour le cryptage SNI, puis vers la destination serveur, caché derrière le domaine www.hello-rkn.ru.

En plus du résolveur DoH ci-dessus mozilla.cloudflare-dns.com, nous pouvons utiliser d'autres services DoH populaires, par exemple ceux de la célèbre société maléfique.
Exécutons la requête suivante :

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Et nous obtenons la réponse :

< 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

Dans ce cas, nous nous sommes tournés vers le serveur bloqué rutracker.nl, en utilisant le résolveur DoH dns.google (il n'y a pas de faute de frappe ici, maintenant la célèbre société a son propre domaine de premier niveau) et nous nous sommes couverts d'un autre domaine, qui est strictement interdit à tous les DPI de bloquer sous peine de mort. Sur la base de la réponse reçue, vous pouvez comprendre que notre demande a été traitée avec succès.

Comme vérification supplémentaire que le DPI du fournisseur répond au SNI ouvert, que nous transmettons en guise de couverture, nous pouvons faire une demande à rutracker.nl sous le couvert d'une autre ressource interdite, par exemple, un autre « bon » tracker torrent :

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Nous ne recevrons pas de réponse du serveur, car... notre demande sera bloquée par le système DPI.

Une brève conclusion à la première partie

Ainsi, nous avons pu démontrer la fonctionnalité d'eSNI en utilisant openssl et curl et tester le fonctionnement du domain fronting basé sur eSNI. De la même manière, nous pouvons adapter nos outils préférés qui utilisent la bibliothèque openssl pour fonctionner « sous couvert » d'autres domaines. Plus de détails à ce sujet dans nos prochains articles.

Source: habr.com