Turb(l)o(g)

Ce n’est pas le premier tir. Souvenez-vous, en septembre dernier, une première consultation avait été lancée sur la base du document de Michel Riguidel.

Après recompilation des avis donnés, voila la V2 de la consultation.

Me voila donc obligé de faire une V2 de la réponse, même si le document en lui même ne la demande pas, il y a tellement à boire et à manger que je ne peux m’empêcher.

Et il y a tellement à boire et à manger que nous avons décidé, avec quelques twittos, de faire une réponse à 12 mains. Avant de continuer, je vous conseille vivement d’avoir ouvert et lu, même en travers, le document dont nous parlons, sinon, vous serez vite paumé.

Sans plus attendre, donc, les notes de lecture mélangées de @ackrst, @arrouan, @bituur_esztreym, @bluetouff, @erebuss & votre serviteur suivies des conclusions respectives de ceux qui ont voulu. La correction orthographique finale a été assurée avec brio par ma chère et tendre.

Licence CC-BY, as usual.

---

Le présent document est une rédaction à 12 mains se voulant être une réponse à la nouvelle consultation HADOPI à propos des spécifications fonctionnelles des moyens de sécurisation publiées le 20 avril 2011.

Le nombre de points à aborder étant trop grand pour être traité de façon fluide dans un texte pouvant se lire du début à la fin, nous avons privilégié un découpage de notre commentaire par pages du document d’origine.

* Page 5
Elle résume le fonctionnement d’hadopi en général. Elle parle largement de « l’abonné » alors que le gros du document parle principalement de titulaire, puis d’administrateur. Le titulaire est défini en page 10 comme étant le souscripteur d’un abonnement à un réseau public (Internet & réseau mobiles), on peut donc considérer que titulaire = abonné. L’administrateur, quant à lui, est la personne qualifiée, nommée par le titulaire, pour accomplir les actes techniques relatifs à la mise en place du logiciel ou du service.

* Page 6
Le rôle de l’HADOPI est rappelé : « Dans le cadre de la loi n° 2009-669 du 12 juin 2009 favorisant la diffusion et la protection de la création sur internet, l’Hadopi s’est vue confier une mission de protection des œuvres et des objets auxquels est attaché un droit d’auteur ou un droit voisin à l’égard des atteintes à ces droits commises sur les réseaux de communications électroniques utilisés pour la fourniture de services de communication au public en ligne (article L331-13 2° CPI) »

Ce paragraphe est, à lui seul, en parfaite contradiction avec toute la suite du document. En effet, ce document, comme la loi HADOPI, ne contient rien d’effectif et directement assigné à la protection des oeuvres… tout est concentré sur la « sécurisation, mesures de sécurisation, etc. ». Considérer que ces SFH vont « effectivement » protéger les auteurs et oeuvres, c’est comme croire qu’une chèvre peut être championne du monde de billard à trois bandes, à peu de choses près.

* Page 7
L’Application ne concerne pas uniquement l’Internet fixe mais également les téléphones mobiles.
Le logiciel sera donc aussi bien installé sur les réseaux filaires que sur les réseaux mobiles. De part la faible puissance des terminaux mobiles et leur caractère fermé (ie iPhone), ce sera donc un logiciel d’analyse réseau qui sera installé par les FAIs sur les réseaux 3G en contradiction avec ce qui se dit page 9.

* Page 8
Le début de la page est encourageant, précisant qu’il est nécessaire d’aider l’utilisateur lambda dans la gestion de sa sécurité et la protection de ses équipements. Malheureusement, par la suite, il n’est quasiment plus question que de la mission d’origine d’HADOPI, en oubliant les intérêts majeurs d’une sécurisation bien pensée.

« Ces équipements comprennent l’ensemble des terminaux et des dispositifs réseaux: ordinateur, télé connectée, console, tablettes, box, routeur, borne WiFi, etc »
Il faut que l’Application puisse surveiller tout ce qui se passe depuis l’ensemble des équipements, il n’y a donc pas d’autre choix que d’installer l’application HADOPI dans la box. Il restera aussi la possibilité d’ajouter un nouveau boitier/extension à coté de la box actuelle pour inclure l’application HADOPI.

* Page 9
Il est précisé que la solution décrite par le document peut être, en tout ou partie, abritée sur les postes des utilisateurs ou bien dans des équipements dédiés sur le réseau ou encore sur « le point d’accès » à l’exclusion de tout autre endroit. Exit donc l’ensemble des solutions faisant appel à des éléments hébergés à l’extérieur alors que justement certains, cloud y compris, sont décrits et inclus dans la suite du doc.

Cette page précise aussi que la solution peut tout à fait être basée sur des logiciels libres, chose pas évidente à réaliser, quand on lit les impératifs décrits par la suite (garanties de mises à jour et de fonctionnalités à fournir, …)

* Page 10
Le titulaire du contrat est d’abord indiqué comme étant la personne morale dans l’entreprise puis, plus loin dans le même paragraphe, c’est devenu le chef d’entreprise voir éventuellement le DSI ou quelqu’un d’autre. Du coup, la responsabilité juridique, on sait plus trop bien où la trouver. La responsabilité juridique est celle qui s’applique pour tout SI en entreprise. C’est à dire que le chef d’entreprise/établissement public est le responsable pénale. Mais il peut déléguer cette responsabilité à des personnes comme le DSI.

Si c’est le chef d’entreprise qui est considéré comme titulaire, risque-t-il de se faire couper la connexion à son domicile ? En cas de poursuite pénale, c’est lui qui sera visé.

Impossible aussi, du coup, de savoir où se termine la notion de « FAI » et où commence celle de « client du FAI ». Une personne fournissant de la connectivité à ses voisins et valablement déclarée auprès de l’ARCEP est-elle FAI ou pas ?

Dans la note de bas de page, il est indiqué que rien ne doit remettre en cause les dispositions relatives au respect du secret de la correspondance et au respect de la vie privée, pourtant, l’ensemble du document transpire le flicage et l’inspection.

* Page 13
« La solution ne peut pas être installée au coeur d’un réseau public »... ah… mais, c’est quoi un réseau public ? J’offre l’accès à internet à toute personne se trouvant dans un rayon de 100m autour de mon domicile. Mon réseau est donc public. Il m’est interdit d’installer une solution labellisée HADOPI ?

Ainsi qu’un somptueux (premier) clash avec les propos tenus page 9 qui précisaient que rien ne devait sortir du réseau local. Il est ici question de permettre aux entreprises de faire voyager les données via internet, précisant quand même que la transmission devra être sécurisée.

* Page 14
On en rajoute une couche sur la rassurante interdiction de désaisir l’abonné de ses informations. On ajoute aussi, contrairement à ce qui se dit partout ailleurs dans le doc, la possibilité d’enregistrer dans le journal les éléments précis contrevenant à une règle de sécurité (URL d’un site visité, nom de fichier téléchargé…)

* Page 15
Les applications pouvant être labellisées HADOPI doivent pouvoir être utilisées à toutes les échelles, aussi bien chez le particulier que dans la grande entreprise. On y répète qu’elle doit pouvoir fonctionner en harmonie avec des logiciels libres.

Puis, il est indiqué qu’un logiciel labellisé doit bénéficier de mises à jour régulières, prenant pour exemple l’évolution rapide des usages. Quand on connaît le délai de réaction dans les milieux du libre, à certains moments, on se demande bien comment une application 100% libre pourrait être labellisée puisque personne ne pourra garantir quoi que ce soit.

Il est également dit « l’Application n’affronte pas la communauté des pirates informatiques qui souhaiteraient briser sa sécurité »
Quel est le sens de cette affirmation ? Quel est l’aveu / le sens de pareille phrase dans une doc technique de description de specificités ?

* Page 17
Le monde est ici divisé en deux grandes parties : les entreprises et les particuliers/TPE. On oublie les gens qui partagent leur internet à tous les vents, les FAI associatifs, les réseaux pervasifs, de toute façon, c’est interdit, ça, madame !

* Page 19
L’ensemble du document parle souvent de simplicité d’utilisation, mais également de granularité d’utilisation, de nombreuses fonctionnalités, etc. Deux principes souvent antinomiques et aucun passage du document ne propose de solutionner le problème du « simple mais configurable à souhait ».

En fin de page, on apprend l’existence d’un des gros morceaux du document, les fameuses listes (noir & blanches, vous notez que les grises ont disparu). Pas un mot, ni sur cette page ni ailleurs, sur les personnes qui vont constituer ces listes et/ou les vérifier ni sur quelle base régulière. Une chose est certaine, ces listes existeront et seront donc publiées, permettant à qui le souhaite de vérifier ce qui se passe.

* Page 20
En contradiction avec la page 14, il est précisé que les historiques de navigation ne sont jamais enregistrés (URL, noms de fichiers, ..)

Il est ensuite question de durée de conservation de logs. Les diverses lois parues ces dernières années imposent, tour à tour, des délais minimaux et maximaux de conservation de données nominatives (‘logs’) pour les entreprises. Ces informations pourtant capitales ne sont pas incluses dans le document où on préfère laisser « le choix à l’utilisateur ».

Dans cette page, sont également mis en avant les besoins d’intégrité du fichier de logs. Mais l’intégrité est certifiée par l’utilisation d’une clef privée qui est en possession de l’administrateur/utilisateur. Ce dernier peut donc modifier le fichier puis relancer le processus de création de la signature qui sera utilisée pour vérifier l’intégrité. La certification perd donc tout son intérêt.

* Page 21
Le premier paragraphe mérite creusage, il me semble qu’il y baleine sous gravillons.

Il est ensuite dit, en français dans le texte, que la sécurité chez un particulier ou dans une TPE est plus faible que dans une « organisation » (comprendre « grande entreprise »). On se demande donc bien pourquoi hadopi tape principalement sur les particuliers en ce moment, de l’aveu même de sa présidente.

« L’application n’est pas une source ou un vecteur d’attaque et n’affaiblit pas l’environnement informatique du titulaire de l’accès Internet. »
Un logiciel peut toujours inclure des failles. La seule manière est de vérifier mathématiquement le code source de l’application.
Or, prouver mathématiquement le code d’une application est un problème très difficile voire impossible vu la complexité du logiciel demandé. En plus, il faudra aussi prouver mathématiquement les protocoles réseaux que pourrait utiliser l’application. En pratique, c’est donc totalement infaisable de ne pas rajouter de source ou de vecteur d’attaque en ajoutant des fonctionnalités à un système.

* Page 22
Une perle dans la note en bas de page nous informe qu’HADOPI a connaissance de méthode de hachage réversible à la demande des juges. Décidément ils sont très forts ! En effet, avec de vieux algorithmes de hachage, il est possible de provoquer des collisions (un même hache qui permet de vérifier deux fichiers différents) mais revenir en arrière n’est pas/jamais possible.

* Page 23
Si le distingo entre internet et la téléphonie mobile est une bonne chose, il me semble illusoire de prétendre à l’installation de ce genre de fonction sur certaines plateformes mobiles (dont, principalement, celle à la pomme…).

On parle ensuite de pédagogie en matière de caractéristiques générales. Je vois d’ici venir le popup « Télécharger, c’est maaaal. Va plutot acheter sur [//] » quand on boot le PC. Un retour aux disclaimers qui emmerdent les acheteurs honnêtes au début des DVD ?

Place ensuite à la grande diversité des « utilisateurs », du particulier à l’entreprise du CAC40. Le logiciel doit tout traiter. Illusoire au possible.

« L’application doit apporter du bénéfice pour l’ensemble de l’écosystème: utilisateurs, ayant-droits, FAI et opérateurs de télécoms et Hadopi. »
Comment une application peut apporter des bénéfices à un utilisateur quand elle va brider son accès à l’information, dégrader les performances de son système mais aussi sa vie privée et ajouter des vecteurs d’attaque supplémentaires sur son système ? Le document se défend de tout ceci mais c’est pourtant la réalité de ce qui risque d’arriver aux utilisateurs de ce genre de logiciels.

* Page 27
Les mises à jour semblent être d’une importance capitale, et on se doute bien de la raison. Mais quid du client qui ne paie plus sa solution commerciale estampillée hadopi ? Elle n’est théoriquement plus mise à jour par l’éditeur… va-t-il perdre pour autant sa labellisation ?

* Page 29
Une première note amusante sonne comme une envie de se dédouaner : « la limitation de débit n’est pas une sanction »… ah mais on se doute bien que c’est pas une sanction, étant donné que l’administrateur peut désactiver le logiciel quand il en a envie. Quel est l’intérêt de cette note, du coup ?

* Page 30
Il est question que l’applicatif embarque un listing de hash de fichiers illicites. Je sais bien qu’un hash c’est petit (~30 octets pour les standards les plus courts), mais vu le nombre d’exemplaires différents d’une même oeuvre qui doivent circuler, ça n’augure rien de bon sur la rapidité de traitement de l’engin.
Avec 256 bits dans le calcul de hash, cela donne une possibilité d’avoir une taille d’espace de hash égal à 2^32 = 4 294 967 296 éléments, rien n’empêchant d’aller chercher un hash sur 512 bits.

La fin de la page part sur une explication compliquée qui, on finit par le comprendre, veut dire que les choses explicitement autorisées prennent le pas sur les choses explicitement interdites. Il doit y avoir un moyen plus simple de le dire.

* Page 31
« Il faut vérifier la configuration des ordinateurs. »
Pour cela, il faudrait pouvoir définir ce qu’est une bonne configuration. Vu l’hétérogénéité des systèmes et des logiciels, c’est presque impossible. Sauf bien sûr, si le logiciel recherche des choses évidentes comme un compte utilisateur sans mot de passe.

« Le module d’analyse doit analyser dynamiquement des logiciels en fonctionnement. »
Il faut donc qu’une partie du logiciel soit en espace noyau et puisse détecter des comportements anormaux en suivant le flux d’exécution d’un logiciel et tout ça de manière dynamique. C’est pas évident mais faisable avec pour coût une modification forte du système et une complexité d’administration forte.

On note, par ailleurs, que le module d’analyse de la configuration du poste informatique est jugé optionnel « surtout dans le grand public pour respecter la sphère privée ». J’aurais eu tendance à penser qu’il était plus important de respecter la vie privée au travail, on n’a généralement moins de choses qu’on a pas envie de dire à sa femme que de choses qu’on a pas envie de dire à son patron.

« Le module de statistique doit pouvoir faire remonter les statistiques réseau de la box. »
Il faudra donc qu’une partie du logiciel se trouve dans la box ou au moins interagisse avec celle-ci.

On parle ensuite d’un logiciel magique qui pourrait analyser la sécurité du réseau local… « oh tiens dis donc eh, t’as un câble sur ton switch qui est branché à rien… c’est pas secure !! » Voire du wifi, sans toutefois expliquer comment. On apprendra plus loin qu’il serait bien vu que les FAI laissent l’ordinateur de la maison aller inspecter la configuration de la box. En bref, c’est pas demain la veille.

* Page 32
Le cloud computing devient un protocole réseau. Clap clap !

* Page 33 / 34
Les fonctionnalités de détection doivent être mises à jour pour refléter les « nouveaux protocoles ou nouveaux comportements délictueux ». Qui sera chargé d’édicter la règle compréhensible par le logiciel et selon laquelle tel comportement est délictueux ? A priori, ca sera à l’entreprise commercialisant le logiciel de proposer de mettre à jour les signatures comportementales.

L’Application doit aussi pouvoir faire une analyse protocolaire presque en temps réel et ça même sur les flux chiffrés. Mais l’analyse protocolaire, ça ne permet pas de savoir ce qu’il y a dans le flux mais uniquement de connaitre le protocole utilisé.
Ca avance à quoi pour l’Application HADOPI ? Par exemple, cela permettra de faire de superbes signatures du genre: P2P chiffré + téléchargement de 1.2Go et connexion à opentracker = alerte de sécurité de haut niveau.

La petite note de bas de page 34 fait par ailleurs bien plaisir. Il faudrait l’accrocher à divers endroits du document, par exemple lorsqu’on parle de comportement délictueux détecté par une technologie.

Le langage des règles globales doit être le même pour tous, mais la norme en question n’est pas détaillée. Ce sera aux éditeurs de se mettre d’accord ? On n’est pas sortis.

Un point positif, par contre, la fin de la page 34 détaille fort bien les risques de surblocage existant même en local au sein d’un seul et même ordinateur en prenant pour exemple le P2P légal & illégal qu’il est fort difficile de différencier sans inspecter les contenus. On se souvient toute fois que, page 30, il est question d’embarquer dans le logiciel un listing de condensat de fichiers connus pour être échangés illégalement. On regarde dans les contenus ou pas, alors ? Oui mais faut pas le dire trop fort.

Découpage en deux niveaux
On peut lire : « L’Application n’éxamine pas le contenu applicatif des échanges. » Mais qu’est-ce que qu’un contenu applicatif ?
Il semble que les rédacteurs ne veulent pas intégrer dans leur mécanisme le fait que le contenu applicatif correspond à tout tampon mémoire réseau qui est passé à la couche OSI inférieure (la couche transport).

Dès lors, le contenu applicatif correspond à n’importe quelles données écrites vers la couche transport.

Dans l’exemple de SMTP, les rédacteurs veulent nous faire croire que les entêtes d’un mail (champs From, Subject, Date, etc) ne sont pas du contenu applicatif, mais du contenu protocolaire, le protocole SMTP.

Ceci est une approximation énorme, qui laisse les outils de DPI avoir leur place dans l’ensemble des solutions pour cette spécification.

En effet, ces champs sont effectivement du contenu applicatif, car générés par une application (le client mail) et sont au-dessus de la couche transport ; l’application passe à la couche transport un tampon de mémoire contenant à la fois les champs d’entête et le « contenu » du mail, qui n’est rien d’autre qu’un champ SMTP.

Plus loin, il est clairement établi que l’application peut « extraire les URLS ». On imagine que soudainement on parle de HTTP. Dès lors, comme pour SMTP, l’URL demandée dans une requête HTTP fait partie du contenu applicatif.

Alors, l’application examine-t-elle oui ou non le contenu applicatif, ou doit-on changer la définition du contenu applicatif pour que cela coïncide avec ce que l’application souhaite faire ?

* Page 35
2e paragraphe : « Cette distinction normale-anormale ne sépare donc pas l’acquisition ou la présentation d’un fichier légal (téléchargement en P2P d’une version de Linux, streaming sur France culture, etc.) de l’acquisition ou la présentation d’un fichier illégal. Cette analyse distingue des conduites protocolaires spécifiques, définies sur des bases de critères quantitatifs, qui varient au cours de la session. »
Donc ça n’est pas le critère légal/illégal (sinon il faudrait qu’ils inspectent et avouent inspecter les paquets, et donc c’est à la taille du fichier… ? Qui va compter ? Quel intérêt ? Vu que pour eux le streaming de plus de 15min c’est illégal, je pense qu’un téléchargement de 704Mo c’est illégal sauf si c’est un .iso provenant d’une liste de miroirs reconnus. C’est bien ce genre de signatures qui risquent d’émerger de leur spécification.

On apprend dans cette même page qu’une « connexion VPN vers un site à risque » serait une « anomalie ». 2 pages après avoir rappelé que la technologie était neutre, on se demande bien comment une tête VPN pourrait être considérée comme « un site à risque ».

* Page 37:
« Une Application engendre optionnellement un journal détaillé, qui sauvegarde les différents événements observés. Les traces doivent enregistrer les événements comme les démarrages, les mises à jour, les actions de l’utilisateur, les arrêts, etc. »
Puis dans la description des évènements à journaliser, il n’est plus question des mises à jour.

Par ailleurs, on a sur cette page un exemple flagrant de faille de sécurité. Sur une même machine vont être stockées les clés privées et publiques permettant le chiffrage et la signature d’un journal. Une base, en matière de sécurité, est de conserver une clé privée à l’abri des regards, surtout de ceux qui ne doivent pas accéder au contenu chiffré.

* Page 38:
Suite à l’introduction des alertes de haut et de bas niveau, il est proposé d’utiliser la norme IDMEF pour le stockage de ces alarmes dans le journal.
IDMEF est une norme qui a été développée à la base pour partager et corréler des alertes de IDS (sonde de détection d’intrusion). Ces alertes IDS ont souvent un faible niveau de détails et à elles seules n’ont pas un grand intérêt. En corrélant ces alertes, on peut obtenir des informations de plus haut niveau et de meilleure qualité. C’est l’idée qui ressort des modules de génération des alertes de haut et bas niveau ainsi que la partie journalisation.

* Page 41:
Exemple d’une politique made in HADOPI, si un stream dure plus de 15min alors c’est un stream illégal. C’est précisé que sinon ce ne sera pas possible de regarder des bandes annonces. Encore une belle preuve de méconnaissance des usages.

Un des objectifs de sécurité de l’application est de pouvoir faire la différence entre un utilisateur se faisant passer pour un pirate et un vrai pirate. Même avec une analyse comportementale que ce soit au niveau du réseau ou au niveau du système d’exploitation, si un utilisateur se fait passer pour un pirate, il est impossible de le différencier d’un vrai pirate. Sauf si l’application utilise la webcam de l’utilisateur pour le prendre en photo et faire une reconnaissance morphologique. Dès lors, quel est l’avantage du dispositif ? Quelle utilité ? Le but serait de pouvoir dire à un utilisateur que ce n’est pas un méchant pirate mais lui-même qui a téléchargé tout en se faisant passer pour un pirate. Ca se recoupe plus tard quand le logiciel doit détecter un reboot sur un LiveCD. Mais ce n’est pas en cohérence avec la loi qui juge le défaut de sécurité et pas le téléchargement illégal…

* Page 43:
Il faut que l’application s’auto-protège alors qu’elle ne fait pas confiance dans le système d’exploitation. C’est une chose qui est tout simplement impossible. On ne peut pas faire tourner un logiciel sur un système non sûr tout en voulant garantir que l’application soit sûre. Il existe une méthode mais il faut faire confiance dans l’hyperviseur qui virtualise le système d’exploitation.

L’application doit être en mesure de détecter une usurpation d’identité. Comment ?

Une infrastructure lourde doit être mise en place pour la synchronisation temps (machine doublée, sécurisation SSL…) et les mises à jour. Le marché est donc de facto fermé aux petites entreprises et au monde du logiciel libre et ce n’est pas la seule obligation incompatible avec ces deux mondes même s’il est tout à fait possible d’imaginer beaucoup de choses dans le monde du logiciel libre (commercialiser du support, des offres d’hébergement…)

* Page 44:
L’application doit pouvoir détecter les man in the middle. Comment ?

Il faut pouvoir garantir des propriétés de sécurité de type intégrité, confidentialité et disponibilité avec une politique de sécurité discretionnaire. Cela a été prouvé comme impossible depuis plus de 20 ans. http://1.usa.gov/4AsK5 et http://bit.ly/hsK0jN prouvent cette impossibilité.
La première publication est l’Orange Book qui fait référence pour la sécurité des systèmes d’exploitation.
Cette impossibilité a été prouvée mathématiquement.

* Page 47:
« Les notifications et leurs contextes (date, heure, etc.) doivent être journalisées (module 3) »
Mais le journal peut ête désactivé… esprit de contradiction encore.

* Page 49
Il est fait l’hypothèse que les « organisations » (toute entreprise plus grande qu’une TPE, donc à partir de 5/10 salariés) ont un SI protégé. C’est loin d’être le cas.

Il est ensuite fait mention des dispositifs existants pour filtrer « le web », parmi lesquels des filtres à skype, P2P, vpn… Faut-il rappeler que tout ceci n’est pas le web ?

* Page 50
Un fort beau paragraphe kamoulox : « ces filtres web sont mis à jour régulièrement souvent en temps réel via des tunnels sécurisés ».

Il conviendrait, pour traiter le cas spécifique des organisations, de distinguer celles qui ont un SI constitué des autres qui, aujourd’hui, n’ont pas plus de compétences que le particulier.

Concernant les grands groupes avec beaucoup d’utilisateurs, on risque, si on suit le document sur cette page, de se trouver en contradiction avec le début du document qui interdit d’installer les dispositifs en coeur de réseau.

* Page 51:
L’application peut être dans le cloud alors qu’il était interdit dès le début du document de faire sortir un quelconque composant de la solution plus loin que le modem d’accès.
Ca promet en terme de confiance envers le cloud.
Une partie des logs et l’application pourraient donc être hébergées sur des machines qui sont au-delà de l’accès de l’utilisateur et dans des infrastructures dont la sécurité n’est absolument pas assurée ni même auditable.

Le document fait, par ailleurs, l’hypothèse qu’une solution centralisée ne peut être contournée, ce qui est bien évidemment faux.

* Page 53
Le document pose le principe que la sécurité informatique en entreprise se doit d’être simple et facile à mettre en oeuvre. D’une part ce n’est presque jamais le cas, d’autre part, le reste du document prône de multiples fonctionnalités dans le logiciel décrit, ce qui est par nature antinomique avec simplicité et facilité.

Le document établit ensuite, dans un passage qui ressemble à une traduction (« il existe de nombreux outils sur étagères »), que le gros des outils de sécurité pour l’entreprise respectent la sphère privée de l’utilisateur. On sait fort bien que c’est faux, ces technologies étant ultra intrusives. Tout n’est qu’une question d’usage. Le respect de la vie privée des utilisateurs en entreprise dépend de l’usage fait de ces outils par le chef d’établissement.

* Page 54:
Le dernier paragraphe me donne envie de dire « KAMOULOX ! » :
« L’identification des protocoles utilisés, des logiciels en cours de fonctionnement ou des URL utilisés, est intéressante, mais n’est pas nécessairement liée à la pile protocolaire. Les volumes des flux entrant et sortant sont des indicateurs précieux qui permettent de détecter la sémantique de la pile protocolaire réelle, en cours d’exécution »

* Page 55:
L’environnement décrit un système sain.
Ce système doit être très fortement sécurisé pour garantir des politiques de sécurité.
Il faut donc que le système dispose d’un contrôle d’accès discrétionnaire.
Or, il n’existe pas beaucoup de systèmes de ce type.
SELinux sous Linux propose ce type de contrôle.
Mais rien n’est parfait, et il est toujours possible de détecter des millions de ruptures de propriétés de sécurité dans une politique de sécurité développée par un grand groupe comme RedHat.

* Page 60:
L’idée pour l’Application à destination des particuliers est de réutiliser des composants de sécurité qui existent déjà comme les anti-virus, les anti-spyware, etc.
Quand on voit la faible efficacité de ces logiciels, on peut se rassurer, le logiciel sera inefficace.

* Page 61:
Il est marqué que le dispositif de sécurité de contrôle parental peut être opéré par le FAI. On se dirige donc clairement vers du DPI chez le FAI à la demande de l’utilisateur.

A la rubrique « dispositifs de sécurité pertinents », le document cite les outils de journalisations qui pratiquent un enregistrement exhaustif de tout ce qui se passe sur le poste de travail, en contradiction avec les limites exposées en début de document.

* Page 62
La fin de la page est un amoncellement de termes techniques sans queue ni tête.

* Page 64
LE début de la page consacre la possibilité d’un filtrage en coeur de réseau par le FAI en violation de ce qui se dit en début de document et avec de très belles phrases comme « l’opérateur de sécurité devra pouvoir exhiber au client les traitements avec une certaine transparence de façon à éviter les portes dérobées, les captures de flux. » ; ça veut dire quelque chose, concrètement ? le résultat de cette exhibition peut être transparent et compréhensible par l’internaute ?

Sur l’hétérogénéité des terminaux, l’analyse est fausse, les terminaux convergent tous vers quelques OS bien précis (windows, osx, ou linux) que ce soit sur des ordinateurs serveur ou poste de travail ou sur leur équivalent mobile (windows CE/phone 7, iOS, ou android).
Ce n’est pas parce qu’il existe des « tablettes, ordiphones, téléviseurs, consoles de jeux et autres tablettes électroniques », qu’on ne doit pas regarder le système qui y fonctionne. Le matériel n’est pas la solution logicielle.
Or celle ci, clairement, est convergente dans le marché actuel, ce qui permet de déployer un mécanisme de sécurisation sur chacun de ces systèmes directement, plutôt que d’aller analyser le trafic réseau avec toutes les problématiques qui existent (atteinte à la confidentialité de la correspondance, trafic chiffré, etc).

* Page 65
« En termes de culture informatique, une Application se rapproche des pare-feu personnels (culture protocolaire) et des antivirus (culture de sécurité et de cryptographie). En termes de présentation et de gestion informatique, une Application se rapproche du contrôle parental. »
Là aussi, on sent l’approximation ; d’autant que la phrase suivante dit que « une application » devra être compatible et cohabiter avec les suites de sécurité, antispam ou autres, existant…

* Page 66:
L’Application ne doit pas impacter les performances du système. Or, un système de sécurité impactera forcément les performances du système sauf s’il ne fonctionne pas.
Si on voit les performances de certains anti-virus et le besoin d’analyse beaucoup plus fort pour HADOPI, l’Application sera donc sûrement très gourmande en performance.

L’application ne doit pas être intrusive dans le cas où l’accès est utilisé à des fins légales. Donc c’est intrusif quand c’est illégal, sinon, non. Comment ?!

« L’Application n’examine pas le contenu des échanges, n’identifie pas le contenu en transit comme étant – ou n’étant pas – protégé par un droit d’auteur, n’enregistre pas de noms de fichier ou d’historique de navigation, et ne transmet pas de données à des tiers ».
Ceci est contradictoire avec la phrase : l’application n’identifie pas, à ce jour, les DRM.

* Page 67:
« Système d’exploitation (Windows, MacOS, Unix, Linux, Android, iOS, etc.) pour les postes terminaux, Linux ou autre pour les routeurs ou boîtiers » -> Une application pour iPhone ? Hummmm :)

Dans le cas d’une application tournant sur la box fournie par le FAI, aucun logiciel ne doit être installé sur l’ordinateur… Comment fait-on pour consulter les logs, gérer les droits d’accès, les clés de chiffrement, être alerté lors d’utilisations « frauduleuses »… ? (Pour cela, le FAI peut alerter l’usager, c’est quelques pages plus bas (page 71).)

La note de bas de page, note 40, est grandiose :
« On n’enregistre pas le nom des fichiers de P2P, de streaming et les URL des sites qui ont participé au téléchargement, mais on peut enregistrer ces identifiants sous forme de fonctions de hachage pour être en mesure de vérifier les actions « suspectes » autorisées par l’utilisateur. » Encore un, on ne fait pas, mais on fait quand même.

* Page 68
Et encore un Kamoulox !
« Systèmes de protection informatique : protection architecturale, protection de logiciels (assombrissement – « obfuscation » – de code exécutable, insertion de code mort, compression et chiffrement de code exécutable avec déchiffrement à la volée, stéganographie), protection des données, protection de l’intégrité du système, fonctions de sécurité (identification, authentification, contrôle d’accès, protection des données, signature). »

* Page 70:
Un logiciel installé sur le réseau est censé pouvoir détecter qu’un ordinateur relié à ce réseau a été démarré sur un LiveCD.
A part en faisant du fingerprint (envoyé des paquets et voir comment le système réagit pour en déduire le système d’exploitation et certains des logiciels installés) par le réseau, c’est bien difficile et encore très facilement falsifiable.

« L’Application peut par ailleurs demander au FAI de vérifier que les clés (WPA) du boîtier ne sont pas des clés faibles (ex : 12345) et de vérifier les adresses MAC des équipements
physiques connectés. Cette fonction de diagnostic donne une bonne assurance de sécurité pour l’amélioration de la sécurisation de l’écosystème du titulaire de l’accès internet, bien
que les adresses MAC soient réinscriptibles par une personne malveillante ». L’application donc doit pouvoir communiquer avec la BOX ? Après tout pourquoi pas. Mais par contre, on adore la fin de la phrase : le filtrage MAC c’est sécurisant. C’est sécurisant pendant 20 secondes, le temps que la personne qui s’est déjà donné du mal pour cracker la clé de chiffrage se rende compte qu’il y a un filtre par MAC. En bref, ça ne sert à rien.

* Page 71:
« On pourrait envisager que le FAI puisse transmettre une alerte (par mail ou par SMS) à l’abonné, si ce dernier le désire. Une telle fonctionnalité, si elle est retenue par l’abonné, devra prévoir une conservation a minima des informations. L’abonné devra avoir été clairement informé par le FAI de la politique de conservation mise en œuvre par ce dernier »
Les données ne devaient-elles pas ne pas sortir du réseau local ? En plus, c’est donc le FAI qui gère les logs ou une partie de ceux-ci ?

« Le moteur de bas niveau peut être situé dans une sonde branchée sur le réseau local quand il s’agit d’une architecture à l’extérieur des postes des utilisateurs » : on a ici la définition parfaite du stochastic packet inspection. En extrémité de réseau avec un dispositif dont l’intelligence se trouve du coté opérateur.
Cf ce billet sur le sujet : http://bluetouff.com/2010/06/27/dpi-spi-et-net-neutrality/
On peut même considérer que l’opérateur historique a commencé à prendre les devants comme en atteste ce petit billet du 24 juin 2010 (écrit sans boule de cristal) :
http://bluetouff.com/2010/06/24/le-deep-packet-inspection-bientot-sur-abonnement-chez-orange/

* Page 72:
Les notifications doivent être « pédagogiques ». A la vue de l’exemple donné, nous n’avons pas vraiment l’impression qu’elles le soient :
« Vous allez téléchargez un fichier en utilisant le protocole : voulez-vous continuer ? ».

* Page 73
Le passage sur l’identification des utilisateurs « une première fois » par cookie sur « le boitier » est délicieuse pour une personne qui fait un peu de sécurité. Est-ce bien la peine de faire du chiffrage asymétrique dans ce cas ??!

* Page 75
« Les notifications de haut niveau doivent proposer à l’Utilisateur les actions (s’il en existe) pour réduire ce risque ».
Donc les notifications de haut niveau s’adressent à l’utilisateur ?

* Page 76:
« L’Application ne doit pas réaliser de DPI (Deep Packet Inspection) dans les réseaux publics ; » -> S’il y avait encore un doute sur le fait qu’elle fait du DPI. Par contre, comment l’application sait qu’un réseau est local ou public ?

« L’Application ne doit pas inspecter le contenu des fichiers téléchargés » -> Ce n’est donc pas un antivirus.

---

Conclusions des rédacteurs

(@bituur_esztreym)

Le doc fourmille d’expressions du genre :
p.8 « Les MS avec cette Application supplémentaire sont définis par leur objectif2 de faire en sorte qu’il n’y ait pas (dans la mesure du possible) de téléchargement illicite via l’accès au réseau public »
p.75 « Les notifications de haut niveau doivent proposer à l’Utilisateur les actions (s’il en existe) pour réduire ce risque »

Révélateur de la conscience qu’ils ont de proposer/vouloir imposer un truc correspondant à une volonté démente & infaisable.

j’ai l’impression que dans la rédaction du bouzin, oscillant sans cesse entre obligation/solutions de sécuriser, pouvoir journaliser, surveiller/ralentir/bloquer etc d’une part, et souci/proclamation larmoyante de la protection de la vie privée, on perçoit bien l’écartèlement impossible dans lequel se sont trouvés les rédacteurs de la chose : ils savent que leurs solutions à la riguidel, dpi etc., sont impossibles, extrêmement complexes et coûteuses, politiquement trop chères, techniquement infaisables, mais comme c’est l’ordre de mission, eh bien ils essayent. Mais ça donne un projet et des specs « de merde ».

(@bluetouff)

Les spécifications de ce dispositif que l’on ne saurait sérieusement qualifier de dispositif de « sécurisation » sont à mi-chemin entre une suite antivirale grand public et un routeur de service Alcatel miniaturisé et dématérialisé placé chez l’abonné. Si on peut se réjouir que ce dispositif ne soit pas placé sur le réseau public, il n’en remplit pas moins les mêmes fonctions.

Il s’agit pour faire simple du Deep Packet Inspection du pauvre : on décentralise le traitement des flux mais au final on a bien le même caractère intrusif.

Par delà la complexité à implémenter une telle solution sans se doter d’une usine à gaz qui altèrera grandement l’expérience de surf des internautes qui se seront laissés piéger par cet attrape gogos, il convient de mettre en garde sur une réalité, démontrée à maintes reprises, que ce logiciel créera plus d’insécurité qu’autre chose. Si vous en doutez, cet incontournable billet de Sid vous remettra les idées au clair : http://sid.rstack.org/blog/index.php/327-du-grain-a-moudre-pour-hadopistes-en-herbe

(@Arrouan)

Les spécifications de cette Application qui est censée « aider » l’internaute à sécuriser son système tendent clairement plus à faire un DPI massif installé chez l’utilisateur (ou sur le réseau ou pas suivant les pages). Bien que de par la lecture du document, on voit que les rédacteurs se sont plus renseignés sur l’état de l’art que le précédent, l’application est quasiment infaisable. Il existe des résultats sur beaucoup de points cités mais la combinaison de cet ensemble semble très complexe. On est à la recherche de la solution de sécurité qui fait tout et qui le fait bien. Or, en général, les solutions de sécurité très spécialisées fonctionnent plutôt bien mais dès qu’elles commencent à proposer tout et n’importe quoi, cela finit justement en n’importe quoi.

La plupart des remarques que j’avais faites sur les spécifications fonctionnelles v1 (http://www.secfault.org/?p=147) sont toujours aussi valables. Il va falloir déployer une usine à gaz, dangereuse, peu contrôlable (contrairement à ce qu’ils veulent bien nous faire croire) et pratiquement inadministrable de par sa complexité.

Pour finir, il me paraît difficile à l’heure actuelle qu’une entreprise connue et reconnue en sécurité veuille produire un tel logiciel. En effet, les fonctionnalités sont complexes à mettre en place, les risques d’attaques, de contestation, etc., sont très fortes. Sorti de quelques acteurs qui ont intérêt à jouer le jeu, je ne suis pas sûr que le retour sur investissement vaille le coût. La labellisation pouvant être facilement perdue mais aussi représentant tout (le logiciel ne se vendra pas sans), qui sera assez fou pour investir dans un logiciel pouvant perdre toute sa valeur du jour au lendemain ?

(@Turblog)

Vu de l’exterieur, le document SFH est sûrement à l’image du présent commentaire multi-mains. Décousu, sans queue ni tête, se contredisant lui-même à de nombreuses reprises, tentant de se justifier à des endroits saugrenus tout en n’apportant aucune justification lorqu’elle serait nécessaire.

J’avais bien compris, depuis le temps, que le but officiel d’hadopi était de défendre les ayant droits. La révision de la première version de la loi par le conseil constitutionnel a obligé le legislateur à contourner le problème, à faire du hacking finalement, pour arriver à ses fins. Ce document est donc, de fait, le fruit de ce hackaton fort mal mené qu’a été hadopi : un mélange entre justification douteuse d’un côté pour s’excuser auprès des intégristes des libertés numériques et un cirage de pompe dans les règles de l’art de l’autre pour amadouer le courroux des ayatolah du copyright.

Il existe de multiples bonnes raisons de vouloir inculquer les bases de la sécurité informatique aux citoyens. La défense du gros compte en banque de quelques milliers de gens n’en est pas une. Si le fait d’aider les citoyens à mieux prendre en main leur vie numérique permet de servir les intérêts des ayants droits, c’est fort bien, mais il ne faudrait pas se tomper de cible.

Il est, en prime, regrettable de constater qu’une telle énergie serait dépensée uniquement pour avertir les gens que le peer2peer de fichiers commerciaux, c’est mal, même si c’est vrai.

En prime, il avait déjà été établi l’an passé qu’aucun logiciel ne pourrait dédouaner un utilisateur qui serait pris dans les filets d’HADOPI. Trop de choses sont falsifiables. Dans ce cas, pourquoi continuer avec ces histoires de journaux archivant l’utilisation ?

Pour ne pas aider, du début à la fin du document, il est fait l’hypothèse que chacun garde jalousement ses identifiants et fichiers de clés personnels bien au chaud sans jamais laisser la possibilité aux autres membres de la famille de mettre la main dessus. Outre la bonne ambiance qui en découle, je vois mal le « bon père de famille » locker sa session quand il va faire ses besoins préssants pour éviter que son Jean-Kévin de 12 ans ne récupère la clé permettant d’effacer ses méfaits du fichier de log. Les « experts en sécurité » ne le font déjà pas en entreprise, alors les utilisateurs normaux chez eux…

Et il ne faudrait pas, surtout, continuer à tomber dans le panneau de la sécurité à tout prix. Nous allons y perdre notre liberté.

(@Erebuss)

La lecture de ces spécifications fonctionnelles HADOPI amène à se poser la question : A quoi sert réellement cette application?

-Etre pédagogique? … la gestion des notifications ne remplira jamais cet objectif.
-Sécuriser la connexion? … vu la complexité technologique requise, elle risque de créer plus de failles qu’autre chose.
En revanche, elle risque de faire croire à Monsieur Tout Le Monde qu’il est protégé alors que cela ne sera pas le cas.

De plus, c’est sans compter la simple difficulté de réaliser un tel logiciel labelisable (entre les contradictions, les « si », les « peut-être »).
La base des spécifications auraient du être précises et ne laisser aucun ambiguité avec éventuellement des fonctions optionnelles.

A moins que le seul but d’un tel logiciel soit au final de dégrader l’expérience utilisateur et de rendre toute évolution technologique comme « suspecte » afin d’éviter l’émergence de nouveaux logiciels ou protocoles, comme Napster l’avait fait en son temps en démocratisant le P2P.

Dans l’état, ce document est tout sauf rassurant.