Test de neutralité

Afin de participer à notre niveau à la neutralité du net pour tous, nous avons l'idée d'essayer de répondre à une problématique qui semble simple, comment détecter qu'un accès à Internet est neutre (ou pas) ?
Il faut pour cela mettre en place un test que l'utilisateur exécuterait sur sa machine connectée, et qui lui afficherait si oui ou non son accès Internet est neutre. En somme, s'il s'agit vraiment d'un accès au vrai Internet.

L'idée technique

L'analyse s'effectue en deux phases principales. La première, la plus rapide et simple à mettre en œuvre, se concentre sur la détection de dégradation (filtrage) "physique". Il s'agit notamment de vérifier si tous les ports sont bien ouverts, certains FAI ayant la fâcheuse tendance à fermer le 25 par défaut, voire tout ceux qui sont supérieurs à 1024.

Par exemple, voici un test TCP de votre propre navigateur web, utilisant simplement des urls de la forme http://neutral-http.aquilenet.fr:1234/good.png : neutral-http a un mini-serveur web ouvert sur tous ses ports, qui ne fait que produire une image. On peut ainsi tester très facilement n'importe quel port en remplaçant 1234 par n'importe quel nombre de 0 à 65535.

Attention

votre navigateur (notamment firefox, opera, chromium, ...) effectue éventuellement lui-même un filtrage !

Vous pouvez configurer Firefox pour corriger ce filtrage (about:config puis créer une nouvelle chaine de caractères nommée "network.security.ports.banned.override" et spécifier les ports désirés séparés par des virgules, ou une plage de port séparée par un tiret).

De même, désactivez éventuellement l'utilisation d'un proxy, car celui-ci n'accepte éventuellement pas l'utilisation de ports exotiques.

Voici un test en utilisant une résolution DNS normale (ne fonctionne pas si le mode "HTTPS only" est activé).

On a aussi sur une autre page de test de neutralité en IPv4 (en http), et une page de test de neutralité en IPv6 (en http)

On a enfin sur d'autres pages les mêmes tests en https: test de neutralité https avec résolution DNS normale,

Enfin sans résolution DNS en utilisant l'IP directement, test de neutralité https en IPv4, test de neutralité https en IPv6 (mais du coup, le certificat est invalide).

Test http en utilisant une résolution DNS normale

Port web (80):
Port web ssl (443):
Port web (8080):
Port ftp (20, 21):
Port ssh (22):
Port telnet (23, 992):
Port mail (25, 587, 465):
Port news (119, 563):
Port whois (43):
Port dns (53):
Port pop3 (110, 995):
Port imap (143, 220, 993):
Port rtsp (554):
Port echo (7):
Port 8:
Port discard (9):
Port dhcp (67-68):
Port netbios (137, 138, 139):
Port 1023:
Port 1024:
Port 1025:
Port openvpn (1194):
Port svn (3690):
Port WoW (3724):
Port bazaar (4155):
Port 4242:
Port emule (4662):
Port sip (5060, 5061):
Port jabber (5222, 5223, 5269, 5280):
Port irc (6666, 6667, 6668, 6697):
Port bittorrent (6969):
Port hg (8000):
Port git (9418):

Par ailleurs, nous fournissons un serveur "echo" sur neutral-echo.aquilenet.fr : tous les ports sont ouverts, et font tourner un simple cat, il suffit donc de s'y connecter avec telnet et d'essayer de taper quelque chose pour vérifier que le port passe bien.

Nous fournissons également des versions ssl sur neutral-https.aquilenet.fr et neutral-echos.aquilenet.fr.

La deuxième phase est le test "logique", c'est-à-dire la tentative de détection de bridages plus fins, comme le ralentissement sur certains ports, protocoles ou sites. Cette phase est concrètement très complexe à mettre en œuvre, les possibilités de bridage étant infinies. En effet, un FAI peut très bien choisir de ne brider qu'un seul site. La seule façon de le détecter étant de tester, on imagine bien le temps que prendrait ce test. L'idée d'approche est donc de ne tester que les sites et les protocoles les plus utilisés et les plus communément bridés (site Youtube et protocole Peer-2-peer par exemple). Mais un autre problème se pose, certains FAI, pour masquer leurs méfaits, n'activent le filtrage qu'au bout d'une certaine durée de connexion sur un site. Par exemple, un téléchargement de la dernière version de Debian en Peer2Peer fonctionnera très bien sur les 100 premiers Mo (ou sur les 10 premières minutes), puis le bridage s'activera et le téléchargement ralentira sensiblement. Ce genre de bridage est donc très long à détecter.

On peut par exemple essayer les outils référencés par Respect my Net.

Il apparaît donc clairement que la détection approfondie d'un bridage peut se révéler coûteuse en temps et en bande passante (communications réseau). L'approche serait donc de proposer des options dans le test, afin qu'un utilisateur lambda puisse vérifier en quelques minutes que son accès Internet est raisonnablement neutre. Ce mode ne testerait que les bridages "classiques". A l'inverse, un utilisateur avancé, technicien, aurait à sa disposition un outil capable de détecter finement des bridages discrets, à condition de le laisser fonctionner pendant plusieurs heures.

Techniquement parlant

Pour ce qui est de nos deux serveurs neutral-http.aquilenet.fr et neutral-echo.aquilenet.fr, il s'agit d'un simple serveur xinetd, avec quelques services:

service http
{
	type		= UNLISTED
	id		= http
	socket_type	= stream
	protocol	= tcp
	port		= 80
	user		= nobody
	wait		= no
	flags		= KEEPALIVE IPv6
	server		= /srv/http/uhttpd
}

service https
{
	type		= UNLISTED
	id		= https
	socket_type	= stream
	protocol	= tcp
	port		= 443
	user		= nobody
	wait		= no
	flags		= KEEPALIVE IPv6
	server		= /usr/bin/stunnel
	server_args	= /etc/stunnel/http-tls.conf
}                                                                               

# This is the tcp version.
service echo
{
	type		= INTERNAL
	id		= echo-stream
	socket_type	= stream
	protocol	= tcp
	user		= nobody
	wait		= no
	flags		= KEEPALIVE IPv6
}                                                                               

# This is the udp version.
service echo
{
	type		= INTERNAL
	id		= echo-dgram
	socket_type	= dgram
	protocol	= udp
	user		= nobody
	wait		= yes
	flags		= IPv6
}

# This is the TLS version.
service echos
{
	type		= UNLISTED
	id		= echos
	socket_type	= stream
	protocol	= tcp
	port		= 992
	user		= nobody
	wait		= no
	flags		= KEEPALIVE IPv6
	server		= /usr/bin/stunnel
	server_args	= /etc/stunnel/echo-tls.conf
}

Et voici le contenu du script uhttpd:

#!/bin/bash

PID=$$
(sleep 10 ; kill -ALRM $PID) &
WPID=$!

# Lire la requête
line=start
while [ -n "$line" ]
do
        read line
        line="${line%^M}"
done

kill $WPID

# Produire une réponse
echo -e "HTTP/1.0 200 OK\r"
echo -e "Server: uhttpd\r"
echo -e "Content-Type: image/png\r"
echo -e "Connection: Close\r"
echo -e "\r"
exec cat /srv/http/ok.png

Et voici les configurations stunnel:

exec = /bin/cat
key = /etc/stunnel/neutral.key
cert = /etc/stunnel/neutral.crt
debug = 2
TIMEOUTidle = 60

exec = /srv/http/uhttpd
key = /etc/stunnel/neutral.key
cert = /etc/stunnel/neutral.crt
debug = 2
TIMEOUTidle = 60

Début du projet

Lors d'une réunion, nous avons parlé de ce projet à nos amis FAI membres de la Fédération FDN. L'appel à projet commun est donc lancé, affaire à suivre. Pendant ce temps, nous continuons à nous tenir au courant des solutions et projets déjà existants, comme measurementlab, projet initié par Google.