Fin 2016, une amie souscrit un abonnement ADSL RED sans TV chez SFR. Le souci, c'est l'apparition récurrente d'un message d'erreur TLS sur « la moitié des sites visités » y compris sur Twitter et des sites web de paiement en ligne.
Le message d'erreur TLS en question ? « [censuré] uses an invalid security certificate. The certificate is only valid for the following names : *.numericable.fr, numericable.fr ».
Compte-tenu du contenu de ce message, on en déduit que l'erreur n'est pas du côté des sites web consultés. Sur un accès ADSL grand public, je prends le parti d'exclure d'entrée de jeu un MitM géant opéré par SFR-Numericable à l'encontre de ses abonné-e-s : j'en aurais entendu parler et surtout, il ne faut jamais expliquer par la malveillance ce que l'on peut expliquer par l'incompétence. Je sais que cette personne utilise le TOR browser. Je lui demande donc si cette erreur apparaît en utilisant le TOR browser. Réponse : non. Quelle différence cela fait-il ? Le TOR browser est pré-configuré pour, entre autres, résoudre les noms de domaine en passant par TOR.
Le problème vient donc de la configuration des serveurs DNS de SFR-Numericable. Mais pourquoi nous redirige-t-ils illégitimement vers un site web appartenant, probablement à ce stade de notre analyse, à Numericable ? Et quels serveurs DNS sont en cause ?
Ça n'est pas ce qui est demandé dans le cadre de la censure gouvernementale sans juge de sites web (voir https://www.laquadrature.net/fr/loppsi-definitivement-adoptee-internet-sous-controle, https://www.laquadrature.net/fr/pjl-terrorisme-le-parlement-peut-encore-sopposer-a-la-derive-securitaire et http://www.numerama.com/magazine/32530-islamic-news-a-ete-censure-pour-l-analyse-d-un-discours-publie.html ). Ça ne correspond pas non plus à ce qui se pratique en matière d'application des décisions de justice ordonnant le blocage de sites web (voir https://www.laquadrature.net/fr/loi-jeux-en-ligne-le-filtrage-du-net-adopte, http://www.lepoint.fr/high-tech-internet/censure-par-claude-gueant-copwatch-revient-24-01-2012-1422966_47.php ou http://www.numerama.com/magazine/32714-t411-bloque-en-france-ce-que-dit-le-jugement.html ). Cela ne correspond pas non plus aux pratiques courantes de DNS menteur. Alors quoi ?
La box de SFR, comme toutes, envoie des informations d'autoconfiguration de la connexion au réseau à tous les ordinateurs (y compris tablette, ordiphone, etc.) du foyer, Wi-Fi ou filaire, via le protocole DHCP. Parmi ces infos, il y a l'adresse des serveurs DNS récursifs à utiliser mais aussi… une liste de recherche (mais si, tu sais, l'option « search » dans un resolv.conf). Que fait cette option ? Supposons que t'ai une liste de recherche « search guiguishow.info ». Si tu saisis un nom de domaine incomplet (exemple : « test »), alors ton ordinateur cherchera le nom « test.guiguishow.info. ». Mais, que se passe-t-il si tu demandes un nom complet, « www.bortzmeyer.org » par exemple, mais que le serveur DNS récursif que tu utilises ne répond pas assez vite voire pas du tout ? Ton ordinateur cherchera alors le nom « www.bortzmeyer.org.guiguishow.info. ». SFR-Numericable fait précisément cela en autoconfigurant une liste de recherche « numericable.fr ».
Tu vas me dire « beh peut-être mais je pense que ni test.numericable.fr ni www.bortzmeyer.org.numericable.fr n'existent donc, dans mon navigateur web, j'aurais une erreur « Adresse introuvable », pas une erreur TLS ! ». Le bon sens voudrait que tu ai raison. Sauf que les serveurs DNS de SFR-Numericable qui font autorité sur tous les noms de domaines appartenant à SFR-Numericable sont configurés pour répondre une même adresse IP à toute demande portant sur <n'importe_quoi_ici>.numericable.fr. Exemples (depuis n'importe quelle connexion chez n'importe quel FAI) :
$ dig +short www.bortzmeyer.org.numericable.fr
82.216.111.15
$ dig +short xd.lol.mdr.ptdr.config.vaseuse.numericable.fr
82.216.111.15
$ dig +short rAvDSRH2YiwBRdjNyiBj3k29YoCNiTCpomz42xfu.numericable.fr
82.216.111.15
$ dig A \*.numericable.fr
; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> A *.numericable.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43662
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;*.numericable.fr. IN A
;; ANSWER SECTION:
*.numericable.fr. 902 IN A 82.216.111.15
;; AUTHORITY SECTION:
numericable.fr. 172166 IN NS ns2.numericable.fr.
numericable.fr. 172166 IN NS ns1.numericable.fr.
;; ADDITIONAL SECTION:
ns1.numericable.fr. 172166 IN A 82.216.111.75
ns2.numericable.fr. 172166 IN A 82.216.111.76
;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 14 15:07:56 CET 2017
;; MSG SIZE rcvd: 129
82.216.111.15 est une adresse IPv4 qui appartient à SFR-Numericable. Sur la machine (ou l'ensemble de machines) désignée par cette adresse IP, un serveur web est installé. Il est configuré pour répondre le même contenu à tous les noms de sites web <n'importe_quoi_ici>.numericable.fr. Quel est le contenu de ce site web ? Une redirection HTTP vers les offres commerciales de SFR-Numericable :
$ wget http://www.bortzmeyer.org
--2017-01-14 15:53:09-- http://www.bortzmeyer.org/
Résolution de www.bortzmeyer.org (www.bortzmeyer.org)… 82.216.111.15
Connexion à www.bortzmeyer.org (www.bortzmeyer.org)|82.216.111.15|:80… connecté.
requête HTTP transmise, en attente de la réponse… 301 Moved Permanently
Emplacement : http://www.numericable.fr [suivant]
--2017-01-14 15:53:09-- http://www.numericable.fr/
Résolution de www.numericable.fr (www.numericable.fr)… 82.216.111.15
Réutilisation de la connexion existante à www.bortzmeyer.org:80.
requête HTTP transmise, en attente de la réponse… 302 Found
Emplacement : http://offres.numericable.fr/ [suivant]
--2017-01-14 15:53:09-- http://offres.numericable.fr/
Résolution de offres.numericable.fr (offres.numericable.fr)… 82.216.111.15
Réutilisation de la connexion existante à www.bortzmeyer.org:80.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : non indiqué [text/html]
Pour tout nom de domaine qui n'est pas de la forme <n'importe_quoi_ici>.numericable.fr, on se fait dégager par le videur à l'entrée avec un code d'erreur 403.
Ça, c'est pour un site web consulté sans chiffrement. Mais, si au lieu de demander « http://www.bortzmeyer.org », on demande « https://paiement-en-ligne.exemple », c'est-à-dire qu'on active le chiffrement entre notre machine et le serveur (HTTPS) ? La résolution du nom nous répondra toujours la même adresse IP SFR-Numericable. On se connectera donc, en HTTPS, au même ordinateur appartenant à SFR-Numericable. Comme une connexion chiffrée nécessite que le serveur décline son identité, il répondra : *.numericable.fr, numericable.fr
(traduction grossière : « je suis <n'importe_quoi_ici>.numericable.fr ainsi que numericable.fr »). Notre navigateur web se rend alors compte de la supercherie : lui, il voulait causer avec paiement-en-ligne.exemple et il se retrouve avec un interlocuteur *.numericable.fr, numericable.fr
. Ça ne correspond pas, le navigateur sent l'arnaque et demande à l'utilisateur ce qu'il souhaite faire. Vérifions cette hypothèse :
$ curl https://www.bortzmeyer.org
curl: (51) SSL: certificate subject name '*.numericable.fr' does not match target host name 'www.bortzmeyer.org'
En revanche, si l'on met un seul composant avant « numericable.fr » (ce qui ne peut, en pratique, pas arriver à cause de « search »), on peut voir le contenu servi par le serveur web de SFR-Numericable : point de redirection ici, il s'agit de la page d'accueil normale de Numericable. Vous pouvez tester vous même : https://lol.numericable.fr/ .
Là, tu vas me dire « ben pourquoi le serveur DNS récursif de SFR-Numericable me répond lentement voire pas du tout ?! ». Ici, je peux seulement émettre des hypothèses :
Notons que la box de SFR-Numericable distribue bien l'adresse IPv4 de plusieurs serveurs récursifs DNS mais que cette redondance ne permet pas de mettre en échec l'effet indésirable de « search ».
Que faire ? Faire en sorte que la box n'envoie plus l'option « search » qui fout la grouille. Je n'ai pas de box, je suis donc incapable d'aider sur ce point. La ressource pointée par ce shaarli semble indiquer que cela n'est pas possible. Notons que même si c'était le cas, cela ne résoudra pas le problème de lenteur des serveurs DNS récursifs de SFR-Numericable. Pour corriger cela, il convient de ne pas utiliser ce service de résolution de noms au profit d'un autre.
De manière générale, il ne faudrait pas utiliser le serveur DNS récursif de son FAI. Cela n'est pas son boulot : il devrait vous fournir uniquement un tuyau et des adresses IP publiques, point. Pas d'adresse mail, pas de box, pas de TV, pas de téléphonie, pas de… Actuellement, il fournit un récursif DNS au même titre qu'il fournit une box : parce qu'un accès à Internet fourni sans cela est clairement inutilisable pour les débutant-e-s. Mais cela à un coût : ton FAI a alors une emprise supplémentaire sur toi : il peut te rediriger sur n'importe quel site web, t'empêcher de consulter tel ou tel site web, te mentir sur ce qui existe ou non sur le web, etc. Tout cela est expliqué ici : récursif DNS d'ARN, FAI associatif en Alsace.
Si tu changes de récursif DNS, cela signifie que tu fais intégralement confiance au prestataire du nouveau serveur. Pour respecter ta vie privée (le prestataire d'un service DNS récursif, voit la liste intégrale des sites web et de tous les services (mails, chat, etc.) que tu consultes, sans aucun chiffrement possible). Pour ne pas censurer de manière illégitime des pans entiers d'Internet. Évite donc d'aller donner encore plus ta vie privée à Google en utilisant Google Public DNS ou à Cisco en utilisant OpenDNS ou aux charlatans d'OpenNic. Une liste de récursifs DNS que j'estime être de confiance (mais je peux me tromper et je suis même juge et partie pour plusieurs d'entre eux !) : https://www.ffdn.org/wiki/doku.php?id=formations:dns .
« Et comment je change le récursif DNS que j'utilise ? ». Ce n'est pas aussi simple que ce que l'on essaye de raconter. Une liste de tutoriels fonctionnels sont listés ici : https://arn-fai.net/recursif#comment-changer-le-r-cursif-r-solveur-dns-que-j-utilise- .
Mais, chez l'amie en question, ça n'a pas été aussi simple car elle utilise Ubuntu. Or, Ubuntu utilise dnsmaq et resolvconf, autant de logiciels qui vont repasser derrière toi pour rendre inopérantes ta modification. Deux logiciels dont je ne peux pas tolérer l'existence et ce, depuis de nombreuses années.
resolvconf est un logiciel qui se désinstalle facilement : sudo apt-get autoremove --purge resolvconf
(et confirme le message qui demande un reboot) puis sudo rm /etc/resolv.conf
.
dnsmasq est une dépendance de network-manager-gnome donc il ne peut donc pas être désinstallé comme ça taktak. Pour le désactiver, il faut utiliser les commandes suivantes :
sudo sed -i 's/^dns=dnsmasq/#&/' /etc/NetworkManager/NetworkManager.conf
sudo service network-manager restart
Ensuite, effectue ton changement de récursif DNS en suivant ce tuto : https://doc.ubuntu-fr.org/dns#par_interface_graphique . Dans tous les cas (connecté-e en Wi-Fi ou non), déconnecte-toi et reconnecte-toi à ton réseau pour que le changement devienne effectif.
L'ensemble de la manipulation a pour effet de réécrire systématiquement et totalement le contenu du fichier /etc/resolv.conf. Comme on n'a pas rempli le champ « Domaines de recherche », aucune option « search » ne viendra se greffer dans notre configuration. Notons bien que c'est le cœur de la réussite de notre manipulation : changer simplement de récursif DNS tout en laissant une possibilité à l'option « search » de revenir ne produira aucun effet. Évidemment, il faut reproduire cette manipulation sur tous les ordinateurs du foyer.
ÉDIT DU 28/01/2017 À 13H50 : Et comment fait-on la même manip' avec Windows Vista/7/8/10 ? Il faut aller dans le « panneau de configuration » puis « Centre réseau et partage » puis « Modifier les paramètres de la carte » puis sélectionner la carte réseau Ethernet ou Wi-Fi puis sélectionner « Protocole Internet version 4 (TCP/IPv4) » puis cliquer sur « Propriétés ». Dans la nouvelle fenêtre, tu peux changer le récursif DNS que tu utilises. Mais pour résoudre notre problème, il faut cliquer sur le bouton « Avancé ». Dans la nouvelle fenêtre, il faut aller dans l'onglet « DNS ». Il faut cocher « Ajouter ces suffixes DNS (dans l'ordre) ». Ensuite, il faut cliquer sur le bouton « Ajouter ». Dans la nouvelle fenêtre, saisir « . » (sans les guillemets). Oui, saisir juste un point et valider. Enfin, il faut fermer toutes les fenêtre ouvertes en utilisant le bouton « OK ». C'est fait. Source : https://superuser.com/questions/93055/windows-using-the-dns-suffix-search-list-on-all-lookups-even-valid-fqdns-how-t/680359#680359 .
Pourquoi juste un point ? Car Windows ne permet pas (ni en utilisant l'interface graphique, ni en bidouillant le registre ni en utilisant les GPO) d'écraser, par une liste vide, la liste de suffixes fourni par la box via le protocole DHCP. On pourrait mettre un label qui n'a aucune chance d'exister un jour dans l'arborescence officielle de l'ICANN comme un nombre pris au hasard. Mais, la probabilité d'un conflit ne disparaît pas pour autant : les règles de l'ICANN peuvent changer, par exemple ou vous pouvez connecter votre ordinateur portable à un réseau dans lequel ce suffixe existe. Or, le point représente la racine de l'arboresence DNS : le nom shaarli.guiguishow.info s'écrit en réalité « shaarli.guiguishow.info. » et le point final est oublié dans le langage (et la représentation) courant par comodité. Cela ne changera pas aussi facilement. Conclusion : si ton Windows n'obtient pas de réponse des récursifs de SFR-Numericable, il reposera la question en la suffixant d'un point… Ce qui revient à poser la même question une deuxième fois.
Comment vérifier que la modification est effective ? Ouvrir une invite de commande (menu démarrer, accessoires, invite de commande). Avant la modification, la commande « ping rAvDSRH2YiwBRdjNyiBj3k29YoCNiTCpomz42xfu » doit indiquer « Envoi d'une requête 'ping' sur rAvDSRH2YiwBRdjNyiBj3k29YoCNiTCpomz42xfu.numericable.fr [ 82.216.111.15 ] avec 32 octets de données » même si aucune réponse à nos ping ne nous parviendra. Après la modification, la commande indiquera « La requête Ping n'a pas pu trouver l'hôte rAvDSRH2YiwBRdjNyiBj3k29YoCNiTCpomz42xfu. Vérifiez le nom et essayez à nouveau ». Autre moyen de vérifier : utiliser la commande « ipconfig /all ». Avant la manipulation, la ligne suivante sera affichée : « Liste de recherche du suffixe DNS.: numericable.fr ». Après la modification : « Liste de recherche du suffixe DNS.: ».
FIN DE L'ÉDIT DU 28/01/2017 à 13H50.
Cette histoire est une illustration concrète que l'option « search » de la bibliothèque de résolution de noms est une saloperie qui ne doit pas être utilisée (parce que derrière, il y a de vraies questions de sécurité) ainsi qu'une illustration qu'on ne peut pas faire confiance à nos gros FAI commerciaux bien connus pour fournir des services d'une qualité décente !
ÉDIT DU 14/01/2017 À 16H20 : corrections suite à une relecture de Stéphane Bortzmeyer. Merci. :) FIN DE L'ÉDIT.