Domaine-fronting basé sur TLS 1.3

Introduction

Les systèmes de filtrage de contenu d'entreprise modernes, provenant de fabricants renommés comme Cisco, BlueCoat, et FireEye, partagent de nombreuses caractéristiques avec leurs homologues plus puissants - les systèmes DPI, qui sont intensément implantés au niveau national. Le principe de fonctionnement des deux est d'inspecter le trafic Internet entrant et sortant et, sur la base de listes noires / blanches, de décider de bloquer ou non la connexion Internet. Étant donné que les deux reposent sur des principes similaires, les méthodes pour les contourner auront également beaucoup en commun.

Une des technologies permettant de contourner assez efficacement à la fois les DPI et les systèmes d'entreprise est la technologie du domain fronting. Son principe consiste à accéder à une ressource bloquée en se cachant derrière un autre domaine public à la bonne réputation, qui ne sera sûrement pas 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é présentés. Cependant, les technologies populaires récemment discutées telles que DNS-over-HTTPS et encrypted-SNI, ainsi que la nouvelle version du protocole TLS 1.3, offrent la possibilité d'examiner une autre variante du domain fronting.

Comprenons la technologie

Commençons par définir quelques concepts de base, afin que tout le monde comprenne qui est qui et pourquoi tout cela est nécessaire. Nous avons mentionné le mécanisme eSNI, dont le fonctionnement sera examiné plus loin. Le mécanisme eSNI (encrypted Server Name Indication) est une version sécurisée de SNI, accessible uniquement pour le protocole TLS 1.3. L'idée principale est de chiffrer également les informations sur le domaine vers lequel la demande est envoyée.

Analysons maintenant le fonctionnement du mécanisme eSNI en pratique.

Supposons que nous ayons une ressource Internet qui est bloquée par une solution DPI moderne (prenons par exemple le célèbre tracker torrent — rutracker.nl). Lors de la tentative d'accès au site du tracker torrent, nous voyons le message standard du fournisseur indiquant que la ressource est bloquée :

Sur le site de la RKN, ce domaine figure effectivement sur les listes noires :

Lors de la requête whois, on constate que le domaine lui-même est « caché » derrière le fournisseur Cloudflare.

Mais contrairement aux « spécialistes » de la RKN, les employés plus techniquement compétents de Beeline (ou ceux qui ont appris de l’expérience amère de notre célèbre régulateur) n’ont pas bloqué stupidement le site par adresse IP, mais ont ajouté au liste d’interdiction précisément le nom de domaine. Il est facile de s'en rendre compte en regardant quels autres domaines se cachent derrière celui-ci, adresse IP, en visitant l'un d'eux et en constatant que l'accès n'est pas bloqué :

Comment cela est-il possible ? Comment le DPI du fournisseur sait-il vers quel domaine se dirige mon navigateur, alors que toutes les communications se font via le protocole https, et que jusqu'à présent nous n'avons pas remarqué de falsifications des certificats https de Beeline ? Est-il clairvoyant ou suis-je sous surveillance ?

Essayons de répondre à cette question en examinant le trafic à l'aide de Wireshark.

Sur la capture d'écran, on voit d'abord que le navigateur obtient l'adresse IP du serveur via DNS, puis se produit la poignée de main TCP standard avec le serveur de destination, et ensuite le navigateur tente de établir une connexion SSL avec le serveur. Pour cela, il envoie un paquet SSL Client Hello, qui contient le nom du domaine source en clair. Ce champ est nécessaire au serveur frontal de Cloudflare pour router correctement la connexion. C'est ici que le DPI du fournisseur nous attrape, en rompant notre connexion. Nous ne recevons aucune page de blocage de la part du fournisseur et voyons une erreur standard du navigateur comme si le site était hors ligne ou ne fonctionnait tout simplement pas :

Maintenant, activons 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 activons 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 le bon fonctionnement des paramètres sur le site de Cloudflare à le lien et nous essaierons de nouveau le tour avec notre tracker torrent.

Voilà ! Notre tracker préféré s'est ouvert, sans aucun VPN ni serveur proxy. Regardons maintenant le dump de trafic dans Wireshark, que s'est-il passé.

Cette fois, le paquet SSL client hello ne contient pas explicitement le domaine de destination, mais à la place, un nouveau champ est apparu dans le paquet — encrypted_server_name — c'est là que se trouve la valeur rutracker.nl, et seul le serveur frontal de Cloudflare peut déchiffrer ce champ. Donc, le DPI du fournisseur n'a d'autre choix que de se laver les mains et d'autoriser ce trafic. Il n'y a pas d'autres options avec le cryptage.

Alors, nous avons vu comment la technologie fonctionne dans le navigateur. Maintenant, essayons de l'appliquer à des choses plus spécifiques et intéressantes. Pour commencer, nous allons apprendre à utiliser le même curl avec l'eSNI pour travailler avec TLS 1.3, tout en regardant comment fonctionne le domain fronting basé sur l'eSNI.

Domain Fronting avec eSNI

Étant donné que curl utilise la bibliothèque standard openssl pour se connecter via le protocole https, nous devons d'abord garantir le support de l'eSNI là-bas. Les branches master d'openssl n'ont pour l'instant pas de support pour l'eSNI, donc nous devons télécharger une branche spéciale d'openssl, la compiler et l'installer.

Nous clonons le dépôt 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 dépôt de curl et configurons sa compilation en utilisant 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

Il est important de spécifier correctement tous les répertoires où se trouve openssl (dans notre cas, c'est /opt/openssl/) et de s'assurer que le processus de configuration se passe sans erreurs.

En cas de configuration réussie, nous verrons la ligne :

WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!

$ make

Après une compilation réussie du paquet, nous utiliserons un script bash spécial provenant d'openssl pour configurer et lancer curl. Nous le copierons dans le répertoire de curl pour plus de commodité :

cp /opt/openssl/esnistuff/curl-esni 

et nous effectuerons une requête https de test vers le serveur cloudflare, tout en enregistrant 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 de openssl et curl, nous recevrons une réponse HTTP avec un 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 requête a été correctement livrée au serveur de destination, entendue et traitée.

Voyons maintenant le dump de trafic dans Wireshark, c'est-à-dire ce que le DPI du fournisseur a observé dans ce cas.

Il est clair que curl s'est d'abord tourné vers le serveur DNS pour obtenir la clé publique eSNI du serveur Cloudflare — une requête DNS TXT sur _esni.cloudflare.com (paquet n° 13). Ensuite, en utilisant la bibliothèque openssl, curl a envoyé une requête TLS 1.3 au serveur Cloudflare dans laquelle le champ SNI était chiffré avec la clé publique obtenue lors de l'étape précédente (paquet n° 22). Cependant, en plus du champ eSNI, le paquet SSL hello contenait aussi un champ avec un SNI ordinaire — ouvert, que nous pouvons indiquer dans un ordre quelconque (dans ce cas — www.hello-rkn.ru).

Ce champ SNI ouvert n'a pas du tout été pris en compte lors du traitement par les serveurs Cloudflare et était simplement une couverture pour le DPI du fournisseur. Le serveur Cloudflare a accepté notre paquet ssl-hello, a déchiffré l'eSNI, en a extrait l'SNI original et l'a traité comme si de rien n'était (il a fait exactement comme prévu lors du développement de l'eSNI).

Le seul point sur lequel on peut s'accrocher du point de vue du DPI est la requête DNS initiale sur _esni.cloudflare.com. Mais nous avons rendu la requête DNS ouverte uniquement pour montrer comment ce mécanisme fonctionne de l'intérieur.

Pour définitivement couper l'herbe sous le pied du DPI, nous utilisons le mécanisme déjà mentionné de DNS-over-HTTPS. Une petite explication – DoH – est un protocole qui permet de se protéger contre les attaques de type « homme du milieu » en envoyant des requêtes DNS via le protocole HTTPS.

Répétons la requête, mais cette fois, nous obtiendrons les clés publiques eSNI via le protocole HTTPS, et non DNS :

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

Le dump du trafic de la requête est présenté dans la capture d'écran ci-dessous :

Il est visible que d'abord, curl s'adresse au serveur mozilla.cloudflare-dns.com via le protocole DoH (connexion HTTPS au serveur 104.16.249.249), pour obtenir les valeurs des clés publiques pour chiffrer l'SNI, puis se connecte au serveur cible, s'abritant sous le domaine www.hello-rkn.ru.

En plus du résolveur DoH mentionné ci-dessus, mozilla.cloudflare-dns.com, nous pouvons également utiliser d'autres services DoH populaires, par exemple celui de la célèbre corporation du mal.
Effectuons une telle requête :

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

Et nous obtiendrons une 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 avons accédé au serveur bloqué rutracker.nl en utilisant le résolveur DoH dns.google (il n'y a pas de faute d’orthographe, maintenant la célèbre entreprise a son propre domaine de premier niveau) et nous nous sommes couverts avec un autre domaine, dont le blocage est strictement interdit à tous les DPI sous peine de mort. D'après la réponse reçue, on peut comprendre que notre requête a été traitée avec succès.

Comme vérification supplémentaire que le DPI du fournisseur réagit à l'SNI ouvert, que nous transmettons comme couverture — nous pouvons effectuer une requête à rutracker.nl en nous couvrant avec un autre resource interdit, 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 requête sera bloquée par le système DPI.

Petite conclusion à la première partie

Ainsi, nous avons réussi à démontrer le fonctionnement de l'eSNI à l'aide d'openssl et de curl, et à vérifier le fonctionnement du domain fronting basé sur eSNI. De la même manière, nous pouvons adapter nos outils préférés utilisant la bibliothèque openssl pour fonctionner 'sous couverture' d’autres domaines. Plus de détails à ce sujet dans nos prochains articles.

Source : habr.com