R. Barnes (Mozilla)A. Cooper (Cisco)O. Kolkman (ISOC)D. Thaler (Microsoft)E. Nordmark (Arista)March20162016-03-10
Normalement, l'Internet est
ouvert. C'est même une de ses principales
caractéristiques : un outil de communication ouvert, où tout le
monde peut s'exprimer. C'est cette ouverture qui est à la base de
son succès. Mais une de ses conséquences est que certaines
communications vont être indésirables pour certains. Il y a donc
une demande pour du « blocage » ou du « filtrage », afin
d'empêcher ces communications. Ce nouveau
RFC, dû à l'IAB,
examine les techniques de blocage et de filtrage et cherche
lesquelles sont le plus compatibles avec une architecture saine et
robuste de l'Internet. Évidemment, les techniques qui menacent le
moins la robustesse de l'Internet sont celles qui se déroulent
entièrement aux extrémités. Si je ne veux pas voir les publicités,
j'installe un logiciel qui télécharge sur ma machine une liste
noire de serveurs distribuant ces publicités, et je peux ainsi
bloquer et filtrer sans risques pour l'utilisation de l'Internet
par les autres. Mais, hélas, pas mal de gens puissants se moquent
de fragiliser l'Internet (ou la démocratie) et bien d'autres
méthodes de blocage ou de filtrage existent.
On voit tout de suite que ce RFC est
très politique. Les filtrages dont il parle sont évidemment ceux
de gens ayant du pouvoir (entreprises, États) et qui vont essayer
d'empêcher M. Michu de voir ce qu'il veut. Mais l'IAB essaie de ne
pas faire trop de politique, et se limite à analyser le problème
technique. Ce RFC est un excellent document, analysant très
finement les systèmes de filtrage et blocage, et restant sous
l'angle technique, à la fois par désir de ne pas prendre position
trop clairement et aussi parce que, pour l'Internet, une censure
légale/légitime et une attaque ne sont pas différentes.
Le problème des « communications non souhaitées » est vaste. Il
ne se limite pas aux pages Web qui déplaisent aux ministres et que
ceux-ci souhaitent censurer. Il y a aussi le logiciel
malveillant (qui remonte à loin), les attaques, le
spam, etc. C'est donc depuis longtemps
qu'il existe des techniques de blocage et de filtrage, et depuis
aussi longtemps qu'elles sont vigoureusement contestées.
Le notait déjà que certains
FAI bloquaient l'accès à certains
services. Parfois, cela se fait avec le consentement de
l'utilisateur, consentement parfois très contestable : si, pour
avoir un accès Internet à l'hôtel, vous devez cliquer « J'accepte » après un
texte de vingt pages, y a-t-il réellement eu consentement ? Mais,
souvent, il n'y a même pas de semblant de consentement : certains
voudraient bloquer sans que l'utilisateur soit d'accord, et
parfois sans
même qu'il soit informé. Si ces « certains » ne contrôlent pas le
réseau, ils cherchent à atteindre leurs fins en agissant sur des
intermédiaires (comme les résolveurs
DNS), et tant pis pour les dommages collatéraux.
J'ai parlé de « blocage » et de « filtrage », quelle est la
différence ? On dit en général « blocage » quand on interdit
complètement l'accès à un agrégat de ressources et « filtrage »
quand il s'agit de sélectivement empêcher l'accès à certaines
ressources seulement, dans cet agrégat. Si on empêche l'accès à
tout YouTube, c'est du blocage. Si on
empêche seulement l'accès à certaines vidéos, c'est du
filtrage. Pour l'analyse dans ce RFC, cela ne change pas
grand'chose, et on parlera indifféremment de filtrage ou de blocage.
Selon le pays, l'époque, les opinions politiques de la personne
à qui on parle, ce filtrage peut être vu comme légal, illégal,
éthique, acceptable, dégueulasse, souhaitable, stupide, scandaleux
et contraire aux droits de l'homme,
indispensable, etc. Mais, pour
l'analyse technique qui est faite par l'IAB, cela ne fait pas de
différence. Notamment, la distinction légale/illégale est non
seulement très complexe (le gouvernement turc a-t-il le droit de
détourner l'adresse IP d'un serveur états-unien ?) mais également
sans conséquences pour la technique. (Un logiciel ne sait pas ce
qui est légal ou illégal et il travaille de la même façon dans les
deux cas.)
C'est encore plus vrai pour la distinction éthique/pas éthique,
que notre RFC considère comme hors sujet, et sur laquelle il ne
prend donc pas position.
La section 2 du RFC donne plusieurs exemples de filtrage ou
blocage. Historiquement, les premiers systèmes qui se mettaient
sur le trajet entre Alice et Bob étaient
les pare-feux (). Ils
peuvent être déployés sur les machines terminales (c'est
aujourd'hui le cas du Netfilter de
Linux) ou bien sur le réseau (souvenir personnel
lointain : les débuts avaient été difficiles car certains systèmes
supportaient mal qu'une machine soit joignable via certains
ports et pas
d'autres : c'est ainsi qu'au début des années 1990, Ultrix coupait
toute communication avec une machine dès qu'il recevait un
ICMP indiquant qu'un port était
bloqué).
Il y a bien des sortes de pare-feux, le
contient des définitions, et le
décrit les différents types de trafic non souhaités, ceux qu'on
veut typiquement bloquer avec le pare-feu. Notamment, on distingue
traditionnellement (ces termes sont absents du ,
qui est assez ancien) :
Les pare-feux sans état, où chaque paquet est traité
indépendemment des autres. Ce sont les plus simples à réaliser
et les premiers apparus. Ils permettent, par exemple, de bloquer
toute connexion sortant vers le port 25 (celui de
SMTP), pour empêcher les
zombies d'envoyer du spam.Les pare-feux avec état, qui ont une mémoire des
précédents paquets, ce qui permet des politiques plus subtiles
comme de bloquer tout paquet entrant qui ne correspond pas à un
flot de données déjà établi (une connexion TCP, par
exemple). Ils sont plus complexe à réaliser (et donc plus
fragiles) et l'état nécessite de la mémoire, les rendant très
vulnérables en cas d'attaque par déni de
service (le pare-feu à état plante souvent avant le
serveur qu'il était censé protéger).Les pare-feux capables de DPI. Le
terme est assez flou mais il désigne en général, de façon assez
arbitraire, les pare-feux qui examinent au-delà de la
couche 4, par exemple en regardant le
contenu applicatif.
Autre exemple de filtrage, celui du
Web. Comme les dirigeants, en général, ne
connaissent de l'Internet que le Web, c'est souvent sur celui-ci
que portent les efforts de censure. Il est donc fréquent que le
filtrage soit spécifique à certains URI,
soit en détournant tout le trafic HTTP vers
un proxy qui examine les
URI, soit par DPI. Évidemment, HTTPS rend
bien plus compliqué ce filtrage. Mais ne l'empêche pas
complètement, en raison des failles du modèle de sécurité de
X.509 : par exemple, le filtreur peut obtenir
un faux certificat d'une autorité existante, ou bien faire
installer sur les ordinateurs une autorité de
certification qui validera les faux certificats
générés par le système de filtrage.
Le filtrage n'est pas forcément fait par des méchants
dictateurs voulant empêcher les citoyens d'accéder à des
informations honnêtes. Un bon exemple d'un filtrage que la
majorité des utilisateurs apprécie, et même réclame, est le
filtrage du spam. C'est même sans doute
dans la lutte contre le spam que le filtrage a trouvé une de ses
premières applications. Une des armes utilisées, les
listes noires, est,
techniquement, tout à fait comparable aux outils de la censure
().
Un autre exemple cité dans le RFC d'un filtrage volontaire par
les utilisateurs est le safe
browsing, quand le navigateur Web connait
une liste de sites Web méchants ou dangereux, et refuse de s'y connecter.
Et le filtrage des noms de
domaine ? Cela peut se faire en supprimant ledit nom,
par exemple par la procédure de justice privée
UDRP (cf. Moore, T. et R. Clayton,
« The
Impact of Incentives on Notice and Take-down »,
Workshop on the Economics of Information Security
2008, et Chachra, N., McCoy, D., Savage, S., et
G. Voelker « Empirically
Characterizing Domain Abuse and the Revenue Impact of
Blacklisting », Workshop on the
Economics of Information Security 2014. Cette approche
nécessite de disposer d'un moyen politique d'action contre le
registre qui gère le nom (notez que c'est
la loi du pays du registre qui compte, pas la loi du titulaire,
comme l'avait illustré l'affaire
RojaDirecta).
Mais la censure d'un nom de domaine peut aussi se faire dans le
DNS. (Au passage,
arrêtez de lire ici et allez, si ce n'est pas encore fait, allez voir
l'excellent rapport
du conseil scientifique de l'AFNIC « Conséquences du filtrage
Internet par le DNS ».) Dans ce cas, un résolveur menteur va donner, pour ce nom
de domaine, un autre résultat que celui prévu par le titulaire du
nom (c'est ainsi que fonctionne la censure administrative
française). Cette technique est utilisée
dans de nombreux pays, même si elle fragilise l'Internet, par
exemple en perturbant le déploiement de DNSSEC.
Une autre technologie d'infrastructure qui
risque d'être utilisée pour le filtrage est le
routage. En manipulant le routage de
l'Internet, on peut empêcher l'utilisateur d'accéder où il
veut. Un exemple typique a été l'action aux
Pays-Bas contre le
RIPE-NCC dans l'affaire
DNSChanger.
Après ce tour des exemples de filtrage (le RFC en cite
plusieurs autres que je n'ai pas repris ici), passons maintenant à
la théorie et essayons de classer ces systèmes de blocage. Il y a
quatre critères de classement importants :
Qui bloque ?Pourquoi bloque-t-il ?Quelle est la cible technique du
blocage ?Quoi, quel composant de l'Internet
est utilisé pour le blocage ?
La liste des cas présentés à la section 2 était délibérement très
variée, utilisant des cas qui se classent très différemment selon
ces critères.
Commençons, par le premier critère, qui
bloque. On a vu des blocages par la police, par des tribunaux, par
des entreprises, par des opérateurs réseau et par des utilisateurs
individuels. Souvent, la décision est prise par une entité et
ensuite appliquée par une autre. Par exemple, le ministère de
l'Intérieur décide de bloquer un site Web « djihadiste » mais
c'est un FAI qui, via son résolveur DNS
menteur, effectue le blocage. (Le RFC n'en parle pas mais un autre
exemple est celui où une entreprise choisit d'utiliser un
résolveur menteur, par exemple OpenDNS,
comme résolveur. OpenDNS affirme toujours que leurs clients ont
choisi le blocage. Mais, dans ce cas, l'employé de base a-t-il
réellement choisi ?)
Second critère, pourquoi on bloque. On
peut bloquer « pour des raisons de sécurité » (c'est souvent une
excuse pipeau mais il y a aussi des vraies raisons de
sécurité). Par exemple, on va bloquer les sites Web qui
distribuent du logiciel malveillant. Ou
bien on va bloquer les communications avec tel préfixe IP, d'où
partent souvent des attaques.
On peut aussi bloquer un contenu dont on ne veut pas. Le RFC ne
cite pas cet exemple mais on pense évidemment aux
bloqueurs de pub. Il y a aussi bien sûr les
cas de censure étatique, où l'État ne veut pas que les citoyens
accèdent à tel site Web. Les raisons sont nombreuses, de la
pédopornographie au
jeu en
ligne en passant par la vente de
drogues, la propagande raciste ou la violation des droits
sacrés des ayant-droits.
Le blocage peut aussi se faire pour des raisons économiques,
par exemple un service d'accès à l'Internet gratuit mais qui
bloquerait la plupart des sites, nécessitant une option payante
pour y accéder.
Le blocage peut se faire par liste noire (on laisse passer par
défaut, et on a une liste des choses interdites, c'est typiquement
le cas avec la censure) ou carrément par liste
blanche (on bloque par défaut et on a une liste des choses
autorisées, c'est typiquement le cas des offres limitées). Une
entreprise qui ne veut pas que ses employés passent du temps sur
autre chose que les tâches qui leur sont affectées pourrait
utiliser une liste noire (interdire ce qui leur ferait « perdre »
du temps) ou la liste blanche (limiter les employés à quelques
destinations connues).
Troisième critère de classification, quelle est la cible
exacte ? Veut-on bloquer un service entier (par exemple la
voix sur IP, pour protéger la vache à lait
des opérateurs téléphoniques) ? Ou un contenu très spécifique (une
seule vidéo sur YouTube) ? Certaines
techniques bloquent facilement plus que la cible visé. Par
exemple, supprimer un nom de domaine parce
que le site Web sert un contenu à problèmes va aussi couper tous
les services associés à ce nom de domaine (le
courrier par
exemple). Les demandes de take down (« le site
Web en http://example.com/ vend de la
contrefaçon, supprimez immédiatement ce nom ») prennent rarement
en compte ce problème. Si on les écoutait, chaque fois que le
WordPress d'une mairie est piraté et sert à
du hameçonnage, on supprimerait le nom de
domaine, coupant ainsi l'accès des citoyens à leur ville.
Enfin, quatrième cas, le comment, quels composants de
l'Internet vont être utilisés pour le blocage. Cela peut être :
La machine terminale,
client ou serveur (ou pair, dans le cas du pair à
pair),Le réseau, par exemple les routeurs,Et un composant auquel on ne pense pas toujours, les
services de rendez-vous, comme le DNS ou
comme une DHT,
qui ne sont pas dans le chemin direct entre les machines
terminales, mais qui sont en général indispensables à
l'établissement d'une communication.
Par exemple, lorsque M. Michu veut accéder à
http://example.com/comment-partir-en-syrie
avec son navigateur Web, les machines terminales sont son
PC et le serveur
HTTP, le réseau, ce sont tous les routeurs
et autres équipements actifs sur le trajet, le service de
rendez-vous, c'est le DNS (par exemple le
registre de
.com). Autre exemple,
Alice appelle Bob en SIP, les machines
terminales sont le
smartphone d'Alice et le
PC de Bob, le réseau, ce sont tous les routeurs
et autres équipements actifs sur le trajet, le service de
rendez-vous, c'est le proxy SIP.
Dans l'exemple HTTP ci-dessus, on peut empêcher M. Michu de
regarder la page Web à de très nombreux endroits. Le RFC donne la
liste complète mais voici quelques extraits, aux trois endroits possibles :
On peut empêcher le navigateur de faire des requêtes vers
cet URL (c'est ce que font les
bloqueurs de pub),On peut configurer le réseau pour envoyer tout le trafic
vers le serveur dans un trou noir,On peut supprimer le nom de domaine example.com.
Le choix dépendra souvent de qui bloque. Si c'est l'utilisateur
(cas des bloqueurs de pub), il fera en général le blocage sur sa
machine terminale. Si c'est l'État, il utilisera plus souvent le
réseau ou bien le système de rendez-vous (s'il est sur son
territoire, ainsi, un
.com peut être saisi
par les autorités états-uniennes).
Le gros du RFC est représenté par la section 4, qui évalue les
différentes techniques. Les critères d'évaluation sont la
portée, la granularité,
l'efficacité et la
sécurité. Commençons par la portée (qui est
affecté).
Si je configure Shorewall sur ma machine
Linux pour bloquer le trafic vers
2001:db8:bad:1:ef5:34:aba1:96, je n'affecte
qu'une toute petite partie de l'Internet. Si le gouvernement des
États-Unis décidait de supprimer
.ir de la racine du
DNS, il affecterait bien plus de monde (« About
35,400,000 results » me dit
Google). D'une manière générale, le blocage
fait aux bords de l'Internet affecte peu de gens, celui fait dans
le réseau affecte beaucoup de monde, sans doute bien plus que ce
qui était nécessaire. Les exemples de « bavures » (le blocage
« bave » au delà de sa portée normale) sont nombreux, de l'Inde
censurant Oman, au célèbre cas de Pakistan Telecom bloquant
YouTube, en passant par la
censure chinoise débordant en Allemagne.
Le « bon » blocage devrait avoir la portée
la plus petite possible.
Et la granularité ? Est-ce qu'on pourra bloquer un service sans
bloquer les autres ? Par exemple, si une machine héberge un
serveur SMTP qui envoie du
spam, peut-on la bloquer sans empêcher
l'accès aux autres ressources qu'elle héberge, comme un serveur
HTTP ? Idéalement, là encore, on souhaite
que le blocage puisse être fait avec la granularité la plus fine possible.
Et l'efficacité ? Si on bloque, on veut qu'il ne soit pas
facile de « débloquer », c'est-à-dire d'accéder aux ressources
bloquées. Évidemment, si le blocage est fait par l'utilisateur
(comme dans le cas des bloqueurs de
publicité), pas de problème : il ne va évidemment pas
chercher à contourner ce blocage. Mais si le blocage est imposé,
l'expérience de l'Internet montre que les utilisateurs vont
chercher à le contourner (voir par exemple les articles
« Failures in a
Hybrid Content Blocking System » et
« Empirically
Characterizing Domain Abuse and the Revenue Impact of
Blacklisting »). Un service bloqué se déplace
facilement, comme le montre les fréquents changements de
TLD de
The Pirate Bay. Du côté client, les solutions
de contournement sont également nombreuses, du passage par
Tor, à l'utilisation de son propre résolveur DNS
pour contourner les résolveurs menteurs. Ces contournements mènent
parfois à une escalade puis à une course aux armements comme dans
le cas turc où le DNS
menteur était contourné par l'utilisation de Google Public DNS, ce qui avait mené au
piratage du routage de
Google. Un autre exemple de course aux armements est le
blocage des services par leur numéro de
port, poussant les applications à toujours
utiliser le port 80, celui de HTTP, poussant les bloqueurs à faire
du DPI, poussant les applications à
chiffrer, poussant les
bloqueurs à faire de l'analyse de trafic pour essayer de détecter,
sous le chiffrement, certains type de trafic, etc. Une telle
course ne peut pas avoir de fin.
Certains de ces contournements ont d'ailleurs des conséquences
pas forcément positives pour l'architecture de l'Internet. C'est
ainsi que beaucoup d'applications se pressent sur le
port 443, celui de
HTTPS, car il est rarement filtré. Ou bien
que des victimes d'un blocage de SIP
passent à des solutions fermées comme
Skype. Le RFC note au passage que le
chiffrement rend évidemment plus difficile
tout filtrage sélectif, et que cela va donc jouer dans la
diabolisation du chiffrement.
Dernier exemple de technique de contournement du blocage, citée
par le RFC mais jamais vue en pratique (mais elle amusera les
nerds), l'ajout
d'en-têtes d'extension dans les paquets
IPv6 (par exemple une option Destination) suffit souvent aujourd'hui à rendre
aveugles les filtres (ces en-têtes sont parfois difficiles à analyser).
Dans l'évaluation du blocage, reste la question de la sécurité :
les techniques de sécurité sur l'Internet cherchent à empêcher
toute interférence d'un tiers. Le blocage ne va-t-il pas entrer en
conflit avec ce souhait ? Techniquement, rien ne distingue une
attaque légale d'une attaque illégale : les mêmes techniques de
sécurité vont réagir contre les deux. C'est le cas des protocoles
qui visent (entre autres) à assurer l'intégrité des communications
(TLS - ou
IPsec - ). Lorsqu'on accède au site de sa
banque en TLS, c'est précisement pour
empêcher un tiers de modifier les données, justement ce que la
censure aimerait bien faire.
La sécurité sur l'Internet repose en général sur des techniques
de bout en bout, les seules sûres (). Certains blocages (comme le détournement des
sessions TLS) nécessitent d'insérer dans le
trafic un intermédiaire non prévu à l'origine, ce qui casse cette
sécurité.
La section 4 du RFC se penche ensuite sur les trois lieux où on
peut faire le blocage, le réseau, puis le rendez-vous, puis la
machine terminale. D'abord, le réseau, par exemple via un
pare-feu. Est-ce un bon endroit pour
bloquer ? Si on bloque dans un réseau périphérique, proche d'une
des machines terminales qui communiquent, la portée reste
faible. Si, par contre, on bloque dans l'épine dorsale d'un grand
réseau, la portée sera bien plus étendue (dans le cas d'une
censure volontaire, une portée importante n'est pas un défaut...)
Notez que le blocage dans le réseau nécessite que le réseau ait
accès à suffisamment d'informations pour prendre sa décision. Cela
peut mener à des pratiques comme le
DPI.
Notez qu'un filtrage dans le réseau peut être complexe car rien
ne dit qu'un point du réseau verra passer tout le trafic entre
Alice et Bob. Pour des blocages sommaires (« couper toute
communication avec 192.0.2.0/24 »), ce n'est
pas un problème. Mais cela interdit des choses plus subtiles, par
exemple de bloquer certains URI sur un site
Web mais pas tous. Le routage dans l'Internet étant ce qu'il est, un
point donné peut ne voir qu'une partie des paquets d'une même
communication. C'est d'ailleurs pour cela que les censeurs
essaient toujours d'obtenir que les réseaux soient architecturés
de manière à faciliter le blocage, notamment en limitant le nombre
de points de sortie vers l'extérieur et en empêchant l'asymétrie
du routage (en se moquant des conséquences que cela peut avoir
pour les performances et la fiabilité).
Quant à l'efficacité et la sécurité du blocage dans le
réseau... Le chiffrement suffit à gêner une
grande partie de ces blocages. Il ne laisse que quelques
métadonnées comme les
adresses IP, qui peuvent être trop grossières pour le système de
filtrage.
Et les techniques de contournement sont nombreuses, comme cela
a pu être vu dans
la lutte des ayant-droits contre The Pirate Bay. Le site
visé peut changer d'adresse IP, ou de nom, ses clients peuvent
passer par Tor ou par un
VPN, etc. Évidemment, plus le blocage reste
en place longtemps, plus les techniques de contournement se
développeront et seront déployées. Si on bloque dans le réseau,
c'est en général parce que les deux parties qui communiquent ne
sont pas d'accord avec ce blocage. Elles ont donc des bonnes
motivations pour le contourner et la lutte de l'épée et de la
cuirasse va donc durer longtemps.
Le bloqueur peut essayer de bloquer l'accès aux services qui
permettent un contournement. Par exemple, il peut interdire
TLS vers certains sites. Comme l'a montré le projet Telex, même cela n'est pas
forcément suffisant : on peut toujours, avec la participation d'un pair
accessible, faire des tunnels peu
repérables. Plus radical, le censeur peut interdire tout le
chiffrement (en France, des tas de politiciens ne demanderaient
pas mieux). Cela serait évidemment catastrophique pour la sécurité
de l'Internet.
Le RFC conclut donc que le blocage dans le réseau est en
général une mauvaise idée.
Bon, mais alors, se dit le censeur qui lit les RFC (cela doit
être rare...), pourquoi ne pas bloquer via les systèmes de
rendez-vous à la place ? En effet, on a beau parler de pair à
pair, presque toutes les communications réelles sur l'Internet
nécessitent un mécanisme mettant en rapport les machines de Bob et
d'Alice. C'est souvent le DNS mais cela
peut être un moteur de recherches (Pirate
Bay joue ce rôle, mettant en rapport un utilisateur de
BitTorrent et le contenu convoité) ou bien
d'autres mécanismes (comme les DHT ou une
blockchain).
Le blocage sur le service de rendez-vous est surtout utile pour
un État si ledit service est sous sa juridiction. Si vous utilisez
un .ly, vous dépendez
logiquement des lois libyennes. Si le service
est global (c'est le cas d'un registre de noms de
domaine), la portée du blocage est également
globale. C'est ce qui fait qu'un service légal dans son pays a pu
perdre son .com et
donc tous ses clients.
Si par contre le service est local (un résolveur DNS), la portée est
limitée aux utilisateurs de ce service.
Lorsque le système de rendez-vous est le DNS, la granularité du
blocage est mauvaise : supprimer le nom de domaine supprime tous
les services associés. Quant à l'efficacité, elle n'est jamais
parfaite (voir mon
article pour une étude sur le cas du DNS ou bien le
rapport de l'ISOC) : les
utilisateurs peuvent souvent changer de point de rendez-vous
(passer à un autre résolveur DNS, par exemple), d'autant plus que
la plupart des systèmes de rendez-vous n'ont aucune sécurité (des
techniques d'authentification comme DNSSEC
pour le DNS changeront peut-être partiellement les choses).
Un autre système de rendez-vous est souvent oublié : les
IRR et, d'une manière plus générale, le
mécanisme d'allocation d'adresses IP. Dans au
moins un cas (déjà cité plus haut), un
État a essayé de l'utiliser pour bloquer un service illégal.
En résumé, le blocage par action sur un service de rendez-vous
est simple (et donc tentant pour les autorités) car on n'agit que
sur un seul point, ou un petit nombre de points, mais n'est pas
très efficace et, comme il consiste à bricoler l'infrastructure de
l'Internet, il est dangereux pour le bon fonctionnement de
celui-ci.
Reste un dernier endroit, dans l'une des machines
terminales. Quelles sont les propriétés d'un blocage fait à cet
endroit ? À chaque instant, le logiciel installé sur ces machines
ou bien leur utilisateur prend des décisions sur le fait de
communiquer ou pas. Les utilisateurs choisissent (ou pas) de
cliquer sur un lien hypertexte. Le
logiciel
de messagerie décide si un message doit être montré ou
classé dans le dossier Spam. Netfilter
jette les paquets ou pas. L'utilisateur installe un nouveau
logiciel de communication (ou pas). Les choix du logiciel sont
guidés par l'utiisateur (cas d'un filtre
bayésien à qui l'utilisateur dit « ce message est un
spam ») mais le contraire arrive aussi (SafeBrowsing).
La portée d'un tel blocage est strictement locale. Si
j'installe Ghostery pour bloquer les
mouchards, cela n'affecte (en bien ou en mal) que moi.
La granularité est très fine : la machine terminale maitrise
tous les aspects de la connexion contrairement à, par exemple, le
serveur DNS, qui n'a aucune idée de pourquoi on demande ce nom de
domaine. Elle peut donc ne bloquer qu'un seul service. Encore
mieux si le blocage est fait dans l'application (le cas, là
encore, des bloqueurs de publicité) car ils ont la totalité de
l'information sur la connexion, sous une forme qui permet des
traitements sans ambiguité (cf. ).
L'efficacité est bonne. D'abord, puisque le blocage est décidé
par l'utilisateur, il ne va évidemment pas chercher à le
contourner. Ensuite, les services bloqués peuvent, évidemment,
essayer de s'adapter (le point de distribution d'un
malware va changer
souvent de nom de domaine et d'adresse IP, pour disparaitre des
listes noires) mais la machine terminale ayant une visibilité
complète (y compris de ces changements) est dans une meilleure
position que quiconque pour s'y adapter. Comme le blocage se fait
aux extrêmités, il ne gêne pas l'architecture de bout en bout
(chacun est bien sûr libre d'accepter de communiquer avec qui il
veut).
À noter qu'il existe deux extrêmités à la communication : le
blocage peut aussi être fait de l'autre côté, par le serveur (dans
le cas d'une communication client/serveur). Voici par exemple les
compteurs du nombre de paquets rejetés sur le serveur qui porte ce
blog. On voit que je n'accepte pas tout :-)
% sudo iptables -n -v -L net-fw
Chain net-fw (2 references)
pkts bytes target prot opt in out source destination
9360K 659M blacklst all -- * * 0.0.0.0/0 0.0.0.0/0
679K 49M smurfs all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID,NEW,UNTRACKED
9041K 625M tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
74720 11M Drop all -- * * 0.0.0.0/0 0.0.0.0/0
8881 631K DROP all -- * * 0.0.0.0/0 0.0.0.0/0
On peut faire la même chose de tas de façons. Par exemple, un
serveur HTTP comme
Apache a plein de techniques permettant
toutes sortes de blocages des visiteurs importuns. Et, évidemment,
pour bloquer un service entier sur le serveur, c'est très facile,
on ne fait tout simplement pas tourner le logiciel correspondant.
Bien sûr, ce blocage nécessite l'accord de la personne qui
utilise ladite machine terminale et les censeurs ne seront donc
pas enthousiastes à l'idée de lui demander.
Bref, le blocage sur une des machines terminales est de loin
celui qui a le moins de chances de causer des dommages
collatéraux sur l'Internet.
Comme tous les RFC, notre contient une
section dédiée à la sécurité, la section 5. Son point essentiel
est que le blocage dans le réseau ou dans les services de
rendez-vous est un danger pour la sécurité de l'Internet : il
s'oppose frontalement aux mesures de sécurité. Par exemple, pour
bloquer, on va essayer de casser le chiffrement, avec
une attaque de l'homme du milieu, comme le
font beaucoup d'entreprises, avec les produits de société comme
Blue Coat, en fabriquant de faux certificats
pour que les logiciels ne détectent pas cette attaque.
En outre, le système qui effectue cette attaque devient
lui-même une cible tentante pour un attaquant extérieur puisqu'il
donne accès à tout le trafic en clair. On a donc mis en péril
toutes les machines de l'entreprise en introduisant cette
« machine du milieu ». (En tant qu'ancien ingénieur
système, je suis également sensible à la remarque du
RFC comme quoi l'administrateur de cette machine court un gros
risque juridique personnel, puisqu'il va avoir accès à des tas de données sensibles.)
La conclusion du RFC (section 6) est que, si on tient à faire
du blocage, il faut le faire sur les machines terminales et
laisser le réseau tranquille, afin qu'il puisse faire son travail
avec rapidité et sécurité. Gageons que cet avis ne sera pas
suivi. Parmi toutes les discussions sur le blocage, le filtrage et
la censure, beaucoup de temps a été passé sur la légitimité ou non
de ces blocages (« si vous vous opposez à la Main Rouge, c'est que
vous sympathisez avec les terroristes ») et nettement moins sur
les conséquences techniques de ces blocages. En gros, si on veut
faire de la censure efficace, il faut ré-architecturer l'Internet
pour la censure et non pas pour la communication. (Cf. mon exposé à
l'Assemblée Générale de France-IX, et les
supports.)
Un des auteurs du RFC, Olaf Kolkman, a écrit
ses réflexions personnelles.