En fin d'année dernière, j'ai passé une semaine déconnecté à réfléchir, me reposer, me remettre en question et pour 2015, j'ai décidé de prendre plus de temps pour moi et mes relations avec les humains. Je m'explique.

Tout d'abord, le contenu du blog et ses mises à jour. J'écris moins depuis le début d'année. Ca se calme un peu. Ce blog prend la tournure d'être un support de tutoriaux/billets. Peut être qu'il y aura moins de billets "de réflexion personnels" (cf mon billet Ménage sur le blog et du fait que je prépare d'autres choses et que donc suis assez occupé. Mais ces billets ne vont pas disparaitre. Celui-ci est en un par exemple ;-) Le contenu intègrera plus mon modèle de menace actuel.

Je pense essayer de passer plus de temps dans le milieu associatif directement ou indirectement. Je pense m'investir un peu plus dans les communauté et mailing-liste auxquelles je me suis abonné (Mozilla, Ubuntu, pour ne citer qu'elles), et ce en diffusant/répondant des messages constructifs par mail, pour faire avancer les choses, éduquer, transmettre des connaissances que j'ai.

Je pense aussi essayer de plus interagir avec les réseaux sociaux (Twitter, Diaspora) ou des commentaires sur des billets de blog, là encore pour échanger, apporter des choses aux autres, et apprendre. Plus d'interaction ne veux pas dire devenir une activité chronophage. Je coupe Twitter régulièrement, je lis en diagonale rapidement ma timeline, j'ai fait du tri dans les RSS. Je consulte plus intelligemment. Par période/moment consacré/dédié dans la journée.Je réponds au mail, j'interagis avec vous, lecteurs, pour ceux qui m'écrivent. Et c'est cool.

Dans mes projets, je prépare des conférences/projets pour différents évènements à venir IRL (Ubuntu party, chiffrofêtes) pour que le week-end, je sois épanoui, je fasse ce que j'aime. Et je réfléchis à comment valoriser ces activités dans le futur, pour montrer qui je suis, ce que j'aime, ce que je sais faire, au-delà des lignes de mon CV qui reflètent ma carrière professionnel. En parlant de ça, je suis en train de me remettre à niveau en faisant des tutos/mini-projets persos de code pour me remettre dans le bain. Mais c'est là une autre histoire.

Et comment je fais pour gérer tout ça ? Je me suis remis au lifehacking pour mieux gérer mes journées. J'ai une todo-liste assez longue, je me consacre à une chose à la fois. J'optimise mes journées et j'ai du temps pour moi.

2015 ce sera pour moi une année d'interaction, de diffusion et de partage de connaissances. Aider les gens à comprendre comment fonctionne Internet (d'où mes billet sur le DNS), l'importance de préservation de la vie privée. Etre à l'écoute. Sortir du monde libriste, aller à la rencontre du grand public non informaticien, non technophile, pour l'aider à comprendre les technologies et enjeux du monde du numérique. L'aider à comprendre ce qu'est la censure sur Internet, en quoi soutenir la Quadrature du Net est important... Un vrai travail de fourmi, qui prend du temps, mais ça me plait. Et c'est là le plus important.

Ce billet fait partie des billets sur le thème du DNS.

Qu'est ce que le DNS ?

Sur le DNS, je vous invite à voir ma présentation DNS - Vulgarisation, où je dis, Les sites webs sont associés à des noms de domaines et se trouvent sur des serveurs (qui ont une adresse IP) et un serveur DNS est un annuaire qui fait la correspondance nom de domaine - adresse IP. Quand on tape une adresse url dans le navigateur, par exemple http://genma.free.fr, l'ordinateur va demander au serveur DNS quel est l'adresse IP du serveur où se trouve le site web demandé. L'ordinateur connait alors l'adresse IP du site web. Il peut alors envoyer des paquets ("Envoi moi la page d'accueil que je l'affiche", "Tiens voilà les login et mots de passe") et communiquer avec le site web.

DNS et vie privée

La notion de DNS leak ou fuite DNS en français correspond au fait que quand on utilise un VPN par exemple, les demandes aux serveurs DNS ne passent pas par le VPN. Le serveur DNS est donc interrogé directement. Quiconque écoute la connexion réseau peut donc voir ces demandes DNS et savoir quels sont les sites que l'on souhaite consulter.

De plus, si on utilise le serveur DNS de son fournisseur d'accès (ce qui est le cas par défaut quand on se connecte sur sa box Internet), celui-ci peut enregistrer la liste des demandes DNS et donc là aussi savoir les sites que l'on souhaite consulter. Il en est de même sur un réseau d'entreprise, encore plus quand on est derrière un proxy.

Résolution de DNS quand on est derrière un proxy ?

Pour cette partie, je me base en partie sur la traduction que je fais d'une réponse sur le message How to resolve the DNS locally when there is a proxy configured ? du site askubuntu.com.

Lorsque l'on utilise un proxy HTTP (comme c'est le cas en entreprise)
l'adresse IP à laquelle on se connecte et celle du proxy, pas celle de la destination finale
l'URL que l'on demande est l'URL complète (incluant le hostname) de la requête

De plus, c'est le proxy qui fait le DNS lookup. Ce n'est pas possible de faire le DNS lookup en local, et de seulement envoyer l'adresse IP au serveur proxy (pour qu'il fasse son travail de proxy et nous renvoie la page web) Il n'y a pas de mécanisme où on demanderait à un proxy de d'utiliser une adresse IP particulière pour un hôte particulier. On peut essayer de changer l'URL de, disons, http://example.com/mypage en http://33.33.33.33/mypage, mais le serveur proxy ne saura pas quel nom d'hôte demander. Le web moderne (HTTP / 1.1) dépend d'un en-tête où l'hôte est toujours présent dans la demande, ce qui permet à un serveur Web de servir pour plusieurs sites, qui seront alors identifiés par leur nom de domaine.

La seule possibilité est de configurer le serveur proxy pour qu'il utilise le résolveur DNS de son choix. Mais cela n'est possible que si on utilise un serveur proxy local que l'on contrôle, sur lequel on a la main.

Remarque : Lorsque l'on utilise un proxy SOCKS ou une autre méthode de tunneling de niveau inférieur, il est possible d'utiliser un serveur DNS local. Mais pas avec un proxy HTTP.

En quoi HTTPS apporte un peu d'inimité ?

Quand on se connecte à un site sur un site avec une connexion en Https, seul la première partie de l'URL est en clair. La liste des pages consultes, les arguments (les identifiants, mots de passe) etc. sont chiffrées et restent secrètes. (Sous réserve qu'il n'y ait pas d'Homme du milieu/Man in the Middle)

Il n'est donc pas possible de savoir quelles pages vous regardez sur le site (à moins de consulter l'historique dans votre navigateur ou les logs du serveur web en lui-même). On peut savoir via les demandes DNS que vous consultez un site, mais pas quelles pages sur ce site. Pour aller plus loin, je vous invite à consulter mes billet taggués Https et à faire usage de Tor via le TorBrowser, ce qui permet d'anonymiser sa connexion et de faire en sorte que le site web ne sache pas que vous le consultez (les logs ne tracent pas votre IP mais celle du noeud de sortie Tor).

Que fait un serveur DNS Local

Un serveur DNS local peut être utile pour avoir un peu plus d'intimité. Comme on est maitre du serveur DNS local, on sait quelles données sont conservées. Ce serveur DNS interroge directement les serveurs TLD (.fr, .com, .net) afin de stocker le résultat en local, ce qui est mieux pour la vie privée. Sur la mise en place d'un serveur DNS en local, je vous invite à lire le billet de Stéphane Bortzmeyer Son propre résolveur DNS.

A lire également :
Les Billets taggués Proxy

Note : nouveau billet de vulgarisation/simplification sur le thème des DNS. Simplifié donc potentiellement inexact, mais l'idée est là.

Rappel : Habituellement, un nom de domaine est associé à une adresse IP qui est celle du serveur et c'est le DNS qui permet de connaitre l'adresse IP du serveur, quand on tape une adresse URL dans la barre d'adresse (cf mes billets précédents sur le DNS)

Dans le cas d'un serveur dit "mutualisé", plusieurs dizaines de sites sont hébergés sur un même serveur et correspondent donc à une même adresse IP.

Dans ce cas là, comment ça marche ?

Le serveur Web est un logiciel (généralement Apache, mais il y a aussi nginx par exemple, ou d'autres). A ce logiciel est un associé un fichier qui permet de faire le lien en le sous nom du domaine (genma.free.fr dans mon cas) et un dossier du serveur (par exemple /home/genma/www/) qui contient l'ensemble des fichiers du site web. Ce fichier et son contenu, , c'est ce que l'on appelle les "virtual hosts" (Il s'agit donc d'un fichier de configuration du serveur apache).

Quand on demande l'adresse genma.free.fr, c'est un (ou plusieurs) serveur(s) DNS qui répondent et qui aiguillent alors le navigateur vers le serveur qui contient le site genma.free.fr. Quand on demande à ce serveur le site genma.free.fr, il redirige/aiguille vers le dossier correspondant de façon transparente, parmi tous les dossiers/sites qu'il héberge.

On a donc bien pour une même IP plusieurs domaines/sites webs de possibles.

Pour aller plus loin

Quand on crée un site chez Free.fr, sur les pages persos, des administrateurs font donc le travail suivant :
création du compte et association d'un espace disque pour héberger le site web, modification des virtuals host du serveur.
déclaration dans les serveurs DNS de l'association de l'adresse nouveaucompte.free.fr (celle du site web) avec l'adresse IP du serveur sur lequel ils ont créés le compte.
quand on demande l'adresse nouveaucompte.free.fr, les DNS savent donc répondre l'adresse IP du serveur mutualisé et le serveur mutualisé sait aiguillé vers le répertoire contenant les fichiers du site web.

Sur le sujet, de l'hébergement mutualisé chez Free.fr, pour compléter/approfondir Site en erreur 500 sur les pages perso de Free.

Ce billet fait suite à DNS - Vulgarisation et donne deux pistes pour sécuriser un peu plus ses connexions DNS voire les masquer. (Ce n'est pas un tutoriel sur comment mettre en place ces outils).

DNSSEC

Rappel sur DNSSec (issu du slide de DNS - Vulgarisation) DNSSEC permet de sécuriser les données envoyées par le DNS. DNSSEC signe cryptographiquement les enregistrements DNS et met cette signature dans le DNS. Ainsi, un client DNS méfiant peut récupérer la signature et, s'il possède la clé du serveur, vérifier que les données sont correctes. La clé pouvant être récupérée via le DNS lui-même. On valide que la correspondance "url-IP" que l'on reçoit est bien celle qui a été certifiée-validée et n'a pas été changée entre temps.

Comment utilise-t-on DNSSEC ? Issu de la page OVH - Vérifier que DNSSEC est correctement déployé pour votre domaine Vous pouvez installer une extension Firefox qui permet de vérifier si les sites que vous visitez sont sécurisés par DNSSEC, et si oui, quel est le résultat de la validation. Cette extension est disponible ici. Une fois installée, vous verrez une clé à gauche de la barre d'adresse du navigateur. Pour les domaines sur lesquels la clé est verte, l'IP du site a été vérifiée par DNSSEC.

Module Firefox de validation DNSSEC : ce site est sécurisé.

Si la clé est orange, c'est que le serveur DNS récursif de votre FAI n'est pas compatible DNSSEC. Ce n'est pas grave : vous pouvez utiliser des serveurs DNS alternatifs pour effectuer cette validation. Le module Firefox vous en propose une liste, à laquelle vous pouvez accéder en cliquant droit sur la clé, puis en sélectionnant "Preferences".

On valide que le site sur lequel on est le bon (bonne correspondance adresse IP - nom de domaine), mais quiconque surveille le trafic DNS a potentiellement vu la demande de résolution DNS et sait donc que l'on consulte ce site.

DNSCrypt

Pour éviter ça, il est possible d'utiliser DNSCrypt, qui chiffre les requêtes DNS et les réponses. Ce projet a été initié par OpenDNS, et il semble que d'autres fournisseurs proposent aussi le support de DNSCrypt. Avec DNSCrypt, il n'y a que le fournisseur de service (le résolveur DNS, OpenDNS) qui voit les requêtes et sait donc quel site on consulte, au lieu du résolveur de DNS et tout ceux qui écouteraient le trafic et les requêtes DNS effectuées sur le réseau.

Le site du projet http://dnscrypt.org/

Conclusion

Deux pistes à approfondir/tester pour avoir un peu plus de fiabilité en ce qui concerne le DNS. Une autre façon est de mettre en place son propre service de DNS en local. Un sujet là aussi à approfondir, sujet d'un futur billet je pense.

Dans mon billet, je FirefoxOS Localisation, Verrouillage, Effacer à distance, je parlais du service qu'offre Mozilla et j'évoquais le fait que je creuserai Les conditions d'utilisation du service. C'est chose fait et voici un petit billet de bilan ;

Firefox Cloud Services Privacy Notice

En cherchant la politique de Mozilla quand à l'usage des données personnelles, je suis arrivé sur cette page : Firefox Cloud Services Privacy Notice

Avec un paragraphe sur le service qui nous concerne :

Find My Device : If you enable Find My Device, we receive the approximate location of your device only when you sign into your Firefox Account and specifically request us to locate a connected device. While signed in, you can see your device's last known locations on a map. We regularly delete these locations and will not collect further locations until you request us to.

Ce que je traduirais par : Find My Device : si vous avez activé la fonctionnalité Find My Device, nous (Mozilla) recevons la localisation approximative de votre appareil uniquement lorsque vous vous connectez à votre compte Firefox et vous nous demandez explicitement de localiser votre appareil connecté. Une fois connecté, vous pouvez voir la dernière localisation connu de votre appareil connecté sur une carte. Nous effaçons régulièrement ces localisations et nous ne collectons pas d'autres localisations tant que vous ne nous le demandez pas.

Il n'y a pas plus d'information, cette page renvoyant vers les Mozilla Privacy Policy, en français.

Politique de confidentialité de Mozilla

Est donc disponible en français la Politique de confidentialité de Mozilla. J'ai lu le texte en entier, ce que je vous invite également à faire. Le texte est lisible et simple, c'est loin d'être du jargon juridique. Le tout tient en deux pages format A4.

Mozilla est donc susceptible de conserver et d'exploiter des données personnelles qu'on est susceptible de lui fournir, selon les conditions d'utilisation/autorisations qu'on lui accorde. Rien d'exceptionnel, rien d'anormal. On utilise Firefox, on a un compte Firefox. Mozilla connait notre login et notre mot de passe, notre mail et notre adresse IP. Mozilla connait donc des informations standards et nécessaires à l'usage de son service. Et l'exploitation qui en est faite et classique.

Analyses plus poussées

Le certificat Https sur le site, testé sur le site SSLLabs.com obtient un beau A vert, ce qui inspire plus que confiance dans le fait de se connecter sur le site (On prendra les précautions de rigueur : phrase de passe changée régulièrement, vérification que l'on est sur le bon site/bonne url etc).

Présence de tracker sur le site ? Ghostery ne signale pas de tracker sur la page https://find.firefox.com/ (pas de Google Analytic par exemple) et les pages que l'on consulte une fois connectée.

Si l'on regarde le code source des pages, on voit qu'il y a des références à https://api.tiles.mapbox.com/mapbox.js/ pour l'appel dun fichier CSS et d'un script javascript. On a donc une référence à un site extérieur...

Si on creuse, on voit que le site https://www.mapbox.com/developers/#javascript propose Mapbox.js Develop mobile and web applications with Mapbox.js, our open-source JavaScript library.

N'ayant pas réussi à faire afficher ma localisation (ni de carte), je ne saurai dire si les images des cartes proviennent du site www.mapbox.com (probablement que oui). Le fait qu'on demande une certaine zone géographique à ce site (pour le faire afficher par une IP donné) est d'une certaine façon une information personnelle... A voir si c'est gênant et si le site a cette information. A approfondir quand le service marchera pour moi.

Pour aller encore plus loin, il faudrait avoir le code source du site find.firefox.com, voir les appels des API etc... Mais on ne s'en sort plus ;-)

En conclusion

Si l'on utilise ce service, on doit faire "confiance à Mozilla". Rien que pour le code source de l'OS (qui est ouvert, que l'on peut compiler soi-même, mais personnellement j'utilise des Roms communautaires) par exemple. On pourra donc leur faire confiance sur le choix de Mapbox.com (ce n'est GoogleMap, c'est déjà ça...). A chacun de trouver le bon compromis entre le choix de l'usage de ce service et des fonctionnalités apportées et le fait que Mozilla sache où l'on est. Dans le cas où c'est un point gênant voir bloquant, on est dans une situation où on n'a pas de téléphone sur soi (voir pas de téléphone du tout). Personnellement, entre le fait que quelqu'un puisse avoir accès à des données personnelles s'il me vole mon téléphone et le fait que Mozilla puisse savoir où je suis, je choisis la solution deux : j'ai activé et je conserve la fonctionnalité qui me permettra de réinitialiser mon téléphone si j'en avais la nécessité.