PROJET AUTOBLOG


NullPointerException

Site original : NullPointerException

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Trackers first-party

mercredi 13 novembre 2019 à 00:00

Depuis le 07 novembre se déroule une nouvelle bataille contre le tracking publicitaire. Au cas où vous seriez passé à côté, vous trouverez un peu de détails ici, et . Cet article a vocation à éclaircir les choses de manière un peu plus posée et technique.

Tracker first-party ? Qu’es aquò ?

Le tracking tiers (third-party)

Quand un site internet veut organiser du tracking utilisateur sur son site, il n’héberge généralement pas directement le système de suivi sur sa propre infrastructure mais passe par un service clef-en-main en prestation, par exemple Google Analytics, ChartBeat ou Xiti.

La méthode habituelle pour intégrer ces systèmes passaient par de l’intégration dite « tierce partie ». Pour faire simple, le site principal demandait à votre navigateur d’aller chercher du contenu sur un autre domaine. Le contenu tiers est parfaitement visible et identifié sur cette capture d’écran : tout ce qui est en rouge est du contenu tiers (et ici bloqué par défaut grâce à µMatrix).

Libération

Mais ça, c’était avant…

Le tracking first-party

Suite à une annonce tonitruante de Libération qui se targuait d’être dorénavant plus blanc que blanc pour ses abonnés avec le retrait de tous les trackers publicitaires, j’ai procédé à une petite analyse de leur site une fois connecté en tant qu’abonné. Et j’ai obtenu sur la capture d’écran que vous avez vu plus haut.

Au premier coup d’œil, on voit déjà que la promesse n’est pas tenue. On pourrait à la limite concéder que ACMP ou ChartBeat n’est « que » du suivi d’audience et en gros ce qui ramène les subventions publiques (qui sont directement indexées sur leur fréquentation) chez Libération. Par contre, Google Analytics et Tag Commander (qui n’apparaît pas sur la capture d’écran, trop de trackers pour tout faire tenir sur une page…), on sort assez rapidement du pur suivi de fréquentation pour glisser franchement dans le marketing, pardon, la publicité…

Et d’un coup, un truc a commencé à me chafouiner…

Autant media, statics et www, je voyais plus ou moins à quoi ça pouvait correspondre et servir. Mais f7ds ? Allons faire un petit tour dans la console réseau de Firefox…

Eulerian

Eulerian

Hum, ça ne ressemble pas à grand-chose que je connaisse, et en tout cas ce n’est pas du contenu mais plutôt des informations qui partent à l’extérieur (résolution d’écran, nombre d’articles lus, durée des sessions…)

Voyons voir le DNS…

$ dig +short f7ds.liberation.fr
liberation.eulerian.net.
atc.eulerian.net.
109.232.197.179

Et boom… Eulerian… Dixit leur communication « Basée à Paris, Eulerian Technologies est une entreprise innovante française qui a, depuis 2002, construit une technologie de collecte de data e-marketing, qui permet d’analyser en temps réel des milliards de données ». Du bon bullshit comme on les aime ! Et bien entendu, pas de publicité hein… du « data e-marketing » SVP !

Ce type de tracking est appelé « first-party ». À l’inverse du contenu 3rd-party qui est hébergé sur un domaine différent du site principal, le tracking 1st-party provient directement du site visité lui-même.

Et alors, qu’est-ce que ça change en fait ?

Et bien tout…

Pour les outils de blocage

Le fonctionnement par contenu tiers a un gros avantage : il est visible ! Non seulement par les utilisateurs, qui avec des outils peuvent l’identifier rapidement, mais aussi par les outils de blocage, qui peuvent du coup maintenir à jour des listes de blocages. L’usage d’un service donné étant caractérisé par le même domaine quel que soit le site visité (Google Analytics reste google-analytics.com que vous soyez sur lemonde.fr ou liberation.fr), ces blocages sont extrêmement efficaces puisque globaux. Le détecter sur un site une unique fois et ajouter à une liste une seul fois protègera l’utilisateur sur tous les sites. Ce tracking first-party passe du coup complètement sous le radar puisqu’il est assimilé au contenu principal.

Le travail de blocage est beaucoup plus difficile que pour les 3rd-parties : on ne sait pas facilement dire « bloque tout eulerian.net ». En effet, tout se joue au niveau DNS et en particulier au niveau de la résolution du nom de domaine. Le client qui cherche à résoudre f7ds.liberation.net va demander à votre résolveur DNS (généralement celui de votre fournisseur d’accès) « Eh, pourrais-tu me donner l’IP correspondante ? » et va voir en réponse « C’est 109.232.197.179 ». À aucun moment le client n’est informé que sur le chemin se trouve un liberation.eulerian.net… C’est uniquement en interne que le résolveur DNS va faire le parcours f7ds.liberation.fr alias liberation.eulerian.net alias atc.eulerian.net alias 109.232.197.179. Et les outils de blocage n’ont du coup pas accès à cette information…

Ils ont par contre déjà commencé à réfléchir à des moyens d’action, mais les pistes actuelles sont peu engageantes. Les navigateur comme Chrome ne proposent a priori pas les API nécessaires. Côté Firefox on a le nécessaire, mais il va être nécessaire de refaire côté extension la résolution DNS faite côté navigateur. Même si du coup on devrait profiter à plein des systèmes de caches, le côté perte de performance pourrait être notable.

Si on veut réutiliser les outils existants, il va falloir identifier non plus les domaines finaux (eulerian.net) mais le domaine initial (f7ds.liberation.fr). Idem, des outils commencent à voir le jour pour analyser dynamiquement des listes de sites pour détecter les trackers et pouvoir les bloquer par liste comme auparavant.

En bref, tout l’ancien boulot réalisé sur le 3rd-party est à refaire pour le 1st-party… Trouver des moyens de détection, identifier les domaines en question, remplir des listes de blocage… Et tout prend des proportions une échelle au-dessus de ce qu’on connaissait côté 3rd-party. Les utilisateurs habituels de solution de blocage risquent fort de ne pas voir arriver de solution pérenne avant plusieurs mois voire années…

Pour noircir encore un peu plus le tableau, les nouveaux blocages sont beaucoup plus fragiles qu’en 3rd-party. Il suffira à un site de modifier ses domaines traçants, passer de f7ds à phai voire securite (Ne rigolez pas 01net l’a fait…), mettre des CNAME anonyme (déjà constaté sur 20minutes) ou par la suite passer directement d’un CNAME à un A/AAAA (la référence au prestataire disparaissant donc).

Pour la sécurité

Le fait que les trackers 3rd-party soient par définition sur un domaine qui n’est pas le domaine principal apporte aussi des protections au niveau du navigateur, via les limitations dites « Same Origin Policy ». L’hypothèse faite par les navigateurs est que si du contenu d’un sous-domaine du domaine principal, alors il est légitime et a globalement les mêmes droits que ce qui vient du domaine principal lui-même. Il a par exemple accès à vos cookies, peut exécuter du javascript ou accéder au contenu d’une iframe.

Idem, le « Content Security Policy » est mis à mal. Étant donné qu’il est rapidement compliqué de faire des règles très strictes, la plupart des sites généralistes se contentent de limiter la casse en bloquant tout sauf leur propre domaine. Et laissent du coup passer les 1st-parties avec, qui se retrouvent à nouveau avec les pleins pouvoirs…

Boursorama

Libération s’est pris les pieds dans le tapis à ce niveau. Leur cookie d’authentification djazsession fuite sur la requête vers Eulerian. N’importe qui là-bas peut donc récupérer ce cookie, l’intégrer à son navigateur via la console de développement et il est devenu vous, avec accès à votre compte client, votre nom, adresse, données bancaires… Ici on ne parle que d’un cookie et d’un journal, mais on peut imaginer des choses bien pires, par exemple une banque, sur une page de login, avec une régie pub verrolée qui enverrait du javascript pour relire votre identifiant bancaire… Ne rigolez pas trop, Boursorama court à la catastrophe avec ses 1st-parties…

Pour la réglementation

Toutes ces maniguances n’ont en réalité qu’un seul but : violer en long, en large et en travers le RGPD. Ces entreprises font tout pour éviter ce qu’elles redoutent le plus au monde, à savoir avoir à demander votre consentement pour pouvoir vous tracker.

Oui, parce que leur collecte est bien entendue complètement illégale… Et qu’ils savent bien que s’ils doivent réclamer le consentement des visiteurs, qui plus est en opt-in (donc sans action pas de tracking), c’est quasiment l’intégralité de leur trafic, et donc de leur business, qui disparaît instantanément…

Ils ont beau dire « c’est du marketing et non de la publicité », avoir découpé les bonnes anciennes régies pub en DMP/DSP/SSP/XChange/mCRM/trading-desk & j’en passe, ça n’en reste pas moins exactement les mêmes objectifs et données collectées qu’il y a 10 ans. Voire beaucoup plus, et bien plus précises.

Écosystème de la publicité
Écosystème du marché de la publicité

Les règles du jeu sont pourtant très claires : l’entrée en vigueur du RGPD depuis mai 2018 a quasiment rendu le consentement et l’opt-in (vous n’êtes pas tracké par défaut, vous devez faire une action spécifique pour vous retrouver tracker) obligatoire, alors que le régime de l’opt-out (vous êtes tracké par défaut, vous devez faire une action spécifique pour arrêter d’être tracker) prévalait auparavant.

C’est d’autant plus vrai dans le cadre du suivi d’audience, qui est le cas favori des 1st-party du moment, où les lignes directrices WP 247 sur l’application du RGPD sont claires et précises (page 18). Dès lors que vous faites un suivi des visiteurs (quels articles a lus untel ou quels mots-clefs intéressent untel autre) et non de votre contenu (combien de personnes a vu tel ou tel contenu), vous êtes sous le régime du consentement et non de l’intérêt légitime. Dès lors que vous externalisez ce suivi à un tiers, les restrictions sont draconiennes pour ne pas avoir à appliquer le régime du consentement.

Dans tous les cas observés aujourd’hui, ni l’une ni l’autre des conditions ne sont remplies et donc le régime du consentement et de l’opt-in s’applique. Le suivi est associé à un utilisateur, ne serait-ce que par la dépose d’un cookie spécifique au visiteur et collecte des données extrêmement personnelles (résolution d’écran, user-agent…), ce qui fait que l’hypothèse d’un pur suivi de contenu ne tient pas.

Dans le cas précis d’Eulerian, le CEO m’a écrit en personne qu’ils se servaient des données collectées pour recroiser avec le service des ventes.

CEO Eulerian

Les données collectées sont aussi en contradiction avec le WP 247 dans le cas de collecte par un tiers. Les IP ne sont ainsi pas anonymisées puisque l’accès au service en 1st-party se fait directement par le visiteur, c’est donc by-design que l’adresse IP complète file vers la collecte. Au moins via le recroisement avec l’après-vente, le cookie identifiant sert à d’autres finalités que la mesure d’audience et permet de remonter à une vente. L’opt-out n’est pas possible, et même lorsque le 1st-party en propose une, il s’agit généralement uniquement d’un opt-out pour les trackers en 3rd-party. Il ne peut de toute façon pas en être autrement, puisqu’un éventuel cookie d’opt-out déposé sur eulerian.net ne circule pas, lui, quand la ressource est visitée depuis f7ds.liberation.fr.

On sait pourtant faire les choses proprement, comme le prouve NextInpact avec son Matomo auto-hébergé en propre et configuré selon les exigences de la CNIL.

Comment se protéger ?

Eh bien c’est là que ça se gâte… Actuellement il n’existe pas de moyen simple et accessible de bloquer ce type de tracker…

Les outils type µBlock ne savent actuellement pas traiter le cas sinon devoir lister explicitement tous les domaines 1st-party. Le boulot est en cours mais ça va mettre un moment et comme dit précédement, c’est mort d’avance pour Chrome.

La solution d’utiliser µMatrix en mode paranoïa ie bloquer tout ce qui n’est pas issu directement du domaine visité est inutilisable, 99% d’Internet devenant immédiatement tout blanc et quasiment plus aucun site ne fonctionnant correctement. Ça a par contre l’avantage de prendre conscience de l’enfer qu’est devenu le web…

Une solution plus efficace est d’utiliser son propre résolveur DNS plutôt que de dépendre de celui de son FAI. Shaft a commencé à proposer un bout de solution ici. Pour la très grosse majorité des gens, c’est aussi une solution à peu près inutilisable encore une fois.

Du travail est aussi en cours du côté de Pi-hole, qui est éventuellement plus accessible pour le grand public que la solution précédente, mais reste quand même assez peu fréquente aujourd’hui.

Sur mobile, on n’en parle même pas, cet environnement risque d’être sans solution… On prie pour que Blokada trouve comment détecter les CNAME.

Pas grand chose de très efficace et encore moins pour le grand public donc… Tout ça reste bien plus complexe que les anciennes méthodes qui ne réclamaient que l’installation d’une extension de navigateur accessible à tous…

De biens jolies saloperies en perspective…

Streaming HLS

lundi 19 août 2019 à 00:00

Déjà 2 ans sans article de blog… On va corriger ça du coup !

Aujourd’hui, on va parler streaming, et surtout comment en faire avec (presque) que du logiciel libre et en tout cas en évitant au maximum les outils habituels privateurs et en proposant des alternatives auto-hébergeables et décentralisées pour tous !

Les problèmes du streaming « standard »

Le streaming « à l’ancienne » est généralement basé sur un flux TCP continu, type RTP, RTSP ou RTMP.

Ces formats fonctionnent plutôt bien tant qu’on a à disposition du matériel professionnel de diffusion, mais c’est généralement la croix et la bannière quand on veut faire avec du matériel classique comme on en a partout à la maison.

Le principal problème de ce type de flux est qu’il s’agit justement d’un flux ! Il faut une connexion permanente et stable entre le lieu de la captation et le serveur de streaming. Au moindre glitch réseau, généralement tout plante et il faut tout relancer, et dans le bon ordre. Ça suppose aussi des choses assez exotiques, type du multicast comme on en trouve dans la documentation officielle de ffmpeg, qui nécessitent en plus du matériel réseau compatible. Idem côté client, chaque client va devoir maintenir un flux constant ouvert, ce qui engorge rapidement le serveur. Et parler de cache ou de miroir sur du flux relève bien entendu de l’exploit voire de l’impossibilité…

L’autre problème, c’est qu’on trouve tout plein de solutions qui reposent sur un encodage des vidéos au niveau du serveur en face et non de là où est effectuée la captation. C’est par exemple le cas avec le module RTMP pour Nginx, qui prend un unique flux en entrée (généralement du 1080p) et le transcode dans les autres résolutions (720p, 480p, 320p, audio only…). Sauf que le transcodage, c’est TRÈS gourmand en ressources. 4 encodages « rapides » en parallèle occupent sans problème un i5-3450 à 100% et les mêmes en version standard un i7-8700K. Côté serveur, un CPU capable d’encaisser ça commence avec la gamme Xeon à plus de 250€ pièce, soit des machines en location à plus de 100€/mois. Inaccessible pour du grand public…

HLS à la rescousse !

Du coup, on veut trouver un système de streaming capable d’utiliser les ressources du lieu de captation et évitant d’avoir un flux permanent ouvert à la fois entre la captation et le serveur mais aussi entre le serveur et les clients. Et ça tombe bien, on a un format magique qui permet tout ça : HLS.

À la différence des fluxs précédents qui se basent directement sur TCP ou UDP, HLS repose sur le protocole HTTP. Les vidéos diffusées sont en fait découpées en tas de petits morceaux MPEG-TS de durée plus ou moins fixe (généralement quelques secondes), et le tout est servi de manière classique par le serveur web. La vidéo complète est reconstituée par les clients à partir d’un index M3U tout aussi classique et simple, qui donne l’ordre des morceaux.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:2350
#EXTINF:6.000000,
1080p/1566166537.ts
#EXTINF:4.000000,
1080p/1566166543.ts
#EXTINF:6.000000,
1080p/1566166547.ts

En bonus, le système est auto-adaptatif. Les fragments de toutes les résolutions étant disponibles, un client peut passer tranquillement d’une résolution à l’autre. Un autre index permet de déclarer les bandes passantes nécessaires pour chaque résolution, le client fera ses courses avec ce qu’il peut supporter.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=842x480
480p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p.m3u8

Aucune magie ni protocole compliqué pour la diffusion donc ! N’importe quel serveur web, y compris un Scaleway à 6 centimes de l’heure

L’encodage peut aussi se faire simplement sur la machine locale. On encode dans tous les formats souhaités, on envoie ça sur le serveur web par n’importe quel moyen à disposition (FTP, SSHFS, rsync, IPoAC…), et basta !

L’effet Kiss-Cool continue, puisque le tout étant uniquement du HTTP classique, il est parfaitement possible de mettre en place de la répartition de charge tout aussi classiquement, avec du HAProxy ou du DNS tourniquet ou des miroirs avec du Nginx en proxy inverse sur une source primaire avec un peu de cache pour soulager tout le monde.

Et ça continue encore et encore, parce que MPEG-TS étant du H.264, ça a le bon goût d’être supporté nativement par les navigateurs ! On trouve même un lecteur clef-en-main à intégrer sur un site Internet, histoire de pouvoir se passer des gros fournisseurs centralisés privateurs habituels.

OBS NDI

Il nous reste du coup un dernier problème à résoudre : dans le cas d’un streaming de jeu vidéo par exemple, on veut généralement réaliser l’encodage sur une machine différente de celle de jeu. L’encodage étant un processus très consommateur, il est en effet assez peu envisageable d’utiliser massivement un CPU déjà bien occupé et qu’on aurait plutôt envie de voir s’occuper du rendu du jeu…

Généralement, l’outil utilisé par les diffuseurs est OBS. Problème, par défaut il ne propose que des options nécessitant un encodage de la captation pour l’envoyer vers des serveurs de stream conventionnels (Twitch, Youtube, Periscope…) ou vers un ffmpeg distant (flux, multicast, tout ça tout ça…).

Heureusement, grâce à Palakis il existe une extension OBS-NDI utilisant le protocole (propriétaire… 😭) NDI. NDI a beau être propriétaire, son concepteur fournit un kit de développement y compris pour GNU/Linux. Ce protocole se base sur Avahi/Zeroconf pour la détection des sources et enchaîne ensuite avec des connexions TCP standard. Ceci permet l’envoi direct (sans encodage) du flux capté vers tout système causant NDI. Et ça tombe bien, ffmpeg supporte NDI depuis sa version 3.4.

Un avantage notable de NDI est de ne pas nécessiter un ffmpeg permanent à tourner en face. On lance OBS quand on veut, et c’est la machine en face qui s’y connectera quand elle souhaitera. On peut ainsi relancer le ffmpeg sans nécessiter d’intervention sur l’OBS, par exemple en cas de problème ou pour changer les paramètres d’encodage.

À noter que conséquence de l’usage de Avahi, NDI est un protocole réseau passant difficilement les pare-feu. En effet, après le requétage Zeroconf, un port réseau éphémère est ouvert pour chaque nouveau client qui arrive. Le premier client passera par le port 49152, le second par le 49153, etc. Veillez donc à désactiver vos pare-feu si vous utilisez ce protocole ou au moins d’ouvrir quelques ports à partir de 49152.

Mettons tout ça ensemble

J’ai fais le choix de Arch Linux pour monter une machine de stream, tout simplement parce que les dépôts AUR contiennent tout ce qu’il faut pour OBS, NDI & ffmpeg, contrairement à d’autres distributions où il sera nécessaire de beaucoup bidouiller pour tout faire fonctionner.

Il ne manque qu’un ffmpeg construit pour NDI, mais on peut facilement le compiler à la main une fois le SDK NDI installé :

git clone https://git.ffmpeg.org/ffmpeg.git --branch n4.2 --depth=1
cd ./ffmpeg
./configure --enable-gpl --enable-nonfree --enable-libndi_newtek --enable-libx264 --cpu=native
make -j8

Les invocations ffmpeg relevant plus du chamanisme que d’autre chose, j’ai simplifié le boulot dans quelques scripts :

Une diffusion se résume à lancer ./encode.rb (les 4 encodages HLS), ./encode.rb live (pour le stockage et Twitch) et ./rsync.py (pour l’envoi sur le serveur).

La configuration du serveur nginx est disponible ici, celle pour un éventuel miroir-cache et l’index m3u8 global ici.

Ces scripts sont basés en grosse partie sur des idées de Benjamin Sonntag qui utilise ce genre de méthode pour les solutions de streaming de Octopuce. Ils sont largement améliorables, en particulier pour sortir quelques paramètres un peu trop en dur à mon goût (l’adresse du flux NDI, l’adresse du serveur SSH…).

Je m’en sers régulièrement pour les diffusions de mon chaton, la machine d’encodage était un simple PC portable W251HUQ de chez Clevo, équipé d’un i5-2520M. En bande passante, comptez minimum 20Mbps, en dessous vous ne tiendrez pas la charge. C’est aussi ce système qui a assuré la diffusion de PSES 2018, sur un i7-8700K cette fois, et avec une carte d’acquisition BlackMagic DeckLink Mini Recorder (très GNU & ffmpeg compatible aussi).

Résumons donc. On a OBS qui s’occupe de la captation. Qui transmet tout ça via NDI vers un ffmpeg qui tourne sur une autre machine. ffmpeg en charge de l’encodage dans les formats souhaités. Un bon vieux rsync des familles pour envoyer les morceaux & index HLS vers un serveur web. Et enfin un nginx qui sert tout ça classiquement aux visiteurs.

Et voilà ! 😊

Le réseau Tor a besoin de vous !

mercredi 25 octobre 2017 à 00:00

Un petit billet rapide pour vous signaler que le projet Tor a besoin de vous !

Effectivement, le nombre de relais disponibles est en chute libre depuis cet été, ce qui est assez inhabituel et pas forcément bon signe pour la suite…

Tor metrics

Ce réseau a donc besoin de vous pour allumer tout plein de nœuds et ainsi redresser la tendance !

Par contre, il ne faut pas se lancer dans cette aventure sans un minimum de précautions et de prérequis, dont voici une petite liste, en particulier si vous êtes français.

Responsabilité juridique

En théorie, l’activité de gestion d’un relai Tor est protégée par la législation européenne et française et vous ne pouvez pas devriez pas pouvoir être poursuivi pour avoir opéré un nœud Tor, quel que soit le trafic que vous aurez relayé.

En effet, vous êtes protégé par l’article 12 de la directive européenne 2000/31/CE du 8 juin 2000 ainsi que par sa transposition en droit français, l’article L32-3-3 du Code des Postes et des Communications Électroniques. Comme vous ne modifiez, filtrez ou sélectionnez pas ce qui passe par votre nœud, vous n’avez pas à endosser la responsabilité du trafic. En clair, vous avez exactement la même position que les opérateurs de réseau « classiques » type Orange, OVH, Level 3 et tant d’autres.

Il n’empêche qu’en pratique, il existe un risque non nul de subir des désagréments oscillants de un peu génant à très fâcheux. Il est donc conseillé d’avoir à sa portée l’adresse d’un avocat, si possible spécialiste du domaine, afin de le contacter rapidement en cas de problème. Personnellement, j’ai maintenant toujours le numéro d’Alexandre Archambault.

Et on ne le rappellera jamais assez, en garde-à-vue

  1. Je garde le silence
  2. Je ne dis rien
  3. Je me tais
  4. Je demande à être assisté par un avocat
  5. Y compris si l’officier de police vous dit que ça ira plus vite sans

En effet, on est généralement dans une situation de stress ou en tout cas pas agréable, et donc on n’apprécie pas forcément correctement la portée de ce qu’on va dire et on peut complexifier sa défense par mégarde.

Ces situations délicates seront d’autant moins délicates qu’on sera nombreux à faire tourner des nœuds afin de rendre cette situation « normale » et non plus être perçus comme des criminels en puissance…

Déclaration ARCEP

En France, les systèmes de communications électroniques sont régulés par l’ARCEP, l’Autorité de Régulation des Communications Électroniques et des Postes.

En particulier, il existe une procédure vous permettant de vous déclarer opérateur de communications électroniques. Même si vous pouvez vous réclamer comme relevant de l’article 12 et de l’article L32-3-3 sans cette déclaration, avoir un tel statut officiel vous donnera toujours plus de poids pour faire valoir vos droits. Ce statut protège aussi votre matériel car il ne sera plus saisissable sans une procédure spéciale (ça n’empêchera pas une éventuelle saisie, mais ça sera un motif de nullité en plus).

La procédure en elle-même n’est pas compliquée et est accessible à un simple particulier sans structure juridique type auto-entrepreneur ou entreprise, mais l’ARCEP n’ayant pas (encore) trop l’habitude de gérer une simple personne physique, il faut (souvent) la relancer pour obtenir le précieux sésame à la fin.

Le dossier à renseigner n’est guère compliqué, une lettre de demande (dont vous trouverez un modèle ici si vous êtes en manque d’inspiration) et une copie de votre carte d’identité, et c’est tout. Vous sélectionnez juste « (Autre) Personne physique », vous contournez l’obligation de saisie du RCS/SIREN en indiquant votre ville de naissance (après tout, c’est bien là qu’on est immatriculé 😂).

Après quelques échanges de courriel ou d’appels téléphoniques avec l’ARCEP qui n’arrive pas à comprendre qu’on est juste un gens normal personne physique sans entité morale ni statut administratif et qui ne comprend pas plus qu’on fait ça bénévolement et sans engagement auprès de nos « clients », vous devriez obtenir votre n° d’opérateur.

Soyez aussi conscient que votre identité ainsi que votre adresse postale sera publiquement accessible dans la base de données des opérateurs.

Sélection du réseau

Le réseau Tor cherche avant tout à assurer une bonne diversité dans le réseau, afin d’éviter d’avoir trop de nœuds contrôlés/contrôlables par une même entité. Ce qui éviterait par exemple qu’une unique perquisition chez OVH et Online conduise à la disparition des 10 plus gros nœuds d’entrée dans le réseau…

Avant d’allumer votre propre nœud, consultez Metrics ainsi que Atlas pour voir quels sont les gros hébergeurs actuels et éviter ainsi d’en allumer plus chez eux.

C’est un peu un problème de la quadrature du cercle qui se pose sur ce sujet, puisqu’un nœud Tor intéressant (ie avec une bande passante importante) est plus que très consommateur en trafic (comptez 100To de données par mois pour un nœud à 300Mbps…). Or, hormis chez quelques trop rares hébergeurs illimités comme OVH, Online ou Hertzner, la bande passante ou le trafic est bridé ou (très fortement) facturé (comptez entre 500 à 1000€/mois pour 300Mbps au prix actuel du marché). Et donc tout le monde va mettre ses œufs dans les mêmes paniers…

Si vous avez la possibilité d’allumer votre nœud chez un AS peu couvert actuellement, faites-le !

Allumer le nœud

Afin de se prémunir d’un effet de bord (type une saisie du matériel), il est conseillé de faire tourner votre nœud sur une machine dédiée au nœud, et d’éviter autant que possible de le mélanger avec d’autres usages (Ou d’avoir des backups. Vérifiés. Avec un PRA. Vérifié). Jusqu’à récemment, on considérait que les nœuds les plus exposés aux ennuis étaient les nœuds de sortie, mais l’affaire Renault/Wannacry a montré que tous les nœuds sont susceptibles d’être impactés. Du plus risqué au moins risqué : exit, guard & bridge (ou plus exactement toute machine susceptible d’être directement contactée par un client Tor, comme par exemple les fallback directories) et enfin middle.

Toujours en vue d’éviter les problèmes, il est fortement recommendé de chiffrer intégralement le disque qui fera tourner votre nœud. Si vous utilisez un serveur dédié ou un VPS, vous pouvez vous inspirer de ce billet pour le faire à distance.

Vous pouvez ensuite passer à l’installation proprement dite de votre nouveau nœud.

Et enfin, toujours pour limiter la casse en cas d’effet de bord, vous pouvez durcir votre configuration pour utiliser des clefs d’identités offline et ainsi éviter qu’on puisse trop longtemps usurper l’identité de votre nœud en cas de saisie !

Stockage chiffré intégral sur serveur distant

samedi 22 juillet 2017 à 00:00

Vous n’aurez pas ma liberté de chiffrer (ni mes données) !

Suite à une petite mésaventure qui m’est arrivée à la mi-mai (je rédigerai peut-être un post-mortem un jour, tiens), j’ai dû encore plus renforcer ma paranoïa sur mes serveurs, et j’en suis dorénavant arrivé à devoir chiffrer intégralement mes disques durs, y compris pour mes serveurs distants.

Le problème est qu’autant chiffrer son téléphone, son PC de bureau et son PC portable est relativement simple, autant chiffrer une machine distante est une autre paire de manches ! En effet, au démarrage, vous n’aurez aucune possibilité d’avoir à disposition un écran et un clavier pour saisir votre phrase de passe ! Il va donc falloir ruser un peu et embarquer un serveur SSH dès le démarrage (avant même le déchiffrement des disques !) pour avoir un accès suffisant pour déverrouiller le reste et lancer le reste du système.

Personnellement, je reste chez Online malgré ma petite déconvenue, et donc j’ai repris le tutoriel initial d’installation d’une machine chez eux pour l’adapter à une version intégralement chiffrée des disques durs.

Histoire de corser un peu le tout, j’ai en plus décider de passer tout mon système sous LVM, et en prime de faire du thin provisionning, ce qui permet un meilleur usage des ressources sur le disque.

Les tutoriels sur le sujet disponibles sur le net ont tendance à un peu trop bidouiller le système, surtout que Debian a (presque) fait le nécessaire pour que tout fonctionne nativement.

Donc voici ma recette personnelle.

Procédure

Comme pour l’ancienne procédure, tout va se passer en mode secours Online. À défaut d’avoir du Debian de disponible, choisissez une version récente d’Ubuntu (à l’heure actuelle, la 16.04).

Étant donné qu’on va faire du chiffrement de disque, je préconise de faire au moins une passe complète d’écriture aléatoire sur vos disques, afin de minimiser encore plus les informations accessibles par un attaquant. Vous pouvez utiliser shred ou pour aller plus vite, un petit outil que j’ai commis en ruby.

Une fois connecté en SSH, on commence par installer les outils nécessaires. Il va y avoir des erreurs à l’installation, c’est « normal » et ça ne bloquera pas la suite.

apt update
apt install -y dialog
apt dist-upgrade -y
apt install -y cryptsetup lvm2 thin-provisioning-tools debootstrap debian-archive-keyring

On passe ensuite au formatage proprement dit. J’ai choisi de faire une partition (nécessairement) en clair de 1G pour mon /boot, puis tout le reste du disque en tant que physical volume LVM. Si vous faites du LXC, vous pouvez faire deux PV LVM, un pour le système et un pour vos machines virtuelles. Vous pouvez bien entendu adapter les logical volumes à vos besoins.

swapoff -a
vgchange -a n

/sbin/parted -a optimal --script /dev/sda mklabel msdos
sfdisk /dev/sda <<EOF
/dev/sda1 : size=1G, type=83, bootable
/dev/sda2 : type=e8
EOF

cryptsetup -q luksFormat --verify-passphrase --hash sha256 --key-size=512 --cipher aes-xts-plain64 /dev/sda2
cryptsetup luksOpen /dev/sda2 crypt_system

pvcreate /dev/mapper/crypt_system
vgcreate system /dev/mapper/crypt_system
lvcreate -l 100%FREE --type thin-pool --thinpool system system
lvcreate --thin --virtualsize 10G  -n root system/system
lvcreate --thin --virtualsize 20G  -n var  system/system
lvcreate --thin --virtualsize 10G  -n log  system/system
lvcreate --thin --virtualsize 10G  -n home system/system
lvcreate --thin --virtualsize 100G -n srv  system/system
lvcreate --thin --virtualsize 1G   -n swap system/system

mkfs.ext4 -F /dev/sda1 -L boot -m 0
for d in root var log home srv; do mkfs.ext4 "/dev/system/${d}" -L "${d}" -m 0; done
mkswap /dev/system/swap -L swap

On monte ensuite tout ça et on lance la création du nouveau système Debian.

mount /dev/system/root /mnt
mkdir -p /mnt/{boot,var,tmp,home}
mount /dev/sda1 /mnt/boot
mount /dev/system/var /mnt/var
mkdir -p /mnt/var/log
mount /dev/system/log /mnt/var/log
mount /dev/system/home /mnt/home
mkdir -p /mnt/srv
mount /dev/system/srv /mnt/srv

debootstrap --arch=amd64 --variant=minbase stretch /mnt http://deb.debian.org/debian/

mkdir -p /mnt/{proc,sys,dev}
for i in proc sys dev; do mount -o bind "/${i}" "/mnt/${i}"; done

On est alors prêt à configurer le minimum vital pour un démarrage correct.

chroot /mnt

cat > /usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF
chmod +x /usr/sbin/policy-rc.d

rm /etc/apt/sources.list
mkdir -p /etc/apt/sources.list.d
cat > /etc/apt/sources.list.d/debian.list <<EOF
deb http://deb.debian.org/debian/ stretch main contrib
deb http://deb.debian.org/debian/ stretch-updates main contrib
deb http://deb.debian.org/debian/ stretch-backports main contrib
deb http://deb.debian.org/debian-security/ stretch/updates main contrib
EOF
cat >/etc/apt/apt.conf.d/60recommends <<EOF
APT::Install-Recommends "0";
APT::Install-Suggests "0";
EOF
apt update
apt dist-upgrade -y

mkdir -p /etc/network/interfaces.d
echo "source-directory /etc/network/interfaces.d" > /etc/network/interfaces
cat > /etc/network/interfaces.d/lo <<EOF
auto lo
iface lo inet loopback
EOF
cat > /etc/network/interfaces.d/enp0s20f0 <<EOF
auto enp0s20f0
iface enp0s20f0 inet static
	address X.X.X.X/24
	gateway X.X.X.1
iface enp0s20f0 inet6 static
	address XXXX:XXXX:XXXX:100::1/56
	pre-up dhclient -cf /etc/dhcp/dhclient6.enp0s20f0.conf -pf /var/run/dhclient6.enp0s20f0.pid -6 -P enp0s20f0
	pre-down dhclient -x -pf /var/run/dhclient6.enp0s20f0.pid
EOF

echo pony > /etc/hostname
hostname -F /etc/hostname

cat > /etc/hosts <<EOF
127.0.0.1       pony.example.org pony
127.0.0.1       localhost

::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
EOF

mkdir -p /etc/dhcp/
cat > /etc/dhcp/dhclient6.enp0s20f0.conf <<EOF
interface "enp0s20f0" {
	send dhcp6.client-id XX:XX:XX:XX:XX:XX:XX:XX:XX:XX;
	request;
}
EOF

cat > /etc/fstab <<EOF
proc				/proc			proc	defaults			0	0
sysfs				/sys			sysfs	defaults			0	0
cgroup				/sys/fs/cgroup	cgroup	defaults			0	0
tmpfs				/tmp			tmpfs	nodev,nosuid,nodev,noatime,size=1G	0	0
$(blkid /dev/disk/by-label/swap | awk '{print $3}' | tr -d '"')	none	swap	swap	0	0

$(blkid /dev/disk/by-label/root | awk '{print $3}' | tr -d '"')	/			ext4	errors=remount-ro,noatime	0	1
$(blkid /dev/disk/by-label/boot | awk '{print $3}' | tr -d '"')	/boot		ext4	defaults,noatime			0	2
$(blkid /dev/disk/by-label/var | awk '{print $3}' | tr -d '"')	/var		ext4	defaults,noatime			0	2
$(blkid /dev/disk/by-label/log | awk '{print $3}' | tr -d '"')	/var/log	ext4	defaults,noatime			0	2
$(blkid /dev/disk/by-label/srv | awk '{print $3}' | tr -d '"')	/srv 		ext4	defaults,noatime			0	2
EOF

cat > /etc/crypttab <<EOF
crypt_system $(blkid /dev/sda2 | awk '{print $2}' | tr -d '"') none luks
EOF

apt -y install dialog locales
apt -y install localepurge
localepurge
dpkg-reconfigure localepurge
apt -y install bash-completion less rsyslog unbound systemd-sysv kbd console-setup console-data net-tools isc-dhcp-client

Jusque-là, pas grand-chose de très nouveau par rapport à la version non chiffrée. C’est à partir d’ici que les choses vont se gâter un peu.

On va maintenant installer le nécessaire pour que le système embarque un serveur SSH léger, dropbear et réclamer à initramfs d’embarquer tout ça et de monter les interfaces réseau au démarrage histoire qu’on puisse se connecter, alors que nos disques durs ne seront pas accessibles à ce moment-là !
Deux difficultées réelles ici. dropbear ne supporte pas encore toutes les possibilités de SSH. En particulier, il ne tolère pas les clefs ED25519. Vous devez donc utiliser soit une ECDSA, soit une RSA. Et côté Debian, thin-provisioning-tools ne déploie pas nativement de hook sur initramfs, ce qui fait qu’il n’est pas embarqué. Il faut donc penser à patcher un peu à la main.

apt -y install lvm2 thin-provisioning-tools cryptsetup dropbear busybox ifupdown
apt -y install linux-image-amd64 linux-headers-amd64 grub2

cat > /etc/dropbear-initramfs/authorized_keys <<EOF
ecdsa-sha2-nistp521 xxxx you@example.org
EOF

cat >> /etc/initramfs-tools/initramfs.conf <<EOF
IP=X.X.X.X::X.X.X.1:255.255.255.0::enp0s20f0:off
EOF

cat > /etc/initramfs-tools/hooks/thin-provisioning-tools <<EOF
#!/bin/sh

PREREQ="lvm2"

prereqs() {
	echo "$PREREQ"
}

case \$1 in
prereqs)
	prereqs
	exit 0
	;;
esac

[ ! -x /usr/sbin/cache_check ] && exit 0

. /usr/share/initramfs-tools/hook-functions

copy_exec /usr/sbin/thin_check
copy_exec /usr/sbin/thin_dump
copy_exec /usr/sbin/thin_repair
copy_exec /usr/sbin/thin_restore
copy_exec /sbin/dmeventd

manual_add_modules dm_thin_pool
EOF
chmod +x /etc/initramfs-tools/hooks/thin-provisioning-tools

update-initramfs -uk all

On finit par tout nettoyer et préparer pour le reboot.

systemctl enable getty@ttyS1.service
systemctl disable dropbear

rm -f /usr/sbin/policy-rc.d

cat > /etc/resolv.conf <<EOF
search example.org
domain example.org
nameserver ::1
nameserver 127.0.0.1
nameserver 62.210.16.6
nameserver 62.210.16.7
EOF

mkdir -p /root/.ssh
cat > /root/.ssh/authorized_keys <<EOF
ssh-ed25519 xxxx you@example.org
EOF

passwd

exit

On démonte tout ça, et hop, reboot !

for i in dev sys proc var/log var home srv boot ""; do umount "/mnt/${i}"; done
vgchange -a n
cryptsetup luksClose crypt_system

reboot

« Normalement », vous devriez pouvoir vous connecter à votre serveur en cours de démarrage en SSH, puis pouvoir lancer le déchiffrement des disques avec cryptroot-unlock. Vous saisissez votre phrase de passe et votre machine va continuer son processus de boot normal (ça peut prendre un peu de temps, soyez patient !).

En cas de problème

Cette procédure est particulièrement galère à debugger quand ça ne fonctionne pas. Parce que votre serveur n’est plus capable de rien et risque même de ne pas booter du tout.

Il est donc conseillé de redémarrer votre machine en gardant un œil sur son KVM IP ou sa console série.

Pour corriger une erreur, vous devrez redémarrer en mode secours, déchiffrer vos disques et les monter.

apt install -y cryptsetup lvm2 thin-provisioning-tools
cryptsetup luksOpen /dev/sda2 crypt_system
vgchange -a y
mount /dev/system/root /mnt
for i in proc sys dev; do mount -o bind "/${i}" "/mnt/${i}"; done
chroot /mnt
mount -a
…
umount -a
exit
for i in dev sys proc ""; do umount "/mnt/${i}"; done
vgchange -a n
cryptsetup luksClose crypt_system
reboot

En piste de trucs qui peuvent merder sur l’initramfs :

Bon courage à vous !

Réflexion autour de l’auto-hébergement et des CHATONS

vendredi 21 juillet 2017 à 00:00

Après ma grosse réflexion autour du logiciel libre, une nouvelle réflexion autour de l’hébergement. Une nouvelle fois, elle a été initiée suite à la publication d’un billet de blog et d’un flux twitter

L’(auto-)hébergement est-il trop compliqué ?

Dans l’article initial, l’auteur fait le constat que les solutions actuelles de cloud personnel (Own/NextCloud & CozyCloud) sont complexes à installer et qu’il faut des connaissances en administration système si on souhaite héberger ça à la maison.

En pratique, on ne peut pas lui donner tort. C’est effectivement compliqué. Voire beaucoup. Et même des personnes plutôt compétentes se prennent régulièrement les pieds dans le tapis.

Mais à la réflexion, cette complexité est en réalité normale.

Un éco-système de facto complexe et unique

On parle d’installer des systèmes complexes, composés de beaucoup de sous-composants. Outre l’application en elle-même, il y a quasiment toujours besoin d’un serveur de courriel, d’une base de données, d’un serveur web, de gérer des certificats X.509, un nom de domaine, de mettre les mains dans le réseau… Certains morceaux sont même d’un niveau tel que même les « experts » du domaine se prennent régulièrement des claques et commettent des erreurs (le courriel, TLS ou DNS, si vous m’écoutez…).

En fait, il est même quasiment impossible d’avoir une recette miracle qui va s’adapter au contexte de l’hébergement final. Les configurations sont trop diverses, en particulier sur tout ce qui touche au réseau (FAI différents, box ADSL ou fibre différents…), pour espérer pouvoir gérer un service sans un minimum de configuration différentes.

Vous êtes chez Free ? Vous avez peut-être seulement une demie-IP à disposition. Vous êtes chez Bouygues ? Vous ne pouvez juste pas envoyer de courriel. Chez OVH le réseau local est en 192.168.1.0/24 mais en 192.168.0.0/24 chez Free voire en 10.0.0.0/24 sur certaines configurations Bouygues. Et je ne parle même pas des manipulations complètement différentes dépendantes du modèle du modem et de la version de son firmware pour configurer le NAT et ouvrir les ports nécessaires à l’utilisation du service. Ouverture de port qui nécessite d’assigner une IP fixe au périphérique, ce qui est déjà hors de portée d’un utilisateur lambda. On pourrait aussi parler de la gestion d’un nom de domaine histoire de pouvoir taper autre chose que des IP pour accéder à son service. Ou encore du problème d’hairpinning qui empêche sur certaines configurations d’accéder aux ressources internes d’un réseau à partir de son adresse externe si on est à l’intérieur du réseau.

Bref, on n’a pas le cul sorti des ronces… Parce qu’on n’a même pas commencé à effleurer le problème en fait…

Un nécessaire besoin de compétences et de connaissances

Une fois qu’on aura le bagage nécessaire pour comprendre l’environnement dans lequel va évoluer son service (notions de TCP, DNS…), il va falloir maintenant comprendre comment interagir correctement avec lui (qui doit communiquer avec qui, comment et pourquoi). Comment emboîter toutes les briques pour que tout fonctionne. Comment debugger en cas de problème (et les problèmes dans le monde réseau sont toujours très difficiles à cerner). Y intégrer des notions de sécurité, de mises-à-jour régulières, etc.

Bref, sans compétence, ça va être difficile et complexe. Très.

Prenons un exemple « simple ». Il existe un outil, ZMap, capable de scanner tout Internet (en fait tout IPv4) en quelques heures. Oui, vous avez bien lu. Tout Internet. J’ai déjà joué avec pour lister les serveurs VNC accessibles par exemple. Des chercheurs font tourner cet outil en permanence pour analyser comment Internet est construit. Et ont même créé des outils très accessibles pour rechercher parmi les données récoltées, comme Censys ou Shodan. Le rapport avec la choucroute me direz-vous ? Et bien qu’il devient très facile de lister les instances YunoHost publiques, ou celles de OwnCloud, de NextCloud ou de CozyCloud. En cas de faille de sécurité sur une de ces solutions, il se pose alors deux problèmes :

Comment éviter ces problèmes ? Facile ! Très facile même. Ne pas apparaître dans Shodan et associés. Comment fait-on en pratique ? Oups… Vous êtes bien assis ? C’est parti !

Il « suffit » d’avoir un hôte virtuel par défaut qui n’indique rien de ce qui tourne réellement sur la machine. Ainsi, quand ZMap va passer et vu qu’il ne se base que sur l’IP de la machine visée, il va tomber sur une page sans information utile. Il faut aussi penser à lui assigner un certificat X.509 neutre, puisque si vous y mettez un certificat avec tous les autres domaines de votre machine (par exemple via du SAN), ZMap utilisera ces informations pour refaire des connexions réseaux correctes et lister les services qui tournent. Du coup, il vous faudra aussi un nom de domaine donc, puisque l’accès par votre IP directe ne mènera à rien. Donc mettre la main dans le DNS, au moins via votre bureau d’enregistrement. Du coup, cela nécessite aussi que l’installeur de votre solution ne soit plus 100% automatique, mais vous pose quelques questions pour pouvoir se configurer, au pif pour connaître votre nom de domaine. Mais alors, comment je fais pour me connecter à l’installeur à la première utilisation ? Zut, il va falloir que je trouve l’adresse IP qui va être assignée par la box. Donc trouver l’interface de gestion fournie par le FAI, comprendre où est le nouveau matériel pour enfin pouvoir s’y rendre via son navigateur web et enfin pouvoir configurer son service.

On récapitule ? Pour corriger ce simple problème qui relève des bonnes pratiques courantes pour un administrateur système, pour un utilisateur lambda il va falloir savoir acquérir un certificat X.509 correct (ce qui est un parcours du combattant à lui tout seul…), maîtriser sa box Internet et son interface d’administration pour trouver l’IP de départ du service et ouvrir les ports nécessaires, savoir répondre à la question « Quelle adresse IP libre de votre réseau souhaitez-vous assigner à votre service ? », trouver l’adresse IP publique de sa connexion (en espérant qu’elle soit statique et non dynamique…), savoir acquérir un nom de domaine, configurer son nom de domaine pour l’associer à l’IP publique, pour enfin avoir son service opérationnel… Et tout ça n’est absolument pas automatisable, puisque dépendant de bouzillions de contextes différents (OVH, Free ou Bouygues en FAI ? Let’s Encrypt ou Gandi pour X.509 ? OVH, Gandi ou Online pour votre nom de domaine ?).

Et en cherchant à simplifier le processus, on le complexifie encore plus… Exemple ? On simplifie la vie de l’utilisateur en installant ZeroConf pour éviter qu’il n’ait à chercher le service via l’interface de sa box mais directement en tapant mon-service.local. Problème ? ZeroConf se retrouve exposé sur Internet…

mDNS
mDNS ouvert sur un YunoHost

Et du coup l’installeur devrait en plus réclamer que l’utilisateur soit en mesure de lui indiquer le sous-réseau et le masque de réseau utilisé par le réseau local histoire de mettre un bon pare-feu devant tout ça, ce qui nécessite encore plus de compétences par l’utilisateur…

Bilan : ce n’est pas de la mauvaise volonté si c’est compliqué de proposer un service en auto-hébergement, c’est réellement compliqué. Même pour ceux dont c’est le métier, il n’existe aucune recette de cuisine à dérouler pour obtenir le résultat souhaité. Il faut avoir des connaissances minimal en réseau, savoir réfléchir, prendre des décisions, tester, improviser…

Quelles stratégies d’hébergement adopter ?

Pour traiter cette complexité, on a vu apparaître plusieurs stratégies autour de l’hébergement d’un service :

Chacun possède ses avantages et ses inconvénients.

Prestation de service : plus de prise de tête, mais plus de liberté non plus…

Pour la prestation de service, ce mode a transféré toute la complexité précédente au niveau de votre prestataire, puisque plus rien n’est réellement chez vous et que vous ne faites que consommer des ressources externes (généralement web) situées sur son propre réseau, qu’il maîtrise pour le coup à 100%.

Vous êtes par contre très dépendant de votre prestataire, qui va souvent vous voler vos libertés au passage (difficulté de sortie, logiciel privateur…). Vous avez peu sinon pas de prise sur ses décisions et son infrastructure. Où sont vos données ? Quid si ses CGU/CGV changent du tout au tout du jour au lendemain ?

Le boulot est fait et même plutôt bien fait, sans que vous n’ayez besoin de mettre les mains dans la technique à un moment, mais en échange vous avez perdu votre âme…

Objets connectés : fuyez pauvres fous !

Sauf très très rares solutions (comme Lima a priori), les choix techniques des objets connectés sont très criticables. En fait, il n’y a aucune prise en compte des difficultés présentées, qui sont juste contournées le plus salement possible…

Les problèmes de réseau sont « réglés » en faisant tout sortir sur Internet via un « cloud » géré par votre prestataire. Par exemple dans le cas d’une caméra connectée, vous ne vous connecterez jamais directement à elle, mais elle au « cloud » du fabriquant (le NAT ou le réseau ne pose pas de problème pour les flux de sortie) et vous aussi.

La sécurité y est trop souvent inexistante et les mises-à-jour fabriquant impossibles (matériel pas pensé pour). Vous avez donc un truc pas cher, plug & forget (branchez & oubliez), mais une catastrophe en terme de bonnes pratiques. C’est ce qui a conduit à la création de botnets géants tel que Mirai. Ce qui donne ça et ça en pratique…

L’auto-hébergement : accompagnement nécessaire et ne passe pas l’échelle

Héberger ses services sur ses propres machines, on l’a vu, c’est (très) compliqué si on souhaite faire les choses proprement et ne pas devenir un danger pour les autres machines du réseau. Cela nécessite de solides compétences pour parvenir à un résultat acceptable qui ne transformera pas votre service en Mirai 2.0 à plus ou moins long terme.

Les solutions actuelles (YunoHost, CozyCloud, Own/NextCloud, La Brique Internet…) tentent de faire du mieux qu’elles peuvent pour fournir des images simples à installer. Mais le manque de compétence côté utilisateur associé à la complexité de l’environnement d’accueil font que malheureusement, ces images sont souvent perfectibles en termes de bonnes pratiques et de sécurité.

Ces lacunes techniques, induites par l’impossibilité de réclamer un master en informatique aux utilisateurs, sont compensées par un accompagnement et une sensibilisation des utilisateurs à la problématique de l’auto-hébergement et aux devoirs et risques associés. Vous ne repartez jamais réellement seul avec votre Brique Internet, vous pouvez compter sur la communauté de Franciliens ou de FDN en cas de problème. Idem sur les autres solutions, les forums de support sont là pour aider les utilisateurs.

Malheureusement, l’auto-hébergement ne passerait pas l’échelle.

Niveau sécurité, les lacunes techniques constatées sont peu dangereuses parce qu’il n’y a que peu d’utilisateurs en réalité. Même si une faille était constatée, les machines infectées ne se compteraient que par dizaines ou centaines, et non par centaines de milliers comme pour les CCTV de Mirai. Il en serait certainement autrement si on comptait des millions d’utilisateurs de Brique Internet ou de CozyCloud auto-hébergé.

Pour la sensibilisation, on peut se permettre de prendre du temps pour les utilisateurs parce qu’on en forme 10 ou 20 sur un week-end. On ne pourrait très clairement pas tenir la cadence s’il fallait en gérer 1 000 ou 10 000 par jour.

Bref, l’auto-hébergement ne tient la route que parce qu’il reste anecdotique. S’il prenait de l’ampleur, on finirait très rapidement par finir dans la catégorie « IoT », avec des milliers de bidules oubliés dans un coin à la merci du premier botnet qui passe. Pour démocratiser l’auto-hébergement, il faudra donc obligatoirement passer par une formation plus que poussée des utilisateurs.

Les CHATONS : la solution idéale, mais des choses à inventer

Sur l’hébergement communautaire à la CHATONS, la complexité est gérée par ceux qui savent la gérer : les administrateurs système. L’informatique a l’énorme avantage qu’il suffit de peu de personnes compétentes pour gérer des services pour beaucoup de monde. Via une association et des bénévoles, on peut donc proposer des services à grande échelle (1 000 à 10 000 personnes), gérés par quelques techniciens, sans pour autant tomber dans les travers précédents.

La charte des CHATONS empèche l’enfermement, vous pouvez facilement passer d’un CHATON à un autre (même si parfois le travail est toujours en cours pour y parvenir). La même charte impose la transparence, ce qui permet de contrôler ce qui est fait de vos données et l’orientation générale du projet est décidée collégialement. Le risque de dérive ou de perte de liberté sont donc plus que minimes.

Ça semble être une solution idyllique, pourtant ce nouveau type de projet va devoir innover dans plusieurs domaines pour être réellement intéressant à long terme.

Il est fort peu probable que tous les CHATONS se mettent à proposer l’ensemble de tous les services existants sur la planète. Les ressources techniques ou financières nécessaires calmeront rapidement les ardeurs. Les CHATONS vont du coup entrer en compétition les uns avec les autres, et de plusieurs manières.

Un utilisateur aura naturellement tendance à aller vers les CHATONS proposant le plus de services possibles, ne serait-ce que pour réduire le coût global (beaucoup de chatons risquent de ne pas être gratuits) ou la « paperasse » nécessaire (comptes à gérer, adhésions…). Ce qui risque de tuer dans l’œuf les petites solutions avec peu de moyens, à l’avantage des gros, en plus de recréer des silos de données. Ce problème existe déjà dans le domaine de la presse en ligne : on ira plutôt s’abonner chez un ou deux journaux généralistes (le Monde, Next Inpact, Mediapart…), plutôt que chez de multiples petits journaux spécialisés. Par définition les CHATONS vont devoir se limiter en nombre d’utilisateurs pour ne pas devenir un nouveau Google, les conflits et frustrations n’en seront que plus violents (un service généraliste allant rapidement saturer, il ne laissera que le choix de services spécialisés).

Un utilisateur risque aussi d’être fort peu content d’avoir à payer plusieurs fois un même service auprès de CHATONS différents, juste parce que chacun propose un service spécial. Et en plus d’avoir à payer pour des services qu’il n’utilise pas ! Si par exemple je souhaite un service de courriel, un de pad, un de stockage et un de calendrier, mais que les seules offres disponibles sont « courriel + pad », « pad + stockage » et « courriel + calendrier + voip », je vais devoir m’abonner à tous ces services, me retrouver avec un doublon sur le pad et le courriel et un service de voip dont je n’ai pas besoin… En pratique, on risque même de se heurter à des limitations financières et donc à des utilisateurs se restreignant sur les services parce qu’ils n’ont pas les moyens de tout payer, tout comme beaucoup doivent aujourd’hui se retreindre à certains médias en ligne. Niveau frustration, ça risque donc d’être assez rigolo.

Côté opérateurs de CHATONS, il risque aussi d’y avoir des stratégies bizarres. Les services les plus utilisés au quotidien (pad, sondage…) sont aussi généralement les moins onéreux et complexes à mettre en œuvre alors qu’ils vont être considérés comme à forte plus-value par les utilisateurs. À l’inverse, les services pourtant utilisés plus ponctuellement dans la tête des utilisateurs (hébergement de vidéo, voip, minecraft…) sont des services extrêmement complexes à gérer et coûtant vraiment très cher en permanence (ce n’est pas parce que vous ne regardez pas une vidéo HD qu’il ne faut pas stocker ses 4Go quelque part tout le temps). On risque donc de se retrouver avec des services très rentables d’un côté avec quasiment tout le monde qui les propose, et des services clairement difficiles à rentabiliser proposés par peu de monde.

Sans grand gourou pour réguler un peu tout ça et mettre en place des vases communicants en particulier financiers (à-la-FFDN), la loi de la jungle risque d’être rapidement la règle.

(Merci à Framasky et Regar42 pour la relecture ! ❤️️)