AVERTISSEMENT : les spécifications des moyens de sécurisation de la HADOPI peuvent profondément évoluer, il est donc nécessaire que les personnes concernées se manifestent et enrichissent ces spécifications avec des remarques ou fassent part de leurs inquiétudes sur divers points. En tout cas je vous encourage à le faire, ce n’est pas du temps perdu. La loi est là, il faut maintenant l’appliquer, à nous de faire en sorte que ce soit avec le moins de casse possible.
Le problème des réseaux sans fil publics
- Les abonnés SFR utilisent souvent la connexion de leur voisin à leur insu (connectivité en roaming même depuis leur domicile). Il me semble important de demander à cet opérateur (comme à Free avec son service FreeWifi, même si ce dernier attribue une adresse ip différente de celle de la box à laquelle le freenaute est connecté) des chiffres sur cette pratique.
- Ces réseaux publics avec portail captif sont très souvent vulnérables à un bypass d’authentification par encapsulation tcp over DNS.
- Les réseaux publics déployés dans des lieux publics sont aussi souvent (même très souvent) mal configurés, un scan du lan une fois connecté au portail captif permet aisément de trouver l’ip de l’AP, ses ports ouverts, et donc l’interface d’administration. pour l’interface HTTP le mot de passe est souvent bien modifié, ce qui est très rarement le cas de l’accès console via ssh à ce même AP.
- Toujours pour ces réseaux publics, les firmwares sont très rarement à jour, et donc exploitables.
Filtrage sur les protocoles (En fonction de la taille, des formats, débits, profils utilisateurs , débits, volumes et plages horaires).
Appliquer une politique de sécurité en fonction de ces critères est hasardeux, le risque de surblocage est très important. Le filtrage sur un protocole n’est pas acceptable en soi, c’est une discrimination par défaut, pas plus que ne l’est une approche statistique, même si l’on sait qu’à la sortie des écoles, un fichier de 700 mégas avec une extension .avi a 90% de chances d’être un fichier contrefait.
L’usage d’un protocole P2P pour des raisons légitimes ne peut pas être entravé, même par un simple avertissement. Dans le cadre de la cellule familiale, si un enfant utilise un protocole de P2P pour une raison légitime et que ses parents n’ont ne serait-ce qu’un avertissement, il partiront du principe que le P2P est une technologie problématique et donc proscrite.
L’analyse des configurations des postes clients (logiciels installés) risque d’être un gros frein, à moins que les journaux produits ne puissent être exploités que par l’utilisateur. De trop nombreux utilisateurs de Windows utilisent des logiciels crackés et vont prendre peur que cet outil agisse comme un mouchard.
Outils de journalisation
- le principe du double archivage des journaux me semble acceptable, je n’ai aucun problème avec ça.
- j’ajouterai la journalisation des adresses mac des clients du lan, qui même falsifiables sur le poste client, peuvent être corrélées avec les durées de session et donc être utiles pour disculper une personne victime d’une intrusion sur son réseau sans fil. Cependant, il est à noter que des box comme certaines anciennes Livebox proposent par défaut une fonctionnalité obligeant les postes clients à déclarer les mac adress pour pouvoir se connecter au WLAN (ces box sont livrées avec du WEP activé par défaut). Le résultat, c’est que l’intru, à l’aide d’un outil de sniffing wireless comme aircrack, peut repérer les mac adress connectées à la box (et donc autorisées) visionner le volume de trafic entre le point d’accès et le client, et donc usurper la mac d’un client autorisé (mac spoofing).
- le contrôle de l’utilisateur sur les données de journalisation chiffrées est un bon point, l’utilisateur doit pouvoir demander ponctuellement le déchiffrement de son journal et s’assurer que la version non chiffrée n’a pas été altérée par un simple diff.
L’anonymisation des journaux envoyés pour déchiffrement des données collectées est très importante.
La sécurité est indissociable de la notion de confiance, et je ne vois pas comment l’HADOPI dont la mission initiale est de faire diminuer l’échange de fichiers contrefaits peut être un tiers de confiance acceptable par les utilisateurs. Même anonymisée, cette fonctionnalité sera en toute logique boudée des utilisateurs.
Concernant le stockage de données issues des contrôles des flux réseaux sur le LAN de l’utilisateur, en ce qui me concerne je refuserai catégoriquement qu’une machine connectée à mon réseau local aille scanner d’autres machines de mon LAN, même si ces informations restent sur le poste clients, il serait par exemple mal venu de compromettre une machine de mon LAN sous OpenBSD ou Linux parce qu’un logiciel sous Windows a décidé de stocker des informations sur mon LAN. Je n’accorde aucune confiance à ces moyens de sécurisation sur une machine cliente.
La problématique des ordinateurs portables se connectant sur mon LAN (amis, famille) qui stockeraient des informations sur mon réseau domestique me fait froid dans le dos. Si un tel dispositif est labellisé, j’interdirai purement et simplement la connexion de tiers sur mon réseau de peur qu’un défaut de mise à jour ou une faille ne vienne compromettre une partie de mon LAN. Au mieux je demanderai la désinstallation complète du dispositif de sécurisation à un tiers pour le laisser se connecter à mon LAN. Qu’on le veuille ou non, cette fonctionnalité est assimilable à un mouchard, elle est donc à proscrire.
Systèmes d’exploitation libres et moyens de sécurisation
Les systèmes d’exploitation libres disposent déjà d’outils performants de sécurisation (de la vraie sécurisation qui lutte contre des accès frauduleux et qui ne condamne pas un usage). Les Unix libres disposent par défaut de Packet Filter et GNU/Linux de Netfilter/Iptable. Ces outils correctement configurés sont suffisants pour assurer un niveau de sécurité satisfaisant, tout dispositif supplémentaire est non seulement inutile et aucun crédit ne saurait leur être accordé. Tout labellisé qu’il soit, un tel dispositif a par exemple fort peu de chance d’apparaître dans les packages d’OpenBSD.
Même si ces solutions existent, elles ne seront jamais intégrées dans des distributions car ni leur fondement légal, ni leur philosophie, sont compatibles avec les logiciels libres.
Le principe des listes et solutions de contrôle parental
De ce point de vue, je n’ai aucun problème, à la seule condition que la configuration par défaut du dispositif fasse apparaître clairement les sites filtrés et qu’aucun site ne soit filtré à l’insu de l’utilisateur. Attention, ceci exclu de fait certaines solutions. Ces listes doivent être lisibles et éditables par l’utilisateur. Aucun site ne doit être placé dans une liste noire à l’insu de l’utilisateur.
Le principe des listes peut convenir mais il est par exemple hors de question qu’une société tierce, comme OPTENET, qui semble avoir des liens affirmés avec les milieux intégristes catholiques et qui a déjà montré en Australie son zèle à filtrer secrètement des sites parfaitement légaux, devienne le garant de ma morale ou de celle de mes enfants. cf : http://bit.ly/be4M7f
« Ces listes (centaines de milliers d’éléments, en général) sont définies et mises à jour par diverses organisations ou groupes d’ordre éthique. » : permettez moi d’en douter, OPTENET équipe aujourd’hui l’éducation nationale et n’est pas un tiers de confiance fiable à mes yeux.
Les problèmes de normalisation au niveau européen
Cette digression sur Optenet me fait sérieusement réfléchir sur une éventuelle compatibilité (et sur le papier elle se doit de l’être) avec les dispositifs européens de filtrage normés (ils devraient l’être au début de l’année 2011). Il va de soi que non seulement je vais m’opposer haut et fort à ce que la France se base, contre les avis de l’AFNOR, sur une norme européenne dont on sait qu’elle a été tronquée par des intérêts privés et qu’elle présente un caractère prêtant à une grande suspicion.
A la veille du vote de l’article 4 de la Loppsi, si nous avons le moindre soupçon de mise en place d’outils un peu trop « polyvalents », nous nous y opposerons fermement et avec les arguments idoines.
Protection antivirale
« Un antivirus car l’application devra se protéger contre les différentes attaques qui ne manqueront pas de surgir contre elle-même. Elle devra détecter des logiciels de contournement, etc. »
Cette définition fonctionnelle me semble erronée.
Il existe déjà des éditeurs proposant des solutions antivirales, je ne comprends pas ce que ceci vient faire dans un dispositif labellisé par la HADOPI. Par définition l’usage d’un antivirus est nécessaire quand c’est trop tard.
Enfin ajouter un antivirus a des solutions antivirales existantes alourdira la charge dédiée à la sécurité de manière inutile en diminuant sensiblement les performances des machines des utilisateurs.
Le coeur du problème : l’analyse dynamique de flux
« Le but de ce module est d’inspecter dynamiquement le contenu entrant et sortant du trafic sur les interfaces du réseau de la machine de l’utilisateur. »
Cette fonctionnalité est dangereuse et ne produira que pour seul effet d’amputer les internautes d’une partie d’Internet.
- Quid des logs produits ?
- Quid des protocoles exotiques ou nouveaux non répertoriés par l’éditeur ?
- Quid du comportement de cette fonctionnalité sur les outils d’anonymisation de trafic (TOR/Freenet) ?
« En cas de découverte d’une configuration atypique, une notification de bas niveau est générée. »
Là encore c’est très discutable, quid de la défense d’un internaute pour justifier une configuration atypique nécessitée par un usage légal, quid de sa valeur au moment de défendre sa bonne foi ? On s’oriente vers des écueils juridiques où les utilisateurs ont tout à perdre : cette fonctionnalité doit impérativement être indépendamment désactivable
Des mesures de sécurité qui n’en sont pas
Page 24 : « (pas de sécurisation WPA, SSID en clair, routeur avec aucun contrôle sur les adresses MAC des appareils se connectant à lui, etc.) ».
- Un SSID en clair n’est pas une vulnérabilité (même masqué, un SSID est détectable, ainsi que le BSSID, par de simples outils d’analyse de réseaux sans fil)
- Un dispositif de contrôle des adresses mac n’est pas non plus un dispositif de sécurité sérieux (il est contournable en 5 secondes).
Leur absense n’ont donc pas à générer d’alerte. Il est même dangereux de définir ces mesures comme des mesures de sécurité car ceci sème le trouble chez certains utilisateurs qui se pensent sécurisés sous prétexte que leur SSID est invisible.
Un point intéressant qui a le mérite d’expliquer clairement les intentions du dispositif
Page 24 : « L’application doit aussi conseiller et guider l’usager pour les divers appareils qui ne sont pas des ordinateurs (lecteur DVD, Boitier multimédia, etc.) mais qui sont susceptibles de posséder des fonctions de téléchargement avec une problématique de contrefaçon. »
Ces dispositifs tendent donc explicitement à limiter les usages de matériels possédant des fonctionnalités de téléchargement. Comme ça c’est clair, l’idée est de « sécuriser contre le téléchargement », mais pas de sécuriser les données personnelles de l’utilisateur. Cette phrase a elle seule discrédite l’ensemble de la démarche, on est plus dans la sécurisation, on est bien dans le registre de la surveillance.
Un point de détail assez amusant
Un peu plus loin (P.27), la solution propose même de « bloquer toutes les connexions ; » … là, vous avez intérêt à avoir une hotline assez sérieuse et ça promet de grands moments…
Contournement du dispositif et contre mesures
La sécurisation des moyens de sécurisation est illusoire, l’histoire nous montre que _tous_ ces dispositifs ont été compromis au moins une fois. L’exploitation à grande échelle est restreinte par la diversité. Si un mécanisme labellisé et donc présent dans toutes les solutions est faillible, le risque d’une exploitation à grande échelle est inéluctable. Un moyen de sécurisation ne saurait réussir à comprendre ce qu’il se passe dans une machine virtuelle, seules des traces « réseau » pourraient apparaître dans les journaux. Si elles sont chiffrées, seul un mécanisme de signature de trafic pourrait permettre de repérer une tentative de contournement et cette perspective est inquiétante et sa pratique généralisée n’est pas souhaitable. Toute approche de reconnaissance de contenus, ne saurait se faire que sur un fondement légal valable et motivé par des faits graves. Par delà les problématiques de priorétarisation de trafic légitime, elle posera à terme des problèmes car il est tentant d’utiliser cette technique pour des causes non légitimes. Nettoyer Internet de contenus copyrightés n’est à mon sens pas une cause légitime et constituerait un détournement non souhaitable de cette technologie.
Je m’inquiète de voir apparaître un dispositif supplémentaire sur les réseaux mobiles, même si ce n’est pas ce qui est clairement expliqué dans le document (page 8). Les réseaux mobiles sont déjà assez filtrés (usage manifeste du DPI) pour que l’on ajoute une couche supplémentaire de filtrage.
En conclusion
Je persiste et signe, l’HADOPI est illégitime dans cette mission, l’intitulé « moyens de sécurisation » est séduisant mais il est trompeur quant aux objectifs. C’est le droit d’auteur qu’on protège en condamnant des usages et non les internautes.
Le risque de voir ces solutions labellisées HADOPI répondre aux normes européennes en font un outil rêvé de contrôle moral et politique basé sur la peur du gendarme, effet renforcé par le délit de négligence caractérisée. Si sur la forme certains points de ce document semblent techniquement corrects, le fond et les motivations de la démarche l’invalident à mes yeux totalement.
Même labellisés, ces moyens de sécurisation n’auront donc pas droit de citer chez moi et je déconseillerai vivement leur installation.
Possibly Related Posts:
- HADOPI : La riposte graduée est morte comme le Disco
- Musique : Google Lab India vous offre le catalogue Hindi
- Monsieur le Ministre de la Culture, je vais vous aider à comprendre…
- Les parlementaires de la honte
- Faut-il réguler la Neutralité du Net ?