Aidons l'HADOPI dans sa dure lutte
Par Benjamin Bayart le vendredi 02 juillet 2010, 00:49 - Lien permanent
Puisque, à en croire Eric Walter, nous pourrions être de dangereux hors-la-loi (c'est en tous cas ce que laisse entendre Eric Walter quand il déclare à silicon.fr C’est à la FDN de nous contacter, la loi s’impose à tous.
et On travaille avec ceux qui sont attentifs au respect de la loi.
, il est urgent que FDN fasse preuve de la meilleure volonté possible.
Du respect de la loi
C'est un point sur lequel je tiens à insister, je l'ai évoqué cent fois avec les gens qui venaient suivre les débats à l'Assemblée Nationale: FDN appliquera la loi, toute la loi, mais rien que la loi. Et, en dehors de la loi, il n'y a que la signature d'une convention, validée par le Bureau de l'association, et qui ne soit pas dénoncée par l'Assemblée Générale, qui puisse nous engager. En particulier, FDN n'étant pour le moment membre d'aucun organe représentatif, d'aucune fédération[1], ne peut être engagée que par sa propre signature.
La loi, plus exactement un décret d'application pris en vertu de la loi, et (selon nous) en dehors des formes légalement requises, indique que l'interconnexion entre la HADOPI et les FAIs se fait selon les règles d'une convention signée, ou à défaut, d'un arrêté publié par les ministres concernés. Ça ne dit pas que les FAIs doivent s'empresser d'aller quémander une convention. Ça dit que si la HADOPI veut aller plus vite que la prise d'un arrêté interministériel, il est de bon ton d'aller discuter avec les FAIs.
Pour s'en convaincre: en l'absence de convention, la mission de FDN, qui est depuis 1992 de permettre à ses adhérents d'accéder à Internet, est parfaitement remplie. À l'opposé, celle de la HADOPI ne l'est pas, ou est pour le moins retardée.
Donc, évoquer dans une interview à la presse (et pas dans le contexte moitié-potache moitié-pamphlétaire d'un blog) que nous pourrions n'être pas scrupuleusement attentifs au respect de la loi, c'est à deux doigts de la diffamation.
Un président d'association qui s'exprime sur un blog peut se permettre certaines moqueries, tant qu'elles restent dans les bornes. Par contre, il me semble qu'un secrétaire général d'une Haute Autorité Indépendante est tenu à un tout petit peu plus de rigueur intellectuelle quand il s'exprime dans la presse...
De la bonne volonté
Toutefois, dans un esprit d'apaisement, et par habitude du logiciel libre et des contenus générés par les utilisateurs, nous allons proposer ici ce que pourraient être les termes d'une convention entre FDN et la HADOPI[2] sur l'interconnexion nécessaire pour l'identification des adresses IP.
- L'interconnexion se ferait en HTTPS[3], sur le port 443, vers une adresse IP sur les serveurs de l'association réservée à cet usage, et chiffrée par un certificat émis par notre autorité de certification[4]
- L'accès à l'interface automatique serait bien entendu uniquement via un échange de login et de mots de passe, permettant un première forme d'authentification[5].
- Les requêtes se devraient d'être transmises par la HADOPI depuis une (ou des) adresse IP explicitement indiquées comme y étant autorisées[6]. La HADOPI s'engageant à avoir une configuration similaire de son côté, n'autorisant les requêtes que depuis les IPs spécifiées par FDN.
- Les requêtes auraient la forme de fichiers XML simples[7]. Basiquement une DTD qui prévoit un élément englobant, typiquement requetes, contenant une liste d'éléments simples, typiquement requete, au contenu vide, ayant chacune trois attributs (identifiant unique de requête[8], adresse IP concernée, date concernée, au format ISO). La balise englobante devra bien entendu porter plus d'attributs (identifiant du FAI concerné, identifiant de l'émetteur de la requête, numéro de série du fichier, nombre de requêtes contenues dans le fichier, etc).
- Les requêtes seraient à déposer par un upload HTTP standard (donc, en POST, avec du form-multipart). Les réponses étant disponibles en GET, le plus simplement du monde, dans les minutes ou heures qui suivent.
- Les fichiers de requêtes seraient chiffrés avec une clef publique fournie par FDN, et signés avec une clef privée propre à la HADOPI, indiquant donc que le fichier vient bien de la bonne source, et est bien à destination du bon FAI[9].
- Les fichiers de réponses seraient eux aussi en XML simple, avec cependant un peu plus d'attributs pour l'élément interne (adresse postale, nom, prénom, adresse mail quand elle est connue, etc), contenant les coordonnées associées à l'abonnement Internet correspondant à cet enregistrement horodaté[10].
- Les fichiers de réponses seraient chiffrés avec la clef publique de la HADOPI (complémentaire de celle ayant servi à signer les requêtes) et signés par la clef privée de FDN[11].
Bien entendu, une facture, portant les références des requêtes, serait communiquée à la HADOPI, immédiatement après que les requêtes auraient été traitées, appliquant les barêmes en vigueur. Les factures une fois réglées, les fichiers de requêtes signés-chiffrés seraient alors détruits[12].
Du logiciel libre
Cet embryon de spécification est, bien entendu, libre de droits. Si la HADOPI le souhaite, FDN se fera un devoir de transformer cet embryon (cependant déjà clair) en un projet de cahier des charges. Il serait alors, lui aussi, sous une licence permettant sa libre réutilisation (probablement CC-by).
Enfin, si une telle interconnexion venait à être réalisée, la partie FAI (implémentée par FDN[13], elle serait publiée elle aussi sous une licence permettant une libre ré-utilisation (probablement GPL[14]).
Une telle approche permettrait d'ailleurs d'avoir des propositions techniques valables pour l'ensemble de FAIs, basées sur une spécification simple, connue, reconnue comme sécurisée, et aisément implémentable dans n'importe quel langage moderne.
Notes
[1] Ça, ça devrait changer, lors de la création de la fédération d'opérateurs associatifs, mais je serai surpris qu'elle suive une direction différente. Le monde associatif est trop complexe et foisonnant pour être mis en coupe réglée.
[2] C'est un des points sur lesquels je me perd, et je n'ai pas le courrage d'aller vérifier exactement dans le texte. Je ne sais plus si c'est la HADOPI qui est interconnectée avec les FAIs et en charge de transmettre les dossiers à la CPD, ou si c'est la CPD qui réalise ce traitement dans le cadre de son instruction du dossier. Je suppose ici que c'est la HADOPI, le raisonnement serait à transposer directement en cas d'erreur de ma part,
[3] Forcément, il circulera sur cette interface des données sensibles, qui ne doivent donc pas transiter en clair. Le chiffrement des fichiers ne chiffre que les fichiers eux-mêmes, et pas toute la négociation protocolaire HTTP. Le SSL est donc de rigueur.
[4] Pourquoi notre propre autorité de certification? Pour être absolument certain que le certificat ne puisse être révoqué que par nous, qu'il ne dépende que de nous, et donc qu'il n'engage que nous.
[5] Bien entendu, ce n'est pas de la haute sécurité, mais ça évite simplement de recevoir des fichiers farfelus. Et n'exonère pas de chiffrer et signer les données échangées
[6] Comme il a été dit en commentaire du billet précédent, certainement pas dans le but d'identifier l'émetteur, mais seulement dans le but d'écarter des usurpations d'identité grossières, et par soucis de protéger la machine de FDN d'un certain nombre d'attaques possibles.
[7] Les données échangées sont très simples, donc rien n'exige de mettre en branle des usines à gaz comme XMLRPC ou SOAP. Du XML tout ce qu'il y a de plus bête est bien plus léger à traiter, typiquement manipulable en XPath, ou pour les puristes à grands renfort d'expressions régulières.
[8] Au libre choix de la HADOPI, typiquement un numéro de dossier ou quelque chose qui ressemble.
[9] Sur des systèmes automatisés, surtout pendant les phases initiales, ça s'est déjà vu, des fichiers qui se mélangent. Et il serait innacceptable qu'un fichier à destination de FDN puisse être lu par un autre FAI, ou que FDN puisse lire un fichier à destination d'un autre FAI.
[10] C'est une nuance importante dans le fonctionnement de FDN, il a les adhérents, d'une part, qui sont les gens qui ont le droit de vote en Assemblée Générale, et il y a d'autre part les abonnés qui sont titulaires d'un login permettant de se connecter sur nos systèmes. Il est fréquent qu'un adhérent ait plusieurs abonnements (pour ses parents, ses enfants, etc).
[11] Pour les spécialistes en sécurité, rien que de très banal, signature et chiffrement par clefs asymétriques, bref du GPG de base.
[12] Il est évident que l'association se doit de les conserver pour justifier, autant que de besoin, de sa bonne foi dans l'émission de la facture, et pour pouvoir corriger en cas d'erreur.
[13] Et dont les frais de développement seraient à la charge de la HADOPI, en vertu des jurisprudences applicables, puisque ces développements ne sont pas nécessaire à la satisfacton de l'objet statutaire de l'association mais seraient réalisés dans le cadre d'une contrainte légale.
[14] Le développement étant financé par le contribuable, au final, il nous semble absolument évident que le code résultant ne peut pas ne pas être sous une licence libre.
Commentaires
Un point me dérange toujours : l'identification par l'adresse IP.
Sans rentrer dans le débat de la fiabilité, je me pose la question du NAT, utilisé par certains FAI (des FAI Wifi en zone blanche par exemple, mais pas que).
Le NAT n'est pas propre, mais rien ne l'interdit légalement.
Hors, sans le port, il va être difficile de choisir quel utilisateur retourner dans ce cas.
Est il prévu de relever (et donc communiquer aux FAI) le port utilisé ?
Enfin, la qualité de FAI est elle précisée ?
Un hébergeur (fournisseur de services, mais pas de connectivité internet direct au sens FAI), peut être utilisé pour du VPN ou de la seedbox. Il peut donc également être concerné.
Magnifique. Clair, carré, précis. Conforme à l'état de l'art côté informatique, à la législation et à la jurisprudence (pour ce que j'en puis juger) côté droit. Nan, il n'y a pas à dire, c'est beau.
Je n'aurais qu'une objection à formuler, et encore le mot objection est un peu fort, disons une réserve. Et j'allais dire une réserve de principe, mais ça ne colle pas. Plutôt une réserve technique énoncée juste pour le plaisir de pinailler (ou de se la péter, oui, peut-être un peu). Et je préviens à l'avance, ce qui suit va être chiant.
Ce sont le point n° 4 et la note n° 7 qui me font réagir. Dès lors qu'il est question de XML, la notion de simplicité est elle-même assez compliquée. Qu'est-ce qu'un document XML simple ? Est-ce un document avec peu de niveaux d'arborescence ? Est-ce un document très peu permissif dans sa structure et son contenu ? Dans la majeure partie des cas, et je crois dans le cas évoqué ici, cette dernière hypothèse est à mon avis la bonne. Du moins si j'ai bien compris.
Si j'ai bien compris, on parle d'un document XML dont la totalité des rubriques présentes sont connues à l'avance. Pas besoin de se poser la question de savoir si la rubrique A sera là, pas besoin de se poser la question de savoir si la rubrique B sera là. Les deux doivent être là. Et la rubrique B contiendra de zéro à dix rubriques C, qui ne contiendront rien d'autre que du texte, alors que la rubrique A ne contiendra qu'un texte, de 0 à 255 caractères alphanumériques.
Ouais ! Ça c'est ce que j'appelle un document XML simple. Aucune alternative, on sait à l'avance quoi contiendra quoi. Tellement simple qu'on peut se poser la question de l'intérêt de le mettre en XML. Tellement simple que le seul intérêt de le mettre en XML se résume aux DTD ou à XML-Schema. Ce qui, soit dit en passant, n'est pas rien, pour d'autres raisons, mais quand même, la seule raison dans ce cas pour utiliser XML plutôt que, par exemple, JSON, est la facilité à déterminer une méta-définition des données. Ce qui est un atout important, mine de rien. Forcer la forme, c'est tout l'art de la procédure juridique, qui sur ce point précis rejoint l'informatique.
Et là, du coup, il me vient à l'esprit qu'il ne me serait absolument pas choquant qu'un DTD ou un schéma XML soit un jour publié au Journal Officiel pour normaliser la forme d'un document ayant telle ou telle valeur juridique. En fait, j'espère qu'on y viendra.
Mais j'ai vachement dérivé dans mon post. En fait, l'essentiel de ce que je voulais dire à l'origine, c'est que de nos jours plus personne n'utilise directement les expressions régulières pour analyser la structure d'un document XML, même simple. SAUF à titre d'exercice en matière d'expressions régulières, parce que c'est rigolo. Mais dans la pratique, on utilise des modules déjà écrits.
Quoi ? J'avais prévenu que c'était du pur pinaillage, non ?
Il vient de me venir à l'esprit que le coup de la DTD ou du schéma XML publié au Journal Officiel s'est peut-être déjà produit, j'en sais rien en fait.
C'est drôle, j'avais commencé à expliqué à quelqu'un pourquoi le coût d'identification des IP serait important du fait de la complexité du protocole à mettre en place.
Et je lui faisais aussi remarquer que ce qui coûterait le plus cher dans ce protocole, ce serait les outils et moyens de protéger les adresses IP des serveurs aux 2 bouts de la chaine contre une attaque DOS. Attaque qui a toute les chances de se produire dès que ces adresses seront connues...
Bonjour,
Y a-t-il d'autres données sensibles que les fichiers xml chiffrés/signés et le login/mot de passe?
De plus la note 5 explique que le https "n'exonère pas de chiffrer et signer les données échangées", or le https chiffre déjà toutes les données, donc je vois pas l'intérêt de chiffrer en plus les fichiers xml: seul le serveur et le client ont accès à la version en clair.
La signature est cependant effectivement nécessaire puisque le https tel qu'utilisé habituellement ne permet qu'une authentification du serveur, et donc pas du client; et https n'est fait que pour protéger des données temporaires: une connexion, alors qu'ici la conservation des signature des demandes et des réponses est certainement utile pour les deux parties.
Le chiffrement en interne chez FDN et chez l'HADOPI sont indépendants du protocole de communication à mettre en place, non?
Bonjour,
Concernant l'identification de l'adresse IP, n'y a t-il pas possibilité de veiller à ce qu'elle soit associée à l'adresse MAC du contrôleur Ethernet utilisant la ligne associée à l'adresse IP et à la ligne téléphonique (unique) utilisée par cette IP ?
En réponse: non, depuis un accès Internet, la seule chose un peu fiable qu'on peut savoir sur un autre internaute, c'est son adresse IP, tout le reste est sujet à spéculation (ce sont des données transmises par sa machine, qui peut bien transmettre ce qu'elle veut). Et cette donnée est, par ailleurs, assez peu fiable. Elle ne fait qu'indiquer quel chemin on pris les données.
Prenons un parallèle simple: des messages sont échangés entre "15 rue des bois, Villeneuve" et "12 rue du moulin, Vielleville". Que sait-on de qui a lu et écrit ces messages? Rien. Sait-on si même leurs distinataires résidaient là? C'est probable, mais pas certain, quelqu'un a pu, par exemple, intercepter le courrier (le facteur, pour lui, c'est facile, mais pour les autres ce n'est pas impossible, c'est seulement délicat). Ce qu'indiqueraient les adresses sur les enveloppes retrouvées par la police, ce n'est qu'un indice, pas une preuve. Il en est de même pour une adresse IP, elle montre qu'une connexion a eu lieu vers une destination, pas qu'elle a abouti. Et encore moins qui était derrière.
Cela ne fiabiliserait-il pas un ciblage plus juste ?
Cordialement.
Question sérieuse: est-ce qu'il existe une loi ou une jurisprudence qui impose l'utilisation de formats et protocoles ouverts et librement implémentables pour les échanges électroniques entre une administration publique et une entité (ici associative) soumise à une obligation légale?
C'est-à-dire: s'ils décident d'envoyer leur requêtes dans un .doc DRMisé (qui impose d'utiliser Microsoft Office donc d'accepter sa licence), ou dans une archive au format .rar (qui impose d'accepter la licence de Alexander Roshal), est-ce que FDN peut refuser de passer un contrat avec une entité privée qui deviendrait un point de passage obligatoire pour respecter une obligation légale?
En réponse: basiquement, ni l'un ni l'autre. Les administrations choisissent bien les contraintes techniques qu'elles veulent (il suffit de voir le nombre de sites uniquement compatibles avec IE qu'on a pu avoir dans l'administration pour s'en convaincre). Mais ces contraintes ne peuvent pas non plus être délirantes, et FDN pourrait tout à fait arguer du surcoût et du manque de trésorerie pour se soustraire à son obligation (en gros, envoyer la facture, et ne pas satisfaire à l'obligation tant que la facture n'est pas payée).
Après, tout est question d'équilibre et de raisonnable. Il y a des juges administratifs pour ça.
Si tel devait-être le cas (Grunt), ne nous trouverions pas confronté à l'apologie d'une marque préférentielle plutôt que diverses autres, et alors qu'il existe d'autres outils répondant à des normes libres internationales ?
N'est-ce pas aller à l'encontre de la constitution européenne qui prévoit que "la concurrence doit être libre et non faussée"...
Imposer des règles normatives faisant référence à des produits fermés et propriétaires nous conduit très loin des "convictions officielles" qui ont permis au Président de la République de signer cette constitution qu'il nous a forcer à adopter !
En réponse: tu raisonnes sur de l'abstrait. C'est risqué.
Ainsi, dans la vie de tous les jours, l'administration prévoit une règle simple, intéropérable, valable pour tous: se déplacer, et écrire sur du papier. Parfois, une solution autre, plus efficace, est prévue, permettant de faire les démarches en ligne. Mais ce n'est qu'une solution alternative.
Ici, a l'opposé, nous avons affaire à une contrainte qui ne relève pas de la réglementation de l'activité des FAIs (par exemple, les obligations liées au code de la consommation s'imposent, et entraînent des charges pour les FAIs), mais est en fait une des obligations de l'État (faire la police pour détecter et caractériser les infractions), et l'État se décharge d'une partie de sa responsabilité sur les FAIs, alors que c'est sans rapport avec leur activité. Les opérateurs de téléphonie doivent garder des informations pour la facturation, l'État ne paye pas, c'est un impératif lié à l'exercice de leur métier. Ils doivent aussi garder des traces pour la police, et répondre aux questions de juges. Le traitement de la question du juge est facturé, parce qu'il ne relève pas du métier normal du FAI.
Si on revient à de l'abstrait. Si l'État crée une nouvelle obligation qui soit assise sur des choix techniques, alors il y a de grandes chances pour que l'intéropérabilité soit une obligation. Par exemple, s'il devient obligatoire de déclarer ses impôts par Internet, les contraintes d'interopérabilité seront beaucoup plus grandes (le site devra être plus accessible aux handicapés, par exemple).
A moins qu'il ne doive exister des liens obligatoires entre la loi, son exécution, les outils mis en oeuvre, les personnes qui les mettent en oeuvre, les personnes qui ont déposées les brevets et les personnes qui vont en tirer d'excellents profits ?
@Artur9
Ils ne sont plus à une contradiction majeure près non ?
La question de Grunt est pertinente d'un point de vue "moral" mais d'un point de vue financier pas tellement dans la mesure où le paiement des licences sera à la charge de l'état puisque les frais de développement le seront.
De plus, je doute qu'une telle loi existe puisque dans le cas du mouchard HADOPI s'imposant aux particuliers ils n'ont pas eu à imposer l'interopérabilité aux éditeurs potentiels du logiciel de "sécurisation". A moins que l'opposition ait "oublié" d'utiliser une telle arme juridique ...
En réponse: tu mélanges. La ceinture de sécurité est obligatoire, et pourtant elle est a ta charge. Les informaticiens lisent les lois comme si c'étaient des normes absolues, ce qu'elles ne sont pas.
@Marco46:
Il ne s'agit pas que d'un problème de coût. Je trouve étonnant (comme semble l'affirmer Benjamin) qu'une administration puisse imposer une technologie propriétaire si les coûts ne sont pas délirants.
Sur le principe, ça me pose un problème. Imaginons qu'ils utilisent des archives au format RAR. Le binaire pour les extraire est gratuit, disponible sur un nombre raisonnable de plateformes (Windows, Mac OS, Linux..), ce n'est pas un problème de coût (pas besoin d'acheter des licences ou du matériel).
Pourtant, ça amènerait la situation suivante: l'association FDN se verrait contrainte, pour satisfaire à ses obligations légales, d'accepter de passer un contrat avec Alexander Roshal (auteur du format RAR, qui est le seul à en connaître les secrets et donne des binaires propriétaires gratuits pour le lire).
Pourquoi les contrats proposés par un tiers devraient-ils être le point de passage obligatoire d'une entité afin de satisfaire à une obligation légale? Autrement dit, l'utilisation de ce format par Hadopi reviendrait, de facto, à dire:
"Tous les FAI de France doivent être entièrement d'accord, sans réserve, avec chaque terme du contrat de licence de Winrar ou unrar." Lesquels termes ne sont pas forcément anodins, peuvent entraîner des obligations qui n'ont rien à voir avec la mission de Hadopi. Les clauses du genre "Je décline toute responsabilité si mon binaire plante votre système ou cause une faille de sécurité", par exemple: un FAI peut vraiment se retrouver contraint d'accepter ça?
Oui, il y a des administrations qui commettent ce genre d'aberration, mais ce n'est pas parce que ça se fait, que c'est légal: c'est peut-être juste que personne n'a pensé à porter l'affaire devant la justice. Comme dans le cas des accès limités à un NAT avec parefeu filtrant vers Internet, vendus comme de l' "Internet mobile" alors que ce n'en est pas. Ou comme dans le cas des racketiciels, au sujet desquels plusieurs constructeurs ont été condamnés. Ou comme les institutions qui décident d'acheter les logiciels d'une entreprise en particulier sans faire d'appel d'offre afin de mettre en concurrence (au Québec, ça a bougé: http://benefice-net.branchez-vous.c... ).
Bref, je pense qu'il faut insister sur la nécessaire intéropérabilité (garante de l'indépendance vis à vis d'un éditeur en particulier) d'une solution qui s'imposerait à FDN en tant que FAI. Peut-être que certains s'en fichent, moi non et j'espère que FDN non plus ;)
Excellent billet,
Suivant depuis peu toutes ces histoires d'HADOPI, CPD et consorts, on voit quand même très bien l'abération de cette loi depuis son début, jusqu'à sa mise en application.
Qu'en est-il du droit de FDN de refuser de passer une convention du type "acceptez ce contrat pour pouvoir vous interopérer avec nous). Faudrait-il en revenir à des formes de communication connues de tous ? (courrier postal par exemple, avec AR pour assurer le suivi du courrier.) Le tout bien évidement géré à la vitesse que peut se le permettre l'association et les gens qui la compose.
Je sais que ça a l'air de vouloir leur mettre des batons dans les roues, et j'avoue que ça n'est pas forcément faux; ceci dit eux ne se gènent pas pour nous en mettre, et ça ne leur pose aucun problème de conscience.
Une fois de plus, la qualité fournie par les FAI alternatifs (qui plus est associatifs) est encore démontrée dans cette histoire ! Combien à parier que le service juridique de SFR (et autres) s'est empressé de contacter les Texellistes pour leur proposer des solutions d'interfaçage ?
Je souhaite bon courage à FDN, certainement pas à cette HADOPI(po).
Bonne soirée a tous. Bon surf, et "souriez, vous êtes filmés".
Oui FDN à le droit de refuser la convention, mais dans ce cas elle doit utiliser la méthode décrite dans l'arrêter dont par l'article 8 du décret 2010-236.
Arrêter qui n'existe pas (encore)...
@Cid:
Ah, tu me rassures. Il existe donc un "fallback" vers une méthode intéropérable à base de papier, de crayon et de langue française.
Non, puisque l'arrêter n'existe pas il n'existe actuellement rien en cas d'absence de convention.
@Jacques Pyrat
Le fait de restreindre les accès à des adresses identifiées au préalable permettrait, avec un bon parefeu (celui d'OpenOffice ?) de limiter les risques d'attaques par déni de service.
(sans l'éliminer totalement)
Cette architecture technique est celle d'ipsite, l'interface technique de france telecom pour la boucle locale.
Cette industrialisation devrait aider les opérateurs de n'importe quelle taille d'accéder à la boucle locale. J'espère que pour la FTTH ça sera similaire.
Bon... souvent, les informations échangées sont plutôt simples, Une connexion TCP en SSL/TLS avec ce qu'il faut pour faire des transactions en clé/valeur en utf-8 aurait été plus que suffisant (comparé à l'usine à gaz des web services).
Bonjour ou bonsoir.
Le dernier décret HADOPI est sorti:
http://www.numerama.com/magazine/16...