Présentation
Les systèmes modernes de filtrage de contenu d'entreprise de fabricants éminents tels que Cisco, BlueCoat, FireEye ont beaucoup en commun avec leurs homologues plus puissants - les systèmes DPI qui sont intensément mis en œuvre au niveau national. L'essence du travail des deux est de rechercher le trafic Internet entrant et sortant et, sur la base de listes noires / blanches, de décider d'interdire la connexion Internet. Et comme les deux s'appuient sur des principes similaires dans les principes fondamentaux de leur travail, les moyens de les contourner auront également beaucoup en commun.
L'une des technologies qui permet de contourner efficacement les systèmes DPI et d'entreprise est la technologie orientée domaine. Son essence réside dans le fait que nous allons vers une ressource bloquée, cachée derrière une autre, domaine public, avec une bonne réputation, qui ne sera évidemment bloquée 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 sur HTTPS et SNI chiffré, ainsi que les technologies récemment discutées, ainsi que la nouvelle version du protocole TLS 1.3, offrent la possibilité d'envisager une autre variante de la gestion frontale de domaine.
Nous traitons avec la technologie
Tout d'abord, décidons un peu des concepts de base pour que tout le monde comprenne qui est qui et pourquoi tout cela est nécessaire. Nous avons mentionné le mécanisme eSNI, dont le travail sera discuté plus tard. Le mécanisme eSNI (encrypted Server Name Indication) est une version sécurisée de SNI, disponible uniquement pour le protocole TLS 1.3. Le point principal est de crypter, y compris les informations sur le domaine auquel la demande est envoyée.
Voyons maintenant comment le mécanisme eSNI fonctionne dans la pratique.
Supposons que nous ayons une ressource Internet qui est bloquée par une solution DPI moderne (prenez, par exemple, le célèbre tracker torrent - rutracker.nl). Lorsque nous essayons d'accéder au site du tracker torrent, nous voyons le talon standard du fournisseur que la ressource est bloquée:
Sur le site ILV, ce domaine est en effet répertorié dans les listes d'arrêt:
Lorsque vous demandez whois, vous pouvez voir que le domaine lui-même est «caché» derrière le fournisseur de cloud Cloudflare.
Mais contrairement aux «spécialistes» d'ILV, les employés les plus techniquement avertis de la ligne de conduite (ou enseignés 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 entré le nom de domaine dans la liste d'arrêt. C'est facile à vérifier si vous regardez quels autres domaines se cachent derrière la même adresse IP, visitez l'un d'eux et voyez que l'accès n'est pas bloqué:
Mais comment ça se passe? Comment le fournisseur DPI détecte-t-il les domaines vers lesquels mon navigateur se rend, car toutes les communications ont lieu via le protocole https, et nous ne semblons pas encore remarquer la substitution des certificats https de la ligne de bord? Est-il clairvoyant ou est-il suivi par moi?
Essayons de répondre à cette question en examinant le trafic via Wirehark
La capture d'écran montre que le navigateur reçoit d'abord l'adresse IP du serveur via DNS, puis il y a une négociation TCP standard avec le serveur de destination, puis le navigateur tente d'établir une connexion SSL avec le serveur. Pour ce faire, il envoie le paquet SSL Client Hello, qui contient le nom de domaine source en texte clair. Ce champ est requis par le serveur frontal cloudflare afin de router correctement la connexion. C'est là que le fournisseur DPI nous attrape, rompant notre connexion. Dans le même temps, nous ne recevons aucun talon du fournisseur, et nous voyons une erreur de navigateur standard comme si le site était déconnecté ou ne fonctionnait tout simplement pas:
Maintenant, activons le mécanisme eSNI dans le navigateur, comme décrit dans les instructions pour
Firefox :
Pour ce faire, nous ouvrons la page de configuration de Firefox
sur: 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 l'exactitude des paramètres sur le site Web cloudflare en utilisant le
lien et réessayerons le focus avec notre tracker torrent.
Voila. Notre tracker préféré s'est ouvert sans VPN ni proxy. Regardons maintenant le vidage de trafic dans Wireshark, ce qui s'est passé.
Cette fois, le package hello du client ssl ne contient pas explicitement le domaine de destination, mais un nouveau champ est apparu dans le package - encrypted_server_name - c'est là que la valeur de rutracker.nl est contenue, et seul le serveur cloudflare frontal peut décrypter ce champ. Et si c'est le cas, le fournisseur DPI n'a d'autre choix que de se laver les mains et d'autoriser un tel trafic. Mais il n'y a pas d'autres options de cryptage.
Donc, comment la technologie fonctionne dans le navigateur - nous avons regardé. Essayons maintenant de l'appliquer pour des choses plus spécifiques et intéressantes. Et pour commencer, nous enseignerons la même boucle pour utiliser eSNI pour travailler avec TLS 1.3, et en même temps, nous verrons comment le domaine frontal basé sur eSNI lui-même fonctionne.
Frontend de domaine avec eSNI
Étant donné que curl utilise la bibliothèque openssl standard pour se connecter via https, nous devons tout d'abord y fournir un support eSNI. Il n'y a pas encore de support pour eSNI dans les branches master openssl, nous devons donc télécharger la branche openssl spéciale, la compiler et l'installer.
Nous clonons le dépôt depuis le 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 assemblé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 d'indiquer correctement tous les répertoires où se trouve openssl (dans notre cas, c'est / opt / openssl /) et assurez-vous que le processus de configuration se passe sans erreur.
En cas de configuration réussie, nous verrons la ligne:
AVERTISSEMENT: esni ESNI activé mais marqué EXPÉRIMENTAL. À utiliser avec prudence! $ make
Après avoir construit le package avec succès, nous utiliserons un fichier bash openssl spécial pour configurer et exécuter curl. Copiez-le dans le répertoire avec curl pour plus de commodité:
cp /opt/openssl/esnistuff/curl-esni
et exécutez une demande de test https sur le serveur cloudflare, tout en écrivant simultanément des 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 des nombreuses informations de débogage d'OpenSL et de Curl, nous obtenons 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é envoyée avec succès au serveur de destination, entendue et traitée.
Maintenant, regardons le vidage du trafic dans Wireshark, c'est-à-dire ce que le fournisseur DPI a vu dans ce cas.
On peut voir que la première boucle s'est tournée vers le serveur DNS pour une clé eSNI publique pour le serveur cloudflare - demande DNS TXT à _esni.cloudflare.com (package n ° 13). Ensuite, à l'aide de la bibliothèque openssl, curl a envoyé une requête TLS 1.3 au serveur cloudflare dans lequel le champ SNI a été chiffré avec la clé publique obtenue à l'étape précédente (package n ° 22).
Mais, en plus du champ eSNI, dans le cadre du package SSL-hello, un champ a également été inséré avec l'habituel - SNI ouvert, que nous pouvons spécifier dans n'importe quel ordre (dans ce cas - www.hello-rkn.ru ).Ce champ de la SNI ouverte n'a pas été pris en compte lors du traitement par les serveurs cloudflare et n'était qu'un déguisement pour le 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 d'eSNI).
La seule chose dans ce cas, vous pouvez vous accrocher en termes de DPI - la requête DNS principale sur _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 éliminer le sol sous le DPI, nous utilisons le mécanisme DNS-over-HTTPS déjà mentionné. Une petite explication - DOH - un protocole qui vous permet de vous protéger d'un homme dans l'attaque du milieu en envoyant une requête DNS via HTTPS.
Nous exécuterons à nouveau la demande, mais cette fois, nous obtiendrons les clés publiques eSNI en utilisant le protocole https, pas le 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 demande est présenté dans la capture d'écran ci-dessous:
On voit que la première boucle accède au serveur mozilla.cloudflare-dns.com en utilisant le protocole DoH (connexion https au serveur 104.16.249.249) pour obtenir d'eux des valeurs de clé publique pour le cryptage SNI, puis au serveur de destination, se cachant sous le domaine
www.hello-rkn.ru .
En plus du résolveur DoH de mozilla.cloudflare-dns.com spécifié ci-dessus, nous pouvons utiliser d'autres services DoH populaires, par exemple, de la célèbre evil corporation.
Nous exécutons la demande 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 dns.google DoH (il n'y a pas de faute de frappe, maintenant la célèbre société a son propre domaine de premier niveau) et nous nous sommes couverts avec un autre domaine, qui est strictement interdit par tous les DPI pour bloquer par crainte de la peine de mort. Selon la réponse, vous pouvez comprendre que notre demande a été traitée avec succès.
Comme vérification supplémentaire que le fournisseur DPI répond à une SNI ouverte, que nous transmettons comme couverture - nous pouvons exécuter une demande à rutracker.nl derrière une autre ressource interdite, par exemple, un autre "bon" tracker de 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 petite conclusion à la première partie
Nous avons donc pu montrer la santé d'eSNI en utilisant openssl et curl et tester le fonctionnement du front-end basé sur un domaine basé sur eSNI. De la même manière, nous pouvons adapter nos outils préférés à l'aide de la bibliothèque openssl pour travailler «sous couvert» d'autres domaines. Plus d'informations à ce sujet dans nos prochains articles.