Il y a quelques semaines, je me trouvais à l’étranger et, alors que j’essayais d’accéder à un site sur lequel je vais régulièrement : page blanche… le chargement poursuit sans fin. Étrange. Normalement, si le serveur est tombé, le navigateur nous avertit qu’il y a une erreur de chargement, s’il y a un problème avec les DNS, le navigateur nous dit que l’adresse est introuvable. Ni l’un, ni l’autre, ok, on a bloqué mon site !

Avant de conclure trop hâtivement, je creuse un peu plus : je ping le nom de domaine, pas de problème, les DNS fonctionnent bien. Je tente d’accéder directement à l’adresse ip : ok, je tombe sur une page Cloudflare. Le problème n’est donc définitivement pas à imputer au site. Je creuse un peu plus et trouve la source du problème. C’est alors que j’ai songé qu’il fallait écrire un article pour présenter tout ça de manière claire.

Blocage et protocoles

La plupart des gens qui connaissent un tant soit peu le web ont en tête le schéma client serveur d’accès à un site web. En résumé, lorsqu’on tente d’accéder à un site, notre navigateur envoie une requête à un serveur DNS pour en connaitre l’adresse ip, puis, envoie une requête HTTP à l’ip correspondante afin que le serveur lui retourne la page.

Le schéma est assez parlant et on comprend aisément qu’il y a au moins trois moyens de bloquer l’accès à un site web.

Blocage DNS

Le blocage DNS consiste à empêcher la résolution d’un nom de domaine en adresse ip. Il est facilement contournable en utilisant un serveur DNS alternatif tel que ceux d’Open Nic. La quasi totalité des ordinateurs, tablettes et smartphones permettent de choisir ses serveurs DNS.

Blocage par adresse IP

Dans le cas d’un blocage ip, c’est directement l’adresse ip du site web qui est bloquée par le FAI. Ce type de blocage n’est pas sans poser de problème puisque si plusieurs sites sont hébergés sur la même adresse ip, comme dans le cas d’un hébergement mutualisé, l’ensemble des sites se retrouvent inaccessibles.

Idem, dans le cas d’un CDN comme Cloudflare, l’adresse ip correspond potentiellement à des milliers de sites et bloquer l’ensemble est difficilement envisageable. Ce type de blocage est donc plus rarement utilisé.

Néanmoins, dans le cas d’un tel blocage, la seule solution est d’avoir recours à un tunnel chiffré, tel qu’un VPN, un Proxy SOCKS ou encore d’utiliser TOR afin d’accéder à un réseau ne bloquant pas l’ip en question.

Blocage de l’hôte

Au lieu d’avoir recours à un blocage DNS, il est possible que le FAI filtre vos packets en se basant sur les en-têtes HTTP. Observons l’anatomie d’un en-tête :

Host: buzut.fr
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en;q=0.7,en-US;q=0.5,es;q=0.3,es-ES;q=0.2
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cache-Control: max-age=0

Voilà l’en-tête de requête que soumet mon navigateur, cookies mis à part, quand je tape buzut.fr dans la barre d’adresse. Le première ligne indique le host auquel on souhaite accéder. Il suffit donc au FAI de lire cet en-tête, et si l’host est censé être bloqué alors mes packets HTTP ne sont pas acheminés. Tout simplement.

Le remède à ce type de blocage est le même que pour le blocage par IP, c’est à dire VPN ou proxy socks.

Blocage par DPI

Le DPI, ou deep packet inspection, consiste à analyser les paquet réseau pour en voir le contenu. Ainsi, il est possible d’appliquer toute sorte de filtrage, notamment par mot-clef etc.

Il y a néanmoins plusieurs inconvénients à cette technique. Elle nécessite plus de puissance que les autres méthodes de blocage et est donc plus onéreuse à mettre en place. Par ailleurs, dans le cas du chiffrement, site web en HTTPS par exemple, l’ensemble des communications entre le navigateur et le serveur web sont illisibles, le DPI devient donc impuissant pour lire le contenu.

Néanmoins, ce type de filtrage peut être évité en utilisant des connexions sécurisés via SSL/TLS (HTTPS) ou en ayant recours au VPN ou proxy socks sus-mentionnés.

Blocage par url

Ce type de blocage est le plus souvent mis en place au niveau des réseaux locaux, au sein d’une école par exemple. Il est très souple car il permet de bloquer seulement certaines pages d’un site sans en bloquer l’intégralité. Il permet également d’agir en fonction de mot-clefs présents dans l’url (l’admin de l’école bloquera par exemple le mot “porn”).

Sa grande faiblesse est qu’une connexion SSL suffit à le contourner, il n’est donc pas d’une efficacité redoutable à l’heure ou de plus en plus de sites passent sur des protocoles sécurisés.

Ne pas tout mélanger

On a vite tendance à croire que le chiffrement résout tous les problèmes. De prime abord, je ne comprenais pas pourquoi, si les DNS résolvaient le nom de domaine et que je faisais une requête en HTTPS au site, il pouvait être bloqué.

Mon raisonnement était le suivant : si j’ai la bonne adresse ip et que le contenu est chiffré via le protocole TLS, mes données ne peuvent théoriquement pas être lues, donc comment bloquer le site si on ne sait pas à quoi je tente d’accéder ? C’était bien entendu sans compter sur le Server Name Identification. Le SNI est une extension du protocole TLS visant à informer le serveur de l’hôte auquel il tente d’accéder. Sans le SNI, on ne pourrait pas utiliser de VHOST avec les sites en HTTPS, il faudrait donc une ip par site…

Comme l’hôte doit être communiqué avant le handshake (le processus qui initie le chiffrement), l’hôte est communiqué en clair dans le header HTTP. Donc visible par tous sur le réseau, même avec SSL/TLS. Ce n’est néanmoins pas le cas du reste de l’url, d’où la confusion possible. En d’autres termes, si vous tentez d’accéder à https://buzut.fr/a-propos/, le fait que vous alliez sur buzut.fr est en clair, en revanche, personne d’autre que mon serveur et votre navigateur ne saura que vous consultez la page /a-propos/.

Par ailleurs, la connexion HTTP et la requête DNS étant deux choses séparées, le fait d’utiliser HTTPS ne signifie absolument pas que votre requête DNS est chiffrée. D’ailleurs, même le protocole DNSSec, la version sécurisée du DNS, ne chiffre pas les échanges entre votre machine et le serveur DNS. Son nom peut être trompeur, mais son vrai rôle est de garantir l’intégrité des informations – s’assurer qu’on ne vous donne pas une adresse ip falsifiée par exemple – et non la confidentialité.

Enfin, je n’ai parlé ici que du web, c’est à dire des sites Internet, mais beaucoup d’autres choses peuvent être bloquées, comme le P2P, la voix sur IP etc. Évidemment il sera possible d’appliquer d’autres méthodes de blocage (tel que le blocage de port) à ces autres protocoles.

J’espère avoir pu vous éclairer sur cette question, ô combien épineuse, du blocage. Vous arrive-t-il souvent de vous retrouver face à des sites bloqués ?