GuiGui's Show

Links per page: 20 50 100

◄Older

page 51 / 297

Newer►

La législation des journaux informatiques
En France, comme dans le reste de l'Union européenne (UE) et un peu partout ailleurs, les opérateurs de communications électroniques ouverts au public et les hébergeurs informatiques de contenus accessibles au public sont tenus de conserver certaines données durant un certain temps pour certaines finalités légales à tendance répressive (enquêtes pénales, renseignement, et droit de communication des administrations). On nomme ça la rétention des données de connexion. (Cette désignation est trompeuse puisque la conservation d'autres jeux de données est également obligatoire.) Le régime juridique des données de connexion est distinct de celui des interceptions (portant sur le contenu des communications) qui ne sera pas traité ici.

Durant les dix dernières années, ce cadre a évolué, donc je voulais faire le point. De plus, je me suis toujours demandé quelles obligations précises pèsent sur moi avec mon site web perso, mes serveurs emails et de messagerie instantanée persos, etc. Voyons ça.

Dernière mise à jour : août 2025.

Plan :
Historique
- 1995 : l'article 13 de la directive européenne 95/46/CE sur la protection des données à caractère personnel, l'ancêtre du Règlement général sur la protection des données à caractère personnel (RGPD), permet aux États de déroger à ses dispositions pour la sécurité nationale, la sécurité publique, la défense nationale, la poursuite des infractions pénales, etc.
- 1997 : l'article 14 de la directive européenne 97/66/CE sur la vie privée dans les télécommunications, l'ancêtre de la directive e-privacy qui complète et modifie la directive de 95, permet les mêmes dérogations.
- 2000 : la loi française 2000-719 codifie, dans la loi 86-1067 relative à la liberté de communication, l'obligation, pour les Fournisseurs d'accès à Internet (FAI), les hébergeurs, et les Fournisseurs de services Internet (FSI) de conserver les données permettant l'identification de l'auteur d'un contenu. On est donc avant le 11 septembre, le Patriot Act, blablabla, hein. ;)
- 2001 :
  
  Suite aux attentats, la loi française 2001-1062 sur la sécurité quotidienne (LSQ) codifie, dans l'article 32-3-1 du Code des postes et des communications électroniques (CPCE), la conservation et l'accès aux données de connexion pour la recherche, la constatation, et la poursuite des infractions pénales. Mais la pratique était déjà bien établie sur la téléphonie (source, page 40). (C'est aussi la LSQ qui codifie le délit de refus de prélèvement génétique et celui de refus de communication d'une convention de déchiffrement) ;
  
  Dès lors, certaines administrations sont autorisées à se faire communiquer les données de connexion pour l'exercice de leurs missions dans le cadre du droit de communication. Dès 2001, les douanes (article 65 du Code des douanes). 2002, le fisc (L83 du Livre des procédures fiscales). HADOPI dès sa création en 2009, bien évidemment. Etc.
- 2002 : dans son article 15, la directive européenne 2002/58/CE, dite e-privacy sur la vie privée dans les communications électroniques, qui succède à la directive de 97, permet aux États, par dérogation / exception, d'adopter des dispositions qui restreignent ses dispositions pour la sécurité nationale, la sécurité publique, la prévention, la détection et la répression d'infractions pénales, et les utilisations frauduleuses d'un système de communications électroniques. Cette directive ne s'applique pas aux hébergeurs (source, page 13). (Sans rapport : bien entendu, le RGPD reste applicable aux hébergeurs.)
- 2004 : l'obligation prévue dans la loi 86-1067 est déplacée dans l'article 6 de la loi 2004-575 dite de confiance dans l'économie numérique (LCEN). Le L32-3-1 CPCE est déplacé dans le L34-1 CPCE.
- 2006 : adoption de la directive européenne 2006/24/CE qui précise et oblige la rétention des données de connexion « à des fins de recherche, de détection et de poursuite d'infractions graves ». Le cadre français, antérieur, n'en est pas une transposition, mais y est conforme. Normal, la France poussait l'UE à adopter ladite rétention et elle n'a pas différé l'application de la directive. À l'inverse, l'Allemagne a traîné des pieds pour transposer cette directive.
- 2011 : le décret 2011-219, précisant la LCEN, est, avec l'ancienne version du R10-13 du CPCE, la dernière définition du régime français avant le grand chamboulement. Il prévoit la conservation des données de connexion suivantes : données d'identité (nom, prénom, etc.), d'abonnement (adresse IP, numéro de téléphone, etc.), de facturation, de trafic (appels, SMS, donc fadettes, date+heure+durée de chaque communication, etc.), et de localisation (d'un smartphone, à la granularité de la couverture d'une zone par une antenne).
- 2013 : la Loi de programmation militaire, notamment son article 20, octroie, pour la première fois, l'accès aux données de connexion aux services de renseignement (au sens très large, il existe de nombreux « services de renseignement du second cercle »), et aux agents des ministères de l'économie et du budget (articles L246-1 et L246-2 du Code de la sécurité intérieure, CSI) pour la sécurité nationale, la sauvegarde des éléments essentiels du potentiel scientifique et économique de la France, ou la prévention du terrorisme, de la criminalité et de la délinquance organisées et de la reconstitution ou du maintien de groupements dissous (L241-2 CSI). En réalité, le L246-2 CSI parle d'« informations ou documents » et le L246-1 « des informations ou documents traités ou conservés » par les intermédiaires techniques, ce qui est susceptible de dépasser le cadre des données de connexion. L'accès est en différé (L246-1 CSI) ou en temps réel (L246-3 CSI).
  
  Les articles L246-1 et suivants seront renumérotés L851-1 et suivants par la loi Renseignement de 2015 à laquelle ils servent de fondement pour l'accès, différé ou en temps réel, aux données de connexion dans un contexte de renseignement.
- 2014-2022 : dans plusieurs arrêts, via plusieurs questions préjudicielles renvoyées par plusieurs juridictions nationales, la Cour de Justice de l'UE (CJUE) invalide la directive 2006/24/CE et précise les exigences découlant du droit de l'UE. Arrêts notables (il y en a d'autres) : Digital Rights Ireland (2014, communiqué de presse), Tele2 Sverige et Watson (2016, communiqué de presse), La Quadrature du net ‒ LQDN ‒ et Privacy International (2020, communiqué de presse), Prokuratuur (2021, communiqué de presse), Commissioner of the Garda Síochána (2022, communiqué de presse), et SpaceNet / Telekom Deutschland (2022, communiqué de presse).
  
  La conservation préventive, généralisée et indifférenciée des données de connexion est une atteinte disproportionnée à la vie privée, même si lesdites données ne sont pas exploitées, dès lors qu'un ensemble de données est susceptible de permettre de tirer des conclusions très précises concernant la vie privée d'une personne. Par dérogation :
  
  Les données relatives à l'état civil (identité) peuvent toujours faire l'objet d'une conservation généralisée et indifférenciée pour tout motif (LQDN, point 159) ;
  
  Dans le cadre de la lutte contre une menace grave, réelle, et actuelle ou prévisible pesant sur la sécurité nationale, une conservation généralisée et indifférenciée des données de trafic et de localisation est possible ;
  
  Dans le cadre de la lutte contre la criminalité grave ou contre les menaces graves à la sécurité publique, la conservation, avec un historique, des données de trafic et de localisation doit être ciblée et non-discriminatoire (par zone géographique, par ex.). Si aucune rétention obligée par la loi, alors il ne reste qu'une conservation rapide (quick freeze), prévue par la Convention de Budapest de 2001 sur la cybercriminalité, c'est-à-dire d'une injonction de conserver, le temps de l'enquête, ce que l'intermédiaire technique détient à l'instant T pour une/des personnes. C'est donc une conservation pour le présent et le futur, mais aussi pour le passé si l'intermédiaire technique conserve des données de connexion pour ses besoins propres (facturation, fonctionnement du service, sécurité du réseau, etc.) ;
  
  La conservation généralisée et indifférenciée de l'adresse IP source d'une connexion (communication) est possible pour les mêmes finalités.
  
  (Digital Right Ireland, DRI) Des critères objectifs doivent limiter au strict nécessaire le nombre de personnes autorisées à accéder et à réutiliser des données de connexion les plus intrusives, y compris au sein des services de renseignement ;
  
  (Tele2) La demande d'accès aux données de connexion les plus intrusives doit être motivée, notamment dans le cadre de la prévention, détection et poursuite des infractions pénales ;
  
  (Prokuratuur) L'accès aux données de trafic et de localisation doit être validé / contrôlé par une autorité judiciaire ou administrative indépendante et extérieure à l'autorité qui demande l'accès afin d'exercer un contrôle objectif, impartial et à l'abri de toute influence extérieure. Pas besoin pour les données d'identité (à ce stade, ce n'était pas explicite dans la jurisprudence de la Cour, mais ça le sera). Conséquence en matière pénale : l'autorité de contrôle ne doit pas être impliquée dans la conduite de l'enquête pénale et elle doit être neutre vis-à-vis des parties. Contrôle a priori ou a posteriori dans un bref délai ;
  
  (Prokuratuur) Si la conservation des données de connexion n'est pas conforme au droit de l'UE, alors l'accès n'est pas conforme ;
  
  (Garda Síochána) Il est interdit d'accéder aux données de trafic et de localisation conservées pour préserver la sécurité nationale pour une finalité présentant un intérêt inférieur, comme la criminalité (= pas de porosité des finalités). En revanche, une finalité supérieure, comme la sécurité nationale, permet d'accéder aux données (de trafic et de localisation) conservées pour une finalité inférieure, comme la criminalité grave. En comparaison, l'article 5(1)b du RGPD autorise la réutilisation seulement pour des finalités compatibles, donc rien d'extraordinaire ici ;
  
  (LQDN, points 190-191) Les personnes dont les données de connexion ont été consultées doivent être informées (quand cela n'est plus susceptible de comprometre l'enquête ou les missions de l'autorité). Là encore, le RGPD et la directive police-justice prévoient ça dès que ça ne nuit plus à l'enquête, donc rien de neuf ;
  
  (SpaceNet) La conservation et l'accès aux données de connexion sont deux ingérences distinctes dans les droits fondamentaux, donc elles nécessitent deux justifications distinctes. Ainsi, il n'est pas possible de compenser une collecte élargie par un accès restreint (ce qui a été l'une des planches de salut des États). La collecte est déjà une ingérence grave dans les droits fondamentaux, peu importe si les données de connexion sont utilisées par la suit ou non (je te laisse faire le parallèle avec une sextape : le fait que la vidéo existe constitue un risque de réutilisation malsaine après coup) ;
  
  (SpaceNet) La CJUE se montre inflexible. Le régime allemand post-2015 prévoyait : conservation 4 semaines pour la localisation, 10 semaines pour le reste, dans les deux cas uniquement pour les infractions particulièrement graves, sous le contrôle préalable d'un juge, par un mécanisme de conservation rapide, avec un cahier des charges technique pesant sur les opérateurs, etc. Pourtant, la CJUE le retoque car, indépendamment de la durée de la conservation, de la nature des données conservées, de la quantité de données conservées, et des conditions d'accès, il était « susceptible de permettre de tirer des conclusions très précises concernant la vie privée d'une personne ». Conclusion : la modulation de la durée, de la quantité, etc. n'a aucune incidence sur le raisonnement de la CJUE. On retrouve ce point dans Prokuratuur.
  
  Analyse par les commentateurs :
  
  La CJUE se fonde sur la Charte des droits fondamentaux de l'UE, ce qui lui permet de tacler indifféremment les législations UE (comme la directive 2006/24/CE) et, sous réserve de l'appréciation par les juridictions de renvoi, les législations nationales basées sur une dérogation au droit de l'UE (permise par la directive e-privacy). Cela serait rare en ce que, d'habitude, elle se fonderait sur du droit dérivé (je ne suis pas convaincu : même en matière de RGPD, elle mentionne très vite la Charte dans ses arrêts, et, de surcroît, pour invalider la directive 2006/24/CE, il fallait forcément qu'elle se base sur un texte supérieur) ;
  
  La CJUE poserait une interdiction de principe, qu'elle ne nuancerait pas avec les autres impératifs prévus par la Charte des droits fondamentaux de l'UE : la sécurité nationale et la criminalité grave sont des dérogations. Selon moi, c'est normal, car c'est ainsi qu'est rédigée la directive e-privacy : interdiction à des tiers de principe de stocker les communications, sauf dérogations. C'est le vieux principe de droit sur l'interprétation stricte des dérogations et exceptions (le contraire revient à vider le principe de sa substance) ;
  
  La CJUE empiète-t-elle sur les compétences des États en matière de sécurité de l'État et de poursuite des infractions, ce que les traités européens ne prévoient pas (autre planche de salut des États, j'y reviendrai) ? Était-il nécessaire d'harmoniser les pratiques des États en ces matières ? Vaste débat ;
  
  Ces arrêts de la CJUE ont-ils été motivés par une peur de l'État ? Stasi ? Démocraties illibérales (pour rire : la Pologne n'a pas modifié sa législation suite à ces arrêts) ? Je pense que toutes les démocraties ont vacillé et qu'il fallait calmer le jeu.
- 2015-2020 :
  
  En déposant ou en soutenant plusieurs questions prioritaires de constitutionnalité, les Exégètes amateurs (LQDN, French Data Network ‒ FDN ‒, Fédération FDN ‒ FFDN ‒) ont fait retirer, à plusieurs administrations, leur droit de communication des données de connexion ou l'ont fait assortir d'un contrôle préalable indépendant ou l'ont fait préciser : Autorité des marchés financiers (2017-646/647 QPC), douanes (2018-764 QPC), organismes de sécurité sociale (2019-789 QPC), HADOPI (2020-841 QPC).
  
  Dans sa décision 2015-478 QPC, le Conseil constitutionnel a interprété que l'accès par les services de renseignement (articles 851-1 et suivants du CSI, ex-246-1 et suivants, cf. infra) porte uniquement sur les données prévues par la LCEN et le CPCE, c'est-à-dire les données de connexion. De même, il a rappelé que le contenu des communications est hors du périmètre.
- 2020 : dans son arrêt Breyer contre Allemagne (résumé ici), la Cour Européenne des Droits de l'Homme (CEDH) valide la collecte de données d'identité des détenteurs d'une carte SIM prépayée : l'ingérence est nécessaire et proportionnée.
- 2021-2022 : le Conseil d'État (avril 2021), la Cour de cassation (juillet 2022) et le Conseil constitutionnel (décembre 2021, mai et juin 2022) ajustent, a minima et à contrecœur, le droit français au droit de l'UE. Il s'agit de neutraliser l'effet de la jurisprudence de la CJUE.
  
  Conseil d'État :
  
  Sur la conservation :
  
  Jusqu'au bout, la France aura prétendu ne pas être concernée (le parquet estonien n'est pas le parquet français, blablabla) d'une part car sa législation nationale, conforme à la directive 2006/24/CE, n'en est pas une transposition (la décision CE 388134 de février 2016 du Conseil d'État est révélatrice), et d'autre part, car la conservation est mise en branle pour un motif de sécurité nationale et de poursuite des infractions pénales qui sont des prérogatives des États, pas de l'UE. Comme l'Allemagne (rachat de la dette des États par la BCE), ce qui a retenu le Conseil d'État de parer avec l'identité constitutionnelle de la France, malgré une analyse en droit tout de même, c'est la peur des nationalistes qui pourraient eux aussi remettre en cause la primauté du droit européen dans leurs thématiques favorites, façon Hongrie ;
  
  La conservation des données de trafic et de localisation demeure généralisée et indifférenciée pendant 1 an pour la sécurité nationale, donc aucun changement pour les services de renseignement ni pour les opérateurs & co (qui doivent conserver comme avant). Il faut simplement un réexamen périodique de la menace afin de vérifier qu'elle est toujours grave, réelle et actuelle ou prévisible (critères de la CJUE) ;
  
  Conservation rapide pour les mêmes données pour la criminalité et la délinquance grave. La conservation ciblée présente des obstacles techniques, donc elle n'est pas une option ;
  
  Toujours une conservation généralisée et indifférenciée de l'adresse IP ou du numéro de téléphone source d'une connexion / communication et des données d'identification du terminal utilisé (on pense à l'IMEI, à une MAC, etc.), pour la criminalité, la délinquance grave, la sécurité publique, et la sécurité nationale ;
  
  Pas d'utilisation des données de connexion pour les autres infractions (non-graves), à l'exception des données d'identité.
  
  Sur l'accès par les services de renseignement :
  
  L'accès en différé (L851-1 du Code de la sécurité intérieure, CSI) ou en temps réel (L851-2 CSI) aux données de connexion par les services de renseignement, et le recours aux boîtes noires (L851-3 CSI) ou à la géolocalisation en temps réel (L851-4 CSI) par les mêmes services, ne font pas l'objet d'un contrôle préalable suffisant. (Ce contrôle était prévu par les décrets 2015-1639 et 2016-67.) En effet, le Premier ministre peut passer outre l'avis de la Commission nationale de contrôle des techniques de renseignement (CNCTR), qui peut contester cela devant la formation spécialisée du Conseil d'État, mais, pendant ce temps-là, la technique de renseignement peut être mise en œuvre. Ce n'est pas suffisant : en dehors d'une urgence, le Conseil d'État veut un avis conforme de la CNCTR ou un contrôle préalable entier par une juridiction ;
  
  Contrairement aux requérantes, le Conseil d'État juge que le nombre de personnes pouvant accéder aux données de connexion ou mettre en œuvre d'autres techniques de renseignement est limité, par technique de renseignement et par finalité. Cela est prévu dans les articles L811-4 et R811-1 du CSI (services de renseignement du premier cercle), et L811-2, R811-2 CSI (second cercle), puis R851-1 à R851-4 CSI (pour les données de connexion), R852-1 à R852-2, et R853-1 à R853-3 du CSI (pour les autres techniques).
  
  Sur l'absence d'une obligation d'information en cas d'accès : le Conseil ne trouve rien à redire en ce que la loi Informatique et Liberté permet une information et que la CJUE, comme le RGPD, permettent de ne pas informer une personne si ça compromet une enquête ou les missions qui incombent aux services de renseignement ou de police. Pour le CE, seule une minorité de cas donnera lieu à une information, comme une erreur de cible.
  
  Arrêts de la Cassation (juillet 2022) :
  
  Quand ces arrêts ont été rendus, la loi avait déjà changé (en juillet 2021 et en mars 2022, cf. infra) ;
  
  Théoriquement, après les arrêts CJUE, le Parquet (le procureur), qui est l'autorité de poursuite (en sus de ne pas être indépendant de l'exécutif), ne peut plus valider les demandes d'accès aux données de connexion des OPJ dans les enquêtes préliminaires ou de flagrance (qui constituent l'écrasante majorité des investigations). Dans les informations judiciaires (commissions rogatoires), c'est le juge d'instruction qui valide les demandes. S'il est indépendant (magistrat du siège), il n'est pas extérieur à l'enquête, donc la CJUE risque de tiquer. Néanmoins, dans l'attente d'une réforme, la Cour de cassation a jugé qu'il n'y aura pas de nullité de procédure sauf si le prévenu peut montrer, au juge du fond, un préjudice, c'est-à-dire que l'accès à ses données de connexion aurait été interdit s'il y avait eu un contrôle indépendant. Il s'agit de la déclinaison du principe juridique « pas de nullité sans grief ». Donc les magistrats peuvent toujours demander l'accès aux données de connexion. Il s'agit d'un contrôle a posteriori à longue échéance. « La Cour de cassation […] a fixé des conditions si strictes qu’aucune nullité ne pourra être prononcée. » (source, page 123) ;
  
  Une réforme est envisagée. Le juge des libertés et de la détention (JLD) se verrait attribuer cette compétence. Mais il est débordé (même si on l'a déchargé des contentieux civils ces dernières années) et il dispose, au moment de sa prise de décision, de très peu d'informations sur l'enquête en cours, donc son accord est majoritairement automatique afin de ne pas entraver l'action publique. Si l'on mettait en place une Autorité administrative indépendante (AAI) ou d'un Service à compétence nationale (SCN), comme l'ANTENJ (en charge de la PNIJ), il s'agirait uniquement d'un avis (à cause de la séparation des pouvoirs) avec un juge pour confirmer les cas de doute. Cela serait en contradiction avec la jurisprudence de la CJUE qui veut un examen obligatoire (contraignant ?) et systématique. De plus, cela serait coûteux et il manquerait une proximité avec les enquêteurs (je trouve ça sain, au contraire). Une autorité nationale de magistrats poserait des difficultés RH et techniques. Une autorité locale rattachée au parquet ne serait pas conforme CJUE. Reste le JLD, y compris sous forme de groupement auprès des Cours d'appel, mais ça implique une charge de travail et un système d'information bien fichu. Il faudrait également prévoir une procédure d'urgence avec un contrôle a posteriori dans un bref délai. Source, pages 18 et 101 et suivantes.
  
  Les réquisitions (60-1, 60-2, 77-1-1, 77-1-2, 99-3 et 99-4 du Code de procédure pénale) doivent se comprendre comme des injonctions de conservation rapide et portent tant sur les données de connexion détenues pour les intermédiaires techniques pour leurs besoins techniques et commerciaux, que sur les données conservées pour l'obligation légale (ce que ne dit pas la CJUE, surtout si les données ont été collectées pour une finalité supérieure, ni la Convention de Budapest de laquelle est issue la conservation rapide, voir ici) ;
  
  La Cour tolère l'exploitation, par ricochet, par le mécanisme de la conservation rapide, des données de trafic et de localisation recueillies à des fins de sécurité nationale dans des affaires de criminalité grave qui n'en relèvent pas, et le repêchage de données de connexion obtenues illégalement, ce que la CJUE interdit. À la demande d'un prévenu, un juge du fond pourra prononcer la nullité des réquisitions si elles outrepassent la stricte nécessité, mais même remarque que ci-dessus, en pratique, ça n'arrivera pas, et, là encore, il s'agit d'un contrôle a posteriori longtemps après, ce qui n'est pas conforme à la jurisprudence de la CJUE ;
  
  Elle restreint l'exploitation des données de trafic et de localisation à la criminalité grave (ou aux atteintes à la sécurité nationale, j'vais y revenir). Comme il n'en existe pas de définition, c'est au juge du fond de décider ce qui en relève en fonction de la nature de l'infraction, au regard de la nature des agissements, du préjudice, des circonstances des faits, de la peine encourue, etc. c'est-à-dire, in fine, de la nature de l'infraction et de la peine encourue d'un côté, et de l'appréciation des circonstances sur le fondement des principes de nécessité et de proportionnalité, de l'autre. Ces faisceaux d'indice n'ont pas (encore ?) été repris dans le Code de procédure pénale ;
  
  La Cour a déjà jugé que relèvent de la criminalité grave : le trafic de stupéfiants dans une maison d'arrêt avec corruption de fonctionnaire ; le banditisme violent, organisé et transfrontalier ; une association de malfaiteurs (hum, dérapage possible car très large) ; et la détention d'arme et d'explosif en lien avec la possible préparation d'une attaque (idem…).
  
  La Cass juge qu'un quantum de peine de prison ne suffit pas pour caractériser de grave une infraction, il faut tenir compte des circonstances de l'espèce, donc les enquêteurs doivent motiver. Dans un contexte où le législateur augmente sans cesse les peines, je trouve cela protecteur ;
  
  Bien évidemment, les infractions ayant trait à la sécurité nationale (articles 410-1 à 422-7 du Code pénal), comme l'atteinte aux intérêts fondamentaux de la nation (complot, insurrection, appel à s'armer, etc.), les actes de terrorismes, etc., peuvent donner lieu à des réquisitions. Dit autrement : cette finalité de sécurité nationale est poursuivie tant par les services de renseignement que par la justice, ce qui est logique (le renseignement détecte, la justice punit) ;
  
  Conséquence de ces arrêts : insécurité juridique pour les magistrats, formalisme pour rédiger les demandes d'accès (nécessité et proportionnalité) pour les enquêteurs, fragmentation des pratiques au niveau national, et garanties en moins pour les citoyens.
  
  Conseil constitutionnel :
  
  2021-930 QPC (septembre 2021) : refus de transposer l'arrêt Prokuratuur à la géolocalisation en temps réel autorisée par un procureur, au motif que d'autres garanties compensent l'absence d'indépendance dudit procureur, comme la temporalité de la mesure (l'extension passe par un JLD), l'absence de contrainte sur la personne ou d'interception de communications, ou la limite de la mesure aux infractions punies d'un certain quantum de peine, etc.
  
  2021-952 QPC (décembre 2021) : l'accès aux données de connexion dans une enquête préliminaire (77-1-1 et 77-1-2 du Code de procédure pénale, CPP) n'est pas conforme à la Constitution car il faut tenir compte de la nature de l'infraction (criminalité grave), ne pas ouvrir à toutes les infractions ;
  
  2021-976/977 QPC : la collecte généralisée et indifférenciée des données de connexion prévue par l'article L34-1 du CPCE est contraire à la Constitution ;
  
  Pour les deux décisions suivantes, la loi avait déjà changé (en mars 2022, cf. infra) ;
  
  2022-993 QPC (mai 2022) : l'accès en enquête de flagrance (60-1 et 60-2 CPP) est conforme car cette procédure est pour un crime ou un délit puni d'une peine de prison et que l'enquête dure 8 jours (elle peut être prolongée si au moins 5 ans de taule sont encourus et si l'enquête ne peut pas être différée). À rebours de la CJUE, il juge qu'il n'y a point besoin d'un contrôle préalable par une juridiction ou une autorité indépendante ;
  
  2022-1000 QPC (juin 2022) : l'accès en information judiciaire (99-3 et 99-4 CPP) est conforme car le juge d'instruction est indépendant (mais pas extérieur à l'enquête comme le voudrait la CJUE), le cadre est défini (information judiciaire) et les conditions sont précisées dans la commission rogatoire.
- 2021 :
  
  mai : dans son arrêt Big Brother Watch et autres contre Royaume-Uni (communiqué de presse), la CEDH dégage des critères pour valider une législation nationale implémentant une surveillance de masse ou des échanges avec des services de renseignement étrangers. En clair, à mes yeux : les digues ont sauté, il est loin le temps de Klass et autres c. Allemagne et de son paragraphe 41 sur menace de surveillance = entrave à la liberté de communication.
  
  La CEDH a mis en œuvre son contrôle in concreto habituel : point d'impératif absolu (comme dans la démarche première de la CJUE en 2014), mais la recherche d'une insuffisance cumulée de garanties ;
  
  D'abord, en matière de surveillance de masse :
  
  Finalités : sécurité nationale ou autres intérêts nationaux essentiels contre les menaces extérieures graves ;
  
  Les États bénéficient d'une marge d'appréciation pour déterminer le régime qu'il convient de mettre en œuvre, tant qu'il est nécessaire et proportionné, qu'une autorité indépendante veille au respect des garanties, y compris pour définir l'objet et l'étendue de la surveillance, et qu'il existe une supervision indépendante des opérations de surveillance et du respect du pouvoir de l'autorité de contrôle (aka contrôle a posteriori) ;
  
  La CEDH dégage des critères pour vérifier les garanties : motif et circonstance de l'interception ; procédure d'octroi de l'autorisation ; procédure pour sélectionner, examiner et utiliser les éléments interceptés ; encadrement des réutilisations ; limites de la durée de l'interception et de la conservation ; encadrement de la destruction des éléments interceptés ; procédure et modalités de la supervision, etc. ;
  
  Elle estime qu'un État a un besoin légitime d'opérer en secret donc que celui-ci peut ne pas lui communiquer ses critères. Il faut juste que les juridictions internes vérifient ce qui a été esquissé aux points précédents. Rien d'étonnant, la CEDH raisonne souvent comme ça en matière de liberté d'expression (vérification de la procédure, que la juridiction a bien vérifié la proportionnalité, les garanties, etc. plutôt que "re-juger" l'affaire et la peine en elles-mêmes) ;
  
  La Cour juge que la législation britannique antérieure à 2016, pourtant axée sur la sécurité nationale, n'est pas conforme à la ConvEDH par absence d'autorisation indépendante et de définition de l'étendue de la recherche et/ou des termes de celle-ci.
  
  Ensuite, sur l'échange avec des services de renseignement étrangers :
  
  Critères : prévoir les circonstances des collaborations et celles d'utilisation des renseignements obtenus, et contrôle indépendant a posteriori ;
  
  Le régime britannique satisfait à ces exigences.
  
  juillet : ajustement à la marge du régime français par l'article 17 de la loi renseignement 2 (loi 2021-998 relative à la prévention d’actes de terrorisme et au renseignement) qui modifie les articles L34-1 CPCE et 6 LCEN, puis par l'édiction des trois décrets français qui régissent actuellement la conservation des données de connexion : 2021-1361 pour les opérateurs au titre du CPCE, 2021-1362 pour les hébergeurs et les opérateurs au titre de la LCEN, et 2021-1363 pour la conservation des données de connexion et de localisation à des fins de prévention de la menace grave et actuelle contre la sécurité nationale. Avis de la CNIL sur le décret 2021-1361. Avis de la CNIL sur le décret 2021-1362.
  
  Sécurité nationale : comme craint, le décret 2022-1327 a pris la suite du 2021-1363, puis le 2023-933, puis le 2024-901 puis le 2025-980.
  
  Conservation :
  
  Conservation de l'identité (5 ans après la fin de contrat, contre un an avant) et des infos d'abonnement / de compte / de paiement (1 an après la fin de contrat / la clôture du compte) pour toutes les infractions, pour la sécurité publique, et pour la sécurité nationale ;
  
  Conservation 1 an des données permettant d'identifier la source d'une connexion ou les terminaux utilisés, pour la criminalité, la délinquance grave, la sécurité publique, et la sécurité nationale. La conformité à la jurisprudence de la CJUE n'était pas acquise au moment de cette modification législative. (En mars 2022, la loi précisera ce que sont la criminalité et la délinquance grave, cf. infra) ;
  
  Conservation 1 an des données de trafic et de localisation, pour la sécurité nationale ;
  
  Au moins, il y a désormais un panachage de la durée de conservation en fonction de la finalité, même si c'est très artificiel (puisque les opérateurs doivent conserver pour sécu natio et que je présume que ça ne va pas s'arrêter demain) ;
  
  Notons que ces décrets prévoient enfin la conservation du port source, ce qui permet d'identifier les utilisateurs d'un service en ligne qui partagent une même adresse IP publique (surtout en mobilité), plutôt que de geindre dans la presse que les méchants GAFAM ne collaborent pas avec la gentille police (alors que si, mais c'était infructueux puisqu'aucune correspondance ne pouvait être établie).
  
  Accès :
  
  Par la justice. Conservation rapide sur injonction du parquet ou des administrations dotées d'un droit de communication pour la prévention et la répression de la criminalité, de la délinquance grave et des autres manquements graves aux règles dont les administrations doivent assurer le respect. « Peuvent être concernées les données du suspect, de son entourage, des victimes, des témoins, ou encore des zones géographique déterminées dès lors qu’elles apparaissent utiles à la manifestation de la vérité. » (source, page 84). « La méthode de la conservation rapide constitue donc en pratique, comme l’a souligné la direction des affaires criminelles et des grâces aux rapporteurs dans le cadre de leurs travaux, « une modalité d’accès aux données de connexion déjà conservées pour d’autres finalités. » » (même source), ce que la CJUE réprouve. En juillet 2022, la Cour de cassation a jugé dans le même sens que la direction des affaires criminelles (cf. supra) ;
  
  Par les Renseignements. Les articles 18 et 23 de la loi renseignement 2 modifient les articles L821-1 et L854-9 du Code de la sécurité intérieure (CSI) pour soumettre l'ensemble des techniques de renseignement au contrôle de la CNCTR (comme avant), et, en cas d'avis défavorable, au contrôle impératif de la formation spécialisée du Conseil d'État. Toutes les techniques sont concernées (accès diffèré ou en temps réel aux données de connexion, boîtes noires, géolocalisation en temps réel, données de connexion et communications internationales, autres techniques). Notons quand même que l'échange de renseignements entre services y échappe. Voir la délibération de la CNCTR sur cette évolution législative ;
  
  Objections de LQDN : une injonction doit être individualisée ; la collecte généralisée des données de connexion doit rester une exception (CJUE) ; la CJUE a une définition beaucoup plus restrictive de la sécurité nationale que notre droit national qui englobe (cf. L811-3 CSI) les violences collectives (auxquelles le Conseil constitutionnel a rattaché, en 2015, les manif' non déclarées ‒ je pense qu'il s'agit des manifs non autorisées), la prévention de la délinquance et de la criminalité organisées, les atteintes à la forme républicaine des institutions, et auxquelles le Conseil d'État, a ajouté, en 2021, les activités de groupes radicaux.
- 2022 :
  
  mars : deuxième ajustement à la marge du régime français par l'article 12 de la loi 2022-299 visant à combattre le harcèlement scolaire, notamment pour palier les inconstitutionnalités (cf. supra). Ajout de l'article 60-1-2 du Code de procédure pénal, vers lequel renvoient les articles 60-1 et 60-2 (réquisition en enquête de flagrance), 77-1-1 et 77-1-2 (enquête préliminaire), et 99-3 et 99-4 (information judiciaire) du même Code, afin de restreindre l'accès aux données de connexion (hors identité civile) aux infractions les plus graves : crime ou délit >= 3 ans de taule ; identification de l'auteur d'un crime ou délit >= 1 ans de taule commis via un réseau de communication électronique ; à la demande de la victime sur son matériel, si la taule est encourue ; ou recherche d'une personne disparue ou la reconstitution d'un parcours criminel.
  
  septembre : arrêt C-339/20 de la CJUE (communiqué de presse) : les infractions d'abus de marché ne peuvent faire l'objet d'une collecte généralisée et indifférenciée pendant un an des données de trafic (l'Autorité des marchés financiers, AMF, avait obtenu des données de connexion recueillies en enquête pénale). Cette QPJ a été posée par la Cour de cassation dans les pourvois 19-80.908 et 19-82.223, jugés en mai 2023.
  
  La CEDH a jugé (résumé), en mai 2023, que les données de connexion recueillies en enquête pénale peuvent être utilisées par une autorité de la concurrence (mais ça ne dit rien de la collecte généralisée). L'affaire a été renvoyée en grande chambre en septembre 2023, donc affaire à suivre ;
  
  Avant tout cela, la Cour de cassation avait perçu, dès 2019, l'absence d'indépendance de l'AMF. Dans ces deux cas précis (AMF et ADLC), la France a mis en place, dès 2018, un « contrôleur des demandes de données de connexion », cf. section « Droit de communication » infra.
- 2023 :
  
  En juin, le Conseil d'État a rendu ses décisions sur les décrets de 2021 / 2022 :
  
  D'abord, la décision CE 468361 sur le décret 2022-1327 (injonction à conserver les données de trafic et de localisation pour la sécurité nationale), attaqué par Free et des individus :
  
  La menace est grave et actuelle : terrorisme (8 attaques depuis 2020, 10 projets déjoués), l'instabilité au Sahel qui vise la France, l'ingérence et l'espionnage liés à la guerre en Ukraine, les groupes radicaux d'ultra-droite et d'ultra-gauche qui troublent la paix publique, et les cyberattaques visant les OIV ;
  
  Devant le Conseil, le gouv' peut invoquer des menaces de natures différentes de celles qui l'ont poussé à prendre le décret ;
  
  Il n'y a pas d'atteinte disproportionnée à la vie privée (sans argument) ;
  
  Il y a un ré-examen périodique (1 an, possibilité d'y mettre fin prématurément, etc.) et un recours effectif devant le Conseil d'État, donc ce serait conforme aux arrêts de la CJUE.
  
  Ensuite, la décision CE 459724 sur les décrets 2021-1361 et 2021-1362 (la conservation en elle-même), attaqués par Free :
  
  Énième confirmation qu'un intermédiaire conserve uniquement ce qu'il collecte dans le cadre de son activité, ce qui est nécessaire / utile à son activité, aka "tu donnes que ce que t'as". On retrouve cette lecture dans l'avis de la CNIL sur le décret 2021-1362. Dans son avis sur le décret 2021-1361, elle exposait que le projet de décret ne l'affirme pas explicitement ;
  
  Énième confirmation qu'un intermédiaire technique n'a pas à vérifier la véracité des données relatives à l'identité civile (adresse postale, par ex.). Attention, changement en 2024, cf. infra ;
  
  Le panachage des finalités pour chaque jeux de données (point 18) diffère de celui de la Cour de cassation (cf. « 2021-2022 » ci-dessus). Sur les données relatives à la source d'une connexion ou aux terminaux : en sus de la criminalité et de la sauvegarde de la sécurité nationale prévues par la Cour de cass, le CE, accepte la lutte contre la délinquance grave et la menace grave contre la sécurité publique, prévues par la loi mais dont la conformité à la jurisprudence de la CJUE n'était pas acquise à date. Pour le reste, identité civile, contrat, facturation, données de trafic et de localisation, la Cour de cass' et le CE sont raccord sur sauvegarde de la sécurité nationale pour les données de trafic et de localisation, et sur la recherche des infractions pénales, la délinquance et criminalité graves, menaces graves contre la sécurité publique, et sauvegarde de la sécurité nationale ;
  
  L'obligation de conserver l'identité civile 5 ans, qui conduit à détenir un historique des adresses postales, emails, numéros de téléphone, etc. n'est pas disproportionnée ;
  
  L'obligation de conserver les « autres informations fournies par l'utilisateur lors de la souscription du contrat ou la création d'un compte » est verrouillée à ce qui est précisé dans le R10-13 CPCE ;
  
  Les données de paiement / facturation, c'est-à-dire la date+heure + le lieu des transactions physiques (pour payer le matos et/ou l'abo, etc.), ne sont pas des données de localisation au sens de la directive e-privacy donc elles peuvent être utilisées pour toutes les finalités, pas juste pour sauvegarder la sécu nationale, la sécu publique, et pour la criminalité et la délinquance graves ;
  
  Le décret attaqué ne fixe pas les durées de conservation, donc on ne peut pas débattre, dans cette procédure, de la durée de conservation des infos de paiement qui serait excessive et donc contraire au droit de l'UE ;
  
  Le décret ne traitant pas de l'accès, par les autorités, aux jeux de données qu'il impose de conserver, on ne peut en parler non plus ;
  
  L'ingérence dans la vie privée est nécessaire et proportionnée ;
  
  Des précisions ont été apportées sur les données à conserver, voir la section « Que faut-il collecter et conserver ? Combien de temps ? » ci-dessous.
  
  En 2023, le Sénat a procédé à une mission d'information « sur les modalités d'investigation recourant aux données de connexion dans le cadre des enquêtes pénales ». Des auditions ont eu lieu en juillet et septembre 2023 (source : agenda de la rapporteure). Un rapport a été produit en novembre. Mes notes ici. En gros :
  
  Malgré les ajustements décrits ci-avant, le droit français n'est pas encore entièrement conforme à la jurisprudence de la CJUE et il reste des divergences d'interprétation entre le Conseil d'État, la Cour de cassation, et le Conseil constitutionnel ;
  
  L'écrasante majorité des États-Membres de l'UE peinent à mettre leur droit en conformité : la conservation rapide ne serait pas efficace par manque d'historique, la conservation ciblée présente des difficultés juridiques et techniques. Conséquence : les pratiques divergent ;
  
  Il existe des dissensions au sein de l'appareil européen (Commission, Conseil, Parlement) ;
  
  Au niveau français, le mal est plus profond : nécessaire unification et clarification des régimes juridiques des preuves numériques, des procédures d'accès, etc. ; disposer de systèmes d'information adéquats ; etc.
- 2024 :
  
  En février, la CEDH rend son arrêt Škoberne c. Slovénie (19920/20). La conservation systématique, généralisée, et indifférenciée des données de trafic et de localisation durant 14 mois n'est pas conforme à l'article 8 de la ConvEDH. Pour affirmer cela, la CEDH se base sur CJUE et Cour constitutionnel Slovène qui avait fait sauter la rétention des données de connexion dès 2014. Danger : la prévention des infractions et la protection des droits et libertés d'autrui sont des buts légitimes = aucune graduation, toutes les infractions ;
  
  En février, la Cour de cassation rend son arrêt dans le pourvoi 23-81.061. Commentaire ici. La localisation en temps réel d'un téléphone (article 230-32 et 230-33 du Code de procédure pénal), en ce que, contrairement au suivi d'un véhicule par une balise GPS, elle fait intervenir les données de connexion, ce qui implique l'application de la directive e-Privacy et des arrêts CJUE, ne peut être ordonnée par un procureur car il est l'autorité de poursuite. La circonstance de l'intervention d'un juge d'instruction après l'enquête préliminaire, qui a pour effet de faire perdre la direction de l'enquête et l'opportunité de poursuite au procureur, est sans effet. La nullité de la géolocalisation nécessite de montrer qu'elle n'a pas été limitée à la criminalité grave ou qu'elle a excédé le strict nécessaire. À ce stade, il est seulement reproché à la chambre de l'instruction de la Cour d'appel de ne pas avoir recherché cela. Même pour des interceptions de communications sans que le JLD ni le juge d'instruction n'en ai été informé à brève échéance, le prévenu doit montrer en quoi ça porte atteinte à ses intérêts.
  
  En avril, la CJUE a rendu son arrêt LQDN contre HADOPI (C-470/21) :
  
  Le Conseil d'État a posé cette question préjudicielle dans le cadre du contentieux CE 433539. Dans ce même dossier, il avait posé une question prioritaire de constitutionnalité (2020-841 QPC). Comme relaté supra, le Conseil constitutionnel avait déclaré les dispositions anti-constitutionnelles en ce qu'elles octroyaient l'accès à toutes les données de connexion et même à tous documents (et données) conservés par les opérateurs ;
  
  Questions en suspens : obtenir l'identité civile à partir de l'adresse IP source d'une connexion est-il possible si l'infraction présumée ne relève pas de la criminalité grave ? Et si c'est le seul moyen d'identifier l'auteur présumé d'une infraction ? Faut-il un contrôle préalable par une autorité indépendante ? Quelles infractions relèvent de la criminalité grave ? ;
  
  La CJUE répond que la correspondance entre une IP source et une identité civile peut être sollicitée pour toutes les infractions pénales, pas juste la criminalité grave, sauf si, conformément à sa jurisprudence antérieure (cf. supra), cela est susceptible de permettre de tirer des conclusions précises sur la vie privée, de tracer l'activité, de profiler l'utilisateur (aka ingérence grave dans la vie privée). Sans trop de surprise étant donné que l'inverse induirait une impunité totale (je peine à croire que les opérateurs gardent l'historique des IP assignées pour leurs besoins propres) ;
  
  Une adresse IP est une donnée de trafic au sens de la directive e-privacy (point 60), mais, dans le cadre d'un accès pour identifier une personne, il y a lieu de la considérer comme une donnée d'identité / d'abonnement, ce que prévoit la législation française.
  
  La question de savoir si l'obtention de l'identité civile à partir d'une adresse IP à l'origine d'une communication est le seul moyen d'identifier l'auteur présumé d'une infraction ou, a minima, le moins intrusif, est un critère de proportionnalité pour décider s'il y a ou non une ingérence grave (points 116 et 119). J'aurais préféré que la CJUE pose une limite claire : l'accès à l'identité civile à partir d'une adresse IP n'est possible, pour toutes les infractions non-graves, que si c'est nécessaire et/ou la méthode la moins intrusive.
  
  Un contrôle préalable et indépendant est obligatoire uniquement en cas d'ingérence grave. Par défaut, ce n'est pas le cas de l'obtention de l'identité civile à partir d'une IP.
  
  Sauf que la HADOPI associe le titre d'une œuvre culturelle présumément piratée (c'est-à-dire des données de trafic) à une adresse IP et, par suite, à une identité civile. C'est cette combinaison de données de connexion qui peut constituer une ingérence grave (c'est-à-dire révéler une orientation sexuelle, des convictions politiques, philosophiques, religieuse, etc.) mais uniquement en cas de réitération (une seule œuvre ne permet pas de tirer de conclusions très précises sur une personne). La CJUE juge que l'ingérence est susceptible d'intervenir à la 2^e réitération, c'est-à-dire à la 3^e itération (pourquoi pas à la 2^e ? D'autant qu'une même personne peut se faire flasher plusieurs fois par étape de riposte graduée). Donc il faut un contrôle préalable indépendant et non-automatisé à partir de cette étape, la troisième étape de la riposte graduée. Je ne comprends pas comment cela peut être mis en place : surtout avec des IP dynamiques (ce dont l'Avocat général a conscience), il faut d'abord obtenir l'identité pour savoir si la 3^e itération est intervenue, ce qui n'est possible qu'après la réquisition de l'identité civile dont il faut décider si elle doit être contrôlée ou non. J'imagine que le Conseil d'État résoudra cette contradiction apparente par un contrôle indépendant a posteriori à brève échéance (ce qui est conforme à la jurisprudence de la CJUE) ;
  
  De même, il faut une séparation interne à la HADOPI afin que les agents ne puissent pas mettre automatiquement en relation une identité avec les titres des œuvres présumément piratées (point 142). Gné ? Le système d'information (SI) de la HADOPI, essentiellement automatisé, doit faire l'objet d'un contrôle indépendant sur son intégrité, sur son respect effectif des garanties, sur l'absence d'abus, etc. (point 146) Donc, il y a la HADOPI, l'entité de contrôle préalable des accès, et l'entité qui audite le SI de la HADOPI. Vache…
  
  Le délit de contrefaçon peut être considéré, par la France, comme relevant de la criminalité grave au regard de l'atteinte à un intérêt fondamental de la société (lol). Inversement, la contravention de négligence caractérisée n'en fait pas partie (en même temps, c'est dans son type : contravention). Sans trop de surprise au regard de la répartition des compétences entre l'UE et ses États-Membres, la définition de la criminalité grave est donc renvoyée aux États. C'est un désaveu de l'Avocat général qui, dans ses premières conclusions (point 74), proposait de considérer qu'une telle définition devrait être autonome. Je ne conçois pas l'intérêt qu'aurait la France à considérer que le délit de contrefaçon relève de la criminalité grave puisque la CJUE a validé l'obtention d'une identité civile à partir d'une IP pour toutes les infractions.
  
  Aux points 44 à 47 de son arrêt C-178/22 rendu le même jour, la Cour a jugé qu'il revient aux États de définir ce qu'est la criminalité grave tant que cela ne dénature pas ni ne vide de sa substance la directive e-privacy ou sa jurisprudence. De plus, une peine de prison de trois ans ne suffit pas à caractériser de grave une infraction, il faut mettre en balance les droits, il faut que les données soient pertinentes pour constater les faits, etc. (point 50 et suivants). Mais une peine de prison de 3 ans n'est pas un seuil excessivement bas.
  
  Un accès pour la lutte contre les infractions pénales permet d'accéder, en sus des données conservées à cette fin en application de la rétention des données de connexion, aux données de trafic et de localisation qui ont été conservées pour les besoins propres des opérateurs (facturation, gestion du réseau, etc.), cf. point 98. Avant cet arrêt, la criminalité grave ou la sécurité nationale donnaient accès aux données de trafic et de localisation détenues pour les besoins propres ; désormais c'est ouvert à toute infraction. Donc une législation nationale ne peut pas prévoir la conservation (additionnelle) des données de trafic et de localisation pour toutes les infractions, seulement pour la criminalité grave, mais OK pour l'accès à celles conservées de base par les intermédiaires techniques. Ça craint ;
  
  Sur la conservation, ce qui avait fait monter la CJUE dans les tours dans ses précédents arrêts, c'était qu'elle était confrontée à des législations, notamment la nôtre, française, qui prévoyait aussi la conservation de la date+heure + durée + type + destinataire de chaque communication (point 81). Si la législation prévoit uniquement la conservation des IP sources, c'est bon. Sauf que la législation française prévoit toujours, en sus de la conservation des adresses IP source, la conservation des données de trafic précitées et de localisation pour la sécurité nationale. Réponse de la CJUE (points 83 à 89) : la loi doit préciser de manière claire et précise les modalités de conservation. Ces modalités doivent inclure : la conservation de chaque jeu de données doit être séparée et étanche ; la mise en relation / combinaison (ex. : identité civile <> IP) doit être réalisée par un procédé technique qui ne remet pas en cause l'étanchéité (gné ?) ; la fiabilité de l'étanchéité doit être contrôlée par une autre autorité publique que celle qui accède aux données (vache, encore une entité de plus…). Bref, c'est de la cosmétique… ;
  
  Divers :
  
  Les données de connexion doivent être conservées pour une durée strictement limitée au nécessaire, y compris l'IP source (point 93). Rien de neuf, c'était déjà dans LQDN 2020, point 156, ou Tele2 point 108 ;
  
  HADOPI = pré-pénal, donc e-privacy et la directive police-justice lui sont applicables. En revanche, seul le RGPD est applicable à la collecte, par les ayant-droits, des adresses IP et des œuvres présumées piratées.
  
  La CJUE rappelle, au point 97, que l'interdiction de porosité entre des finalités de rang différent ne s'applique qu'aux données de trafic et de localisation, pas aux données d'identité ni aux adresses IP source. Je déduis que même si, actuellement, l'article R10-13 CPCE prévoit la conservation de l'adresse IP pour la criminalité grave (et la sécu publique et nationale), la HADOPI peut y accéder sans requalifier le délit de contrefaçon de criminalité grave.
  
  Un volume massif d'infractions présumées (4 millions en 2021) n'est pas une excuse pour procéder à un contrôle automatisé de l'accès aux données de connexion.
  
  En bref : sur plusieurs points, il s'agit d'un arrêt régressif qui complexifie excessivement les choses par des détours… La note 38 des deuxièmes conclusions de l'Avocat général annonçait la couleur : renouer le dialogue avec les juges nationaux, adaptation, etc.
  
  Article de L'informé sur la première défense du ministère de la culture devant le CE après l'arrêt CJUE.
  
  Toujours en avril, toujours la CJUE, arrêt C-178/22 (CP) évoqué supra dans HADOPI : accès aux fadettes pour les seules infractions graves (à la discrétion des États-Membres) + contrôle préalable (par juge ou autorité administrative indépendante qui doit être en capacité de s'y opposer, y compris si l'ingérence dans les droits est grave alors que l'infraction ne relève pas de la criminalité grave au sens de l'État-Membre). Article Next.
  
  En juin, la mission de réflexion sur les conditions d'accès aux données de trafic et de localisation par les acteurs de l'enquête pénale, confiée par le ministre de la Justice au conseiller d'État Alexandre Lallet, rapporteur public de la décision CE 393099 du Conseil d'État d'avril 2021, aurait rendu son rapport, mais il est introuvable en ligne. En novembre 2024, ce rapport était en discussion / arbitrage (source, page 13).
  
  En novembre, un groupe de réflexion sur le même sujet et piloté par la Commission européenne a rendu ses recommandations et son rapport. Mes notes ici.
- 2025 :
  
  En février, abandon du règlement européen e-privacy qui devait mettre à jour la directive e-privacy de 2002, entre autres pour la rendre entièrement compatible avec le RGPD. Faute d'accord entre les co-législateurs, rien n'avançait depuis 2021. Pour rappel, e-privacy permet, par dérogation, la conservation des données de connexion (cf. supra). Certains États, dont la France, voulaient donc exclure explicitement du principe de confidentialité des communications qu'elle prévoit les activités de prévention et de détection des infractions pénales, d'exécution des sanctions pénales, et de détection et de protection des menaces graves pour la sécurité publique. L'objectif était de réaffirmer la compétence exclusive des États.
  
  En juin, la loi 2025-532 sur le narcotrafic modifie l'article L34-1 du CPCE : les opérateurs et FAI doivent vérifier l'identité civile de leurs clients.
  
  Entre mai et septembre : appel à contribution puis consultation publique de la Commission européenne préparatoires à son analyse d'impact sur la révision des règles européennes en matière de rétention des données de connexion dans le cadre de sa feuille de route plus large pour un accès efficace aux données à des fins répressives. Lire l'excellente contribution d'EDRi. Mes notes sur tout ça.
Sources pour rédiger cette section :
- FDN et autres contre gouvernement à PSES 2015 ;
- Big Brother habite place Beauvau ? chez Thinkerview en 2018 ;
- Legal update: on en est où de l'accès aux logs ? au FRnOG 36 de septembre 2022 ;
- Les innombrables tweets d'Alexandre Archambault auxquels je n'ai plus accès puisque Twitter est désormais fermé aux non-inscrits ;
- Rapport d'information du Sénat « Surveiller pour punir ? Pour une réforme de l'accès aux données de connexion dans l'enquête pénale » de novembre 2023.
Actuellement

Gros résumé à la truelle de la section précédente.

En droit français (il n'y a plus de législation européenne sur le sujet, uniquement e-privacy qui la permet par dérogation), la rétention des données de connexion est codifiée dans :
- Les articles L34-1 et R10-13 du Code des postes et des communications électroniques (CPCE). Dernières modifications par le décret 2021-1361 et la loi 2025-532 sur le narcotrafic ;
- Article 6(V)A de la loi pour la confiance dans l'économie numérique (LCEN) et décret 2021-1362. Renvoi vers le L34-1 CPCE ;
- Un décret annuel visant à maintenir la conservation généralisée et indifférenciée pour motif de sécurité nationale. Le dernier est le 2025-980.
Lire la section « Qui est concerné ? » infra sur la répartition des types d'acteurs entre CPCE et LCEN.

Plus précisément, les intermédiaires techniques doivent conserver :
- Toutes les données d'identité (état civil), d'abonnement (numéro de téléphone, adresse IP, etc.), de contrat, de compte, de facturation / paiement, etc. doivent être conservées 5 ans pour l'identité, et 1 an après la fin du contrat pour le reste. Finalités : infractions, sécurité publique, sécurité nationale. En sus de ce régime, les pièces comptables (factures) sont aussi soumises à l'obligation fiscale 6 ans et à l'obligation comptable 10 ans ;
- Toutes les données d'identification (adresse IP source d'une connexion, numéro de téléphone appelant, identifiant de l'utilisateur ou de son terminal, etc.) doivent être conservées 1 an à compter de la communication. Finalité : criminalité, délinquance grave, sécurité publique et sécurité nationale (bien entendu, comme l'intermédiaire technique ignore l'usage de ses utilisateurs, il conserve pour tout le monde) ;
- Toutes les données de trafic (appels, SMS, emails, connexions, etc.) et de localisation (pour un smartphone) doivent être conservées 1 an à compter de la communication en cas de menace grave pour la sécurité nationale, sur décret du Premier ministre. Un tel décret est actuellement en vigueur ;
- Dans tous les cas, les entités conservent uniquement les données qu'elles détiennent dans le cadre normal de leur activité (cf. 2023 dans la section « Historique »). Exemples : absence de données de paiement et de facturation sur un service gratuit ; absence de données de localisation hors abonnement de téléphonie mobile ; l'opérateur d'un point d'accès Wi-Fi public gratuit n'a pas l'identité ni la facturation s'il ne le désire pas (attention quand même aux autres lois applicables), mais il a l'identifiant du terminal utilisé (adresse MAC) ; un éditeur qui permet le dépôt de commentaires n'a pas forcément le nom / prénom / date de naissance / adresse postale ;
- Le présent article traite de l'obligation légale de conserver des données de connexion, mais, bien évidemment, en dehors de ce cadre, les intermédiaires techniques conservent eux-mêmes de telles données pour leurs besoins techniques (fonctionnement du service, prévention des pannes, résolution des incidents, sécurité du réseau, etc.) ou commerciaux (facturation, etc.), cf. R10-14 du CPCE. Certaines entités consignent les connexions à un espace client au titre de l'obligation de traçabilité des accès aux données à caractère personnel tirée du RGPD (la CNIL préconise 6 mois à 1 an, hein ;) ). L'obligation légale de conserver des données de connexion permet seulement de s'assurer que tous les acteurs conservent un ensemble minimal de données pour une durée minimale, etc. ;
- Pour toutes les données énumérées à l'ensemble des points qui précèdent, un intermédiaire technique peut recevoir une injonction judiciaire de conservation rapide (quick freeze), c'est-à-dire l'ordre de conserver l'ensemble des données de connexion qu'il détient sur des personnes. Il faut donc un système d'information dans lequel on peut empêcher la suppression automatique des données de connexion conservées.
L'accès aux données de connexion est régit par trois régimes :
- Pour les enquêtes pénales :
  
  Il s'agit du régime des réquisitions judiciaires, donc des articles 60-1 et 60-2 du Code de procédure pénale (CPP) pour les enquêtes de flagrance, 77-1-1 et 77-1-2 CPP pour les enquêtes préliminaires, et 99-3 et 99-4 CPP pour les informations judiciaires ;
  
  L'article 60-1-2 CPP restreint ces réquisitions pour toutes les données de connexion sauf l'identité civile : crime ou délit >= 3 ans de taule ; identification de l'auteur d'un crime ou délit >= 1 ans de taule commis via un réseau de communication électronique ; à la demande de la victime sur son matériel, si la taule est encourue ; ou recherche d'une personne disparue ou la reconstitution d'un parcours criminel ;
  
  Les réquisitions, qui sont ordonnées par le parquet (= procureur) doivent être comprises comme des injonctions de conservation rapide. Elles permettent d'accéder aux données de connexion conservées pour d'autres finalités que l'infraction poursuivie (ex. : accès aux données de trafic et de localisation détenues uniquement pour la sécurité nationale dans le cadre d'une enquête sur un délit), y compris à l'historique. La peine prévue (années de prison) n'est pas suffisante pour qualifier la gravité d'un crime ou d'un délit et autoriser l'accès aux données de connexion (c'est au juge du fond d'apprécier la nullité des pièces en bout de course) ;
  
  Pour les demandes venues de l'étranger / international, les intermédiaires techniques doivent renvoyer vers la BEFTI ou la sous-direction de la lutte contre la cybercriminalité (ex-OCLCTIC), car, a priori, y'a pas de raison que si une entité étrangère n'est pas tenue de répondre à une réquisition directe des autorités françaises, l'inverse soit vrai.
  
  Dans un procès au civil, les données de connexion, y compris d'identité, ne sont pas communicables. Si c'est demandé, il faut contester durant le procès, car la juridiction est tenue par les propos et prétentions des parties. Exemple : Wikipédia a été contrainte, à tort, de communiquer les données d'un contributeur, cf. 1, 2, 3, 4 ;
- Pour les services de renseignement :
  
  Articles L851-1 (accès différé aux données de connexion), L851-2 (accès en temps réel aux données de connexion), L851-3 (boîtes noires), L851-4 (géolocalisation en temps réel d'un terminal), et 851-6 (IMSI catcher pour localisation et identification uniquement) du Code de la sécurité intérieure (CSI) ;
  
  De nombreux services de renseignement, dits du premier ou du second cercle, peuvent accéder aux données de connexion : articles L811-4 et R811-1 du CSI pour le premier cercle, et L811-2 et R811-2 pour le second cercle, puis R851-1 à R851-4 (pour l'accès aux données de connexion), et R852-1 à R852-2, et R853-1 à R853-3 du CSI (pour les autres techniques) ;
  
  Les finalités dépendent des techniques de renseignement, mais, en gros, il s'agit de : sécurité nationale, terrorisme, et défense et promotion des intérêts fondamentaux de la Nation. Comme dit plus haut, la sécurité nationale englobe beaucoup de choses : violences collectives, donc manifs non autorisées, activités de groupes radicaux, délinquance et criminalité organisée, complot, insurrection, appel à s'armer, etc. ;
  
  Sur autorisation du Premier ministre après avis de la Commission nationale de contrôle des techniques de renseignements (CNCTR). Si avis défavorable, la formation spécialisée du Conseil d'État est obligatoirement saisie et la technique de renseignement ne peut pas être mise en œuvre avant sa décision. Cf. L821-1 et L854-9 CSI ;
- Pour les administrations : voir la section suivante, mais, en gros, L96 G du Livre des procédures fiscales et des lois sectorielles (le Code du travail, par ex., qui renvoient, ou non, au L96 G), sous réserve de l'indépendance de l'administration, pour les infractions les plus graves (cf. supra : criminalité, délinquance grave) et les manquements graves aux règles qu'elles sont chargées de faire appliquer (cf. L34-1 CPCE).
Droit de communication

Plein d'administrations disposent d'un droit de communication initialement accordé au fisc (L81 à L102 AH du Livre des procédures fiscales) : douanes (article 65 quinquies du Code des douanes), AMF (L621-10-2 du Code monétaire et financier), DGCCRF et ADLC (L450-3-3 du Code du commerce), sécu dont CAF (L114-19 à L114-21 du Code de la sécurité sociale), Pôle emploi (L5312-13-2 du Code du travail), URSSAF, inspection du travail (8113-5-2 du Code du travail), ANSSI (L2321-3 du Code de la défense), HADOPI (L331-14 du Code de la propriété intellectuelle), etc.

Ce droit porte sur plusieurs types de documents et données (relevé de compte bancaire, par ex.), dont les données de connexion. Rigolo : le Conseil constitutionnel aime rappeler que le droit de communication des données de connexion n'est pas assorti d'une exécution forcée, d'une contrainte, alors que, pour la HADOPI, par exemple, une contravention est prévue en cas de refus de répondre.

Toutes les administrations ne peuvent pas avoir accès aux données de connexion. Tel est le cas de la Sécu, de Pôle emploi, ou de la Haute autorité pour la transparence de la vie publie (HATVP) :
- Pour Pôle emploi, le R5312-49 du Code du taff référence le L5312-13-2 du même Code qui exclut le L96 G du Livre des procédures fiscales, c'est-à-dire les opérateurs de communications électroniques ;
- Concernant la Sécu dont la CAF, le Conseil constitutionnel a dit non en ce qui concerne les données de connexion, et l'article L114-20 du Code de la sécurité sociale exclut explicitement le L96 G du Livre des procédures fiscales ;
- Dans sa décision 2017-753 DC, le Conseil constitu a censuré l'accès aux données de connexion que la loi organique pour la confiance dans la vie politique voulait octroyer à la HATVP.
De même, toutes les administrations n'ont pas accès aux données de trafic et de localisation. Exemple : l'inspection du travail est limitée aux données permettant d'identifier l'auteur présumé de travail dissimulé (donc numéro de tél / adresse IP et identité civile), cf. 8113-5-2 du Code du travail.

Depuis 2018-2019, suite à des questions prioritaires de constitutionnalité et pour répondre au critère d'indépendance posé par la CJUE (l'autorité de poursuite ne peut pas être celle qui valide / contrôle l'accès aux données de connexion), l'AMF (2017-646/647 QPC), l'ADLC (2015-715 DC), et le fisc (2015-715 DC puis loi de finances pour 2021) demandent une autorisation préalable d'accéder aux données de connexion au Contrôleur des demandes de données de connexion (CDCD), c'est-à-dire un membre du Conseil d'État suppléé par un magistrat de la Cour de cassation (et inversement, par alternance). Voir ici et là.

Les autres administrations sont-elles soumises à un contrôle préalable ? La douane est soumise au contrôle du procureur, ce qui n'est pas conforme à la jurisprudence de la CJUE (mais c'est mieux que l'absence de contrôle d'avant la décision 2018-764 QPC). Le cas HADOPI est devant le Conseil d'État.

Pour les données de trafic et de localisation, est-ce que les crimes, les délits graves et les « manquements graves » dont ces autorités ont la charge relèvent de la gravité délimitée par la CJUE ? L'AMF s'est fait retoquer là-dessus (cf. 2022 dans la section « Historique »). Quid de la lutte contre les entraves à la concurrence (ADLC) ?

De là, se faire communiquer, via une injonction de conservation rapide, les données de trafic ou de localisation que les opérateurs collectent dans le cadre de la sécurité nationale (cf. 2021 dans la section « Historique ») pour traiter des affaires qui n'en relèvent pas, tient-il la route ? A priori, la CJUE a dit non (sauf ce que les intermédiaires techniques détiennent pour leurs besoins, mais la Cour de cassation a dit oui (cf. 2022 dans la section « Historique »).

Un droit français pas conforme à la jurisprudence de la CJUE

Conservation :
- La conservation généralisée et indifférenciée des données de trafic et de localisation est prolongée par décrets depuis 2021. La menace est-elle réellement réelle et actuelle ou prévisible ? Vu la décision du Conseil d'État de juin 2023 (cf. « Historique » supra), peu d'espoir de ce côté-là, surtout que la sécurité nationale est l'une des compétences des États membres de l'UE ;
- En droit français, la définition de la sécurité nationale est plus large que celle de la CJUE en ce qu'elle englobe, entre autres, les violences collectives, donc les manifs non autorisées, les activités de groupes radicaux, la délinquance et la criminalité organisées, le complot, l'insurrection, l'appel à s'armer, etc. ;
- Les durées de conservation (5 ans pour l'identité civile, 1 an pour le reste) sont-elles excessives ? D'un côté, la CJUE a jugé qu'elles sont sans incidence sur la conformité ou non d'un régime (tant qu'elles permettent de tirer des conclusions précises sur la vie privée, c'est mort, même pour un jour). De l'autre, le RGPD et la CJUE disent que les données doivent être conservées pour une durée strictement limitée au nécessaire, y compris l'IP source (cf. LQDN 2020, point 156 ou LQDN contre HADOPI, point 93, ou Tele2, point 108, par ex.). En 2023, le Conseil d'État ne s'est pas prononcé au motif que le décret attaqué ne prévoit pas lui-même les durées de conservation (c'est la loi qui le fait) ;
Accès :
- Le parquet (aka procureur aka magistrat) autorise les accès aux données de connexion dans les enquêtes de flagrance ou préliminaires (même aux données d'identité et IP sources, même si la CJUE ne l'impose pas). Pour les informations judiciaires, c'est le juge d'instruction. Or, le procureur est celui qui poursuit (il n'est donc pas neutre), et le juge d'instruction n'est pas entièrement extérieur à l'enquête. De plus, dans l'attente d'une refonte, il appartient à un prévenu de saisir le juge du fond de nullités des réquisitions, ce qui constitue un contrôle a posteriori à trop longue échéance, d'autant que les conditions posées par la Cour de cassation sont trop strictes pour qu'une telle démarche aboutisse (cf. « Historique » supra) ;
- Des administrations agissant comme autorité de poursuites peuvent accéder aux données de trafic et de localisation sans contrôle indépendant préalable. La douane sollicite le procureur. Le cas HADOPI est devant le Conseil d'État (même si la HADOPI ne demande pas les données de trafic aux opérateurs, elle a le titre des œuvres présumées piratées). Quid des autres administrations ? ;
- Les échanges entre services de renseignement, qui peuvent porter sur des données de connexion, ne font pas l'objet d'un contrôle préalable ;
- Une injonction de conservation rapide (ce que sont les réquisitions par le judiciaire ou par une administration) donne accès aux données déjà conservées par obligation légale, c'est-à-dire à l'historique. Cette conception, validée par la Cour de cassation en juillet 2022 (cf. supra), même si elle est logique, n'a pas été examinée par la CJUE et n'est pas prévue (à charge comme à décharge) par la Convention de Budapest qui instaure la conservation rapide ;
- Ces injonctions permettent également d'accéder à des données de trafic et de localisation qui ont été conservées pour une autre finalité que celle faisant l'objet de l'enquête (ex. : les données de trafic et de localisation, conservées pour la sécurité nationale, peuvent être utilisées dans une enquête sur un crime sans rapport avec la sécu nationale). Source 1, page 84 ; Source 2, page 10. La CJUE réprouve cela si la finalité d'accès est inférieure à la finalité de conservation ;
- Les mêmes injonctions permettant d'accéder aux données de connexion de l'entourage d'un suspect, de personnes présentes dans une zone géographique (cf. point « Recherche géographique inversée »), etc. De même, la conformité des logiciels de rapprochement judiciaire apparaît douteuse : ils manipulent plus de données que nécessaire, ils font du rapprochement automatisé, ils reposent en partie sur la découverte fortuite, etc. ;
- Qu'est-ce que la criminalité grave dans la conception de la CJUE ? Qu'est-ce que les manquements graves aux règles que les administrations sont chargées de faire appliquer ? En juillet 2022, la Cour de cassation a jugé qu'un quantum de peine ne suffit pas à caractériser de grave une infraction, et la CJUE a été dans le même sens dans son arrêt LQDN contre HADOPI de 2024. Or, c'est ce que prévoit l'article 60-1-2 du Code de procédure pénale. les critères dégagés par la Cassation n'y ont pas été intégrés. De même, cet article ne s'applique pas au droit de communication des administrations qui reste donc câblé sur criminalité, délinquance grave et manquements graves, sauf restriction dans chaque loi sectorielle. Si la CJUE semble avoir laissé aux États le soin de définir ce qu'est la criminalité grave (cf. point « 2024 » de la section « Historique » ci-dessus), y aura-t-il des divergences d'appréciation au sein de l'UE ? Comment seront-elles remontées à la CJUE ? ;
- En avril 2021, le Conseil d'État a restreint au minimum l'information des personnes de l'accès à leurs données de connexion par les Renseignements : uniquement en cas d'erreur (accès à tort). Conformité douteuse, même si la CJUE semble plutôt aller dans ce sens.
À la recherche d'un paradis inexistant

A priori, c'est dans un cadre juridique suisse similaire à celui de la France que ProtonMail a mouchardé l'adresse IP, le modèle, et l'identifiant du terminal de militants français (source). Il s'agit bien de données de compte / d'abonnement et d'identification (source d'une connexion).

On notera que la France a utilisé une procédure de coopération dédiée à la criminalité grave pour une affaire qui n'en relève pas et que les autorités suisses ont laissé faire (car ce n'est pas leur boulot de vérifier si des faits relèvent ou non des conventions d'entraide).

Pour obtenir une collaboration, il faut une équivalence de l'infraction dans le droit suisse (je ne suis pas convaincu que ça freine les demandes puisque les autorités ne reprochent jamais d'être un mouvement social mais des infractions précises comme trouble à l'ordre public, destruction ou dégradation de bien, etc. qui existent dans toutes les législations…).

Comme le note Reflets, on peut déplorer le flou dans la communication de ProtonMail, qui a changé plusieurs pages de son site web depuis cette histoire. Lire aussi l'analyse d'Alex Archambault.

Mais, quoi qu'il en soit, et comme l'écrit très bien Reflets, il existera toujours une conservation et un accès aux données de connexion. Toutes les législations prévoient ça. La vertu des arrêts CJUE et des contentieux LQDN, FFDN, FDN, c'est d'avoir nettoyé les imprécisions et les excès.

Il ne sert à rien de rechercher du « no log », VPN, TOR, etc. Ça ne sera que temporaire. Ça se fera défoncer par les autorités. Tout au plus est-il possible de jouer sur la temporalité, l'absence de coopération judiciaire, etc., mais ça ne se fait pas en souscrivant simplement à un service, cela demande plus d'efforts.

Futur
- Le traitement des adresses IP par la HADOPI est toujours devant le Conseil d'État après la question préjudicielle C-470/21. Dossier 433539 ;
- Analyse d'impact de la Commission européenne en vue d'actualiser les règles de l'UE en matière de conservation des données de connexion. Prévue pour 2025 si la feuille de route est validée en juillet 2025 ;
- Refonte, en France, de l'accès aux données de connexion dans les enquêtes pénales. Suite à la mission Lallet ;
- Édiction, en France, du décret précisant l'obligation tirée du L34-1 CPCE de vérifier l'identité civile.
Concrètement

Une fois que l'on a écrit tout ça, comment savoir dans quelle catégorie entre un service usuel genre un site web personnel, et les obligations qui s'imposent à nous ?

Pour rédiger cette section, je me suis appuyé sur le travail du feu groupe juridique de la FFDN (copie ici) et sur le travail de LQDN (copie ici). On notera qu'il s'agit de brouillons. Ils sont faux en cela qu'ils ne tiennent pas compte des décrets de 2021. Le premier écrit ne faisait pas consensus au sein du groupe de travail, notamment sur l'interprétation à retenir (celle, militante, de la CJUE, ou celle du droit français). Ce pan du droit est vraiment ardu.

Qui est concerné ?

Deux catégories d'intermédiaires techniques sont concernées :
- Les hébergeurs de contenus publics. Pour concourir à identifier l'auteur d'une création / modification / suppression de contenu. Article 6, I, 2 de la LCEN pour la définition, et article 6, V, A pour l'obligation ;
- Les opérateurs de communications électroniques ouverts au public. Pour concourir à identifier l'auteur d'une communication. Article R10-13 du CPCE. ET, pour les FAI (y compris VPN), pour concourir à identifier l'auteur d'une création / modification / suppression de contenu. Article 6, I, 1 de la LCEN, et article 6, V, A pour l'obligation qui visent explicitement les FAI, pas l'ensemble des opérateurs de communications électroniques (ce qui est logique : comment publier un contenu sur un téléphone fixe, par ex. ?).
Les deux régimes (CPCE et LCEN) se recoupent en partie, notamment sur les données à conserver.

Dans les deux cas, la prestation peut être gratuite ou payante, et le fournisseur peut être une personne morale ou physique, ça ne change pas l'existence de l'obligation.

La définition d'un hébergeur est plutôt claire : stockage de signaux, d'écrits, d'images, de sons ou de messages pour leur mise à dispo via des services de communication au public en ligne.

Mais qu'est-ce qu'un opérateur de communications électroniques ? Les définitions sont dans l'article L32 du CPCE mais rien n'est clair. En gros, ça regroupe les personnes qui :
- 1) exploitent un réseau de communications électroniques (ouvert au public)
  ou
- 2) qui fournissent un service de communications électroniques (idem)
  ou
- 3) qui offrent un accès à des services de communication au public en ligne
  ou
- 4) qui offrent au public, au titre d'une activité professionnelle principale ou accessoire, une connexion permettant une communication en ligne.
Sachant qu'une communication électronique, c'est toute transmission de signes, signaux, écrits, d'images ou de son par voie électromagnétique et qu'un service de communications électroniques est une prestation qui consiste à fournir de telles communications. Pourquoi le vocable change en plein milieu pour « communication au public » ? Bonne question. En tout cas, pour définir les « fournisseurs de services de communication au public en ligne » renvoie, in fine, vers les B du IV et 1 et 2 du I de l'article 6 de la LCEN donc éditeurs, hébergeurs et FAI.

On retrouve les opérateurs réseaux (première définition), les services de voix sur IP (VOIP) comme SkypeOut (deuxième), les Fournisseurs d'Accès à Internet (troisième), les fournisseurs de hotspots Wi-Fi (quatrième), etc.

Les hébergeurs ne sont pas englobés dans la deuxième définition. Par défaut, les fournisseurs de messagerie électronique non plus (je vais y revenir).

La notion qui revient est le caractère public. Un réseau privé n'est pas concerné. (C'est d'ailleurs pour cela que plusieurs entités qui opèrent un réseau informatique à une échelle métropolitaine, par exemple, destiné à un nombre prévisible d'utilisateurs (les salariés et clients / usagers de ces entités, par exemple) prennent le statut juridique de Groupe Fermé d'Utilisateurs ‒ GFU ‒, pour s'éviter les contraintes précitées du CPCE.) L'accès à Internet fournit par un employeur à ses seuls salariés / agents n'est pas concerné. Les services non-publiés (intranet, correspondance privée) ne sont pas concernés.

Un site web ?

J'ai un blog Wordpress et un shaarli. Il s'agit de services de communication au public en ligne (article 6, III, 2 de la LCEN) dont je suis l'éditeur (au sens de la loi sur la presse). À ce titre, mon hébergeur doit conserver des données sur moi.

Dans les deux cas, comme sur les réseaux sociaux, d'autres personnes peuvent écrire des articles ou des commentaires. La loi permet deux statuts : soit je suis éditeur (au sens de la loi sur la presse), soit hébergeur (au sens de la LCEN).

Si je modère mes commentaires a priori et à la mano, je suis éditeur de facto, car je choisis les contenus, j'ai le contrôle de ce qui est publié. Le Bon Coin a été reconnu hébergeur en 2014 car les annonces sont modérées par un logiciel (source).

A priori, si j'octroie des droits de publication à un nombre restreint de personnes que je choisis, je suis aussi éditeur, je choisis toujours le contenu, ce n'est pas le tout-venant qui peut publier sur mon site. On notera qu'en droit de la presse, il y a une cascade de responsabilités : l'éditeur (ou le dirlo de publication) sera poursuivi, à défaut ou au titre de complicité, les auteurs aussi, à défaut les imprimeurs, à défaut les diffuseurs, donc, a priori, un éditeur n'a pas obligation de consigner qui a écrit quoi (juste il morflera seul).

Les réseaux sociaux jouent sur les deux tableaux : ils se prétendent hébergeurs mais rendent visibles ou invisibles des contenus, les hiérarchisent, les font modérer selon une charte qui leur est propre par des travailleurs sous-payés (troisième point du 2e bloc), etc., ce qui semble constituer un rôle éditorial. Cependant, la question est loin d'être évidente à résorber, lire 1, 2, 3, 4.

Généralement, la consignation des données relatives aux auteurs de contenus (commentaires, articles, etc.) est effectuée par le site web lui-même, par son code, dans sa propre base de données.

Les requêtes de lecture / consultation d'un site web ne doivent pas faire l'objet d'une journalisation au nom d'une prétendue obligation légale qui n'existe pas. L'article 6 de la LCEN et le titre du décret 2021-1362 sont clairs : l'obligation vise uniquement les personnes qui ont contribué à la création d'un contenu.

Pages Jaunes, qui conservait un tel journal des consultations, s'est ramassée sur ce point en ce quelle n'était pas hébergeur de contenus tiers (cf. section 5 de la délibération 2011-203 de la CNIL qui est l'objet du jugement précité), donc qu'il n'y avait aucun contributeur de contenu à identifier, donc pas d'obligation légale, donc une conservation dénuée de base légale.

D'autres finalités peuvent conduire à journaliser les consultations / lectures / accès, cf. section « Journaux techniques » ci-dessous, mais pas la rétention des données de connexion.

Dans mon cas, j'ai fermé les commentaires sur mon blog (mais sinon Wordpress consigne le cœur des données qu'il est obligatoire de conserver), je n'ai plus publié de contributions extérieures depuis 2011 (et Wordpress ne consigne pas les informations nécessaires), et je suis le seul auteur sur mon shaarli. Je suis uniquement éditeur, donc j'ai rien à conserver au titre d'hébergeur.

Évidemment, mes sites web non-publiés (gestionnaire de ToDo, GLPI, agrégateur RSS, etc.), dont je suis le seul utilisateur, et qui font l'objet d'une restriction d'accès par identifiant+mdp ou par adresses IP, ne sont pas des services de communication au public en ligne, donc ils sont hors périmètre (usage strictement personnel).

Garder un journal des accès web pourrait également permettre de se disculper en cas de piratage qui conduirait à la publication d'un contenu illégal plutôt que d'en assumer la responsabilité éditoriale. D'un côté, il faut que l'attaquant publie sa prose via le web (sinon il ne sera pas journalisé par le serveur web, et à part ça, j'ai uniquement un accès SSH (qui ne consigne pas les actions) et la probabilité d'une attaque réussie diminue avec des logiciels maintenus à jour. D'un autre côté, un tel journal sera inexploitable car l'attaquant se dissimulera derrière des rebonds / intermédiaires, et le contenu, qui sera temporaire (car je m'en rendrais compte rapido) et qui ne relèvera pas de la diffamation / injure / harcèlement / appel à la haine / dénigrement / etc. mais plutôt d'actes rentables genre vente de Viagra, ne sera jamais poursuivi, donc l'occasion de dégainer le journal n'existera pas. Tout montre qu'un tel journal est inutile. Sans compter qu'un piratage doit faire partie des cas de force majeur ou équivalent ("j'ai mis en place des mesures de sécurité, elles ont été contournées, c'est pas d'chance").

J'ai jamais lu que des commentaires ou articles de blog constituent une fourniture de service de communications électroniques entraînant l'application du régime prévu par le CPCE. La directive-cadre européenne 2002/21/CE dispose même de l'inverse (cf. arrêt C‑193/18 de la CJUE, points 29 à 31).

Un serveur emails ? Un serveur de messagerie instantanée ?

Il s'agit de correspondance privée qui s'entend comme un nombre prévisible et déterminé de destinataires individualisés. Il y a donc une communauté d'intérêt entre l'expéditeur et les destinataires. Cela a été tranché par les juridictions, y compris pour le spam… C'est différent d'un site web ou d'un profil ouvert sur un réseau social auxquels tout le monde peut accéder sans restriction. Donc le statut d'hébergeur ne s'applique pas (puisqu'il n'y a pas mise à dispo via des services de communication au public en ligne).

A priori, les listes de diffusion, les MUC (discussion de groupe) Jabber, IRC, et tant d'autres entrent également dans ce cadre-là.

Attention : parfois, un même service peut relever de plusieurs statuts. Exemple : la publication web ouverte au public des archives d'une liste de discussion ou la mise à disposition au public de pièces jointes ou de calendriers par un webmail (type GMail) sortent du cadre de la correspondance privée, donc le statut d'hébergeur s'applique. J'ai rien de tout ça, donc je suis peinard.

Suis-je un opérateur de communications électroniques ? Auquel cas, la rétention à ce titre s'appliquerait, quand bien même celle à titre d'hébergeur ne s'applique pas. La question se pose pour de gros fournisseurs de messagerie, car si la correspondance est privée, le service en lui-même est ouvert au public (tout le monde peut ouvrir une adresse Outlook, par ex.).

La CJUE a tranché : GMail n'est pas un service de communications électroniques car sa fonction première n'est pas la transmission de signaux (cette charge est majoritairement portée par d'autres acteurs du réseau, quand bien même Google dispose de son propre réseau mondial), donc Google n'est pas un opérateur de communications électroniques, donc le CPCE ne concerne pas GMail. Les juridictions suisses ont tranché dans le même sens pour ProtonMail.

Comme le relève le Conseil d'État (note 48 pages 13 et suivante), la CJUE semble se contredire dans son arrêt LQDN de 2020, sauf à considérer que la différence entre SkypeOut (qui a été reconnu service de communications électroniques) et GMail est que SkypeOut assure, contre rémunération, la responsabilité de la transmission des communications en vertu d'accords passés avec des opérateurs télécoms là où GMail n'en fait rien, que l'essentiel du transport des emails est assumé par d'autres acteurs en best effort.

Sur la qualification juridique de GMail, on peut lire cet excellent historique.

Conclusion : je ne suis concerné ni par la LCEN, ni par le CPCE pour mes serveurs emails et de messagerie instantanée.

De toute façon, j'utilise les fonctionnalités « smtpd_sender_login_maps » + « smtpd_sender_restrictions = […],reject_sender_login_mismatch,[…] » de Postfix qui permet d'associer une adresse d'expéditeur à un identifiant+mdp. Donc, si, du temps où mon serveur emails hébergeait aussi une partie de ma famille (ce qui n'est plus le cas, j'en suis le seul usager), les autorités avaient débarqué pour me demander qui a émis tel email à telle date, etc., tant qu'elles me donnaient l'adresse de l'expéditeur de l'email litigieux, je pouvais dire avec certitude, et sans journal, qui en était l'auteur (sauf en cas de vol de l'identifiant+mdp, mais bon…).

Que faut-il collecter et conserver ? Combien de temps ?

Cf. les décrets 2021-1361 (pour les opérateurs au titre du CPCE), 2021-1362 (pour les hébergeurs et les opérateurs au titre de la LCEN) et 2021-1363 (pour la conservation des données de connexion et de localisation à des fins de prévention de la menace grave et actuelle pesant sur la sécurité nationale), ainsi que l'arrêt 459724 du Conseil d'État (CE) qui précise de nombreux points, dont le fait qu'on conserve uniquement ce que l'on collecte dans le cadre normal de l'activité (cf. « 2023 » dans la section « Historique » supra) aka ne pas avoir toutes les données n'est pas un problème (en n'avoir aucune, en revanche…, cf. supra).

Pour la participation à l'identification de l'auteur d'un contenu (LCEN), cinq jeux de données sont prévus :
- Identité. Noms, prénoms, date et lieu de naissance, adresse postale, numéro de téléphone, adresse emails. On notera que, pour un service de communication au public en ligne, l'article 6, III, 1, a ne prévoit pas la communication de la date et du lieu de naissance à l'hébergeur. Normalement, un décret ne peut pas prévoir des choses en sus de la loi… Conservation : 5 ans après la fin du contrat ;
- Autres informations contractuelles. Identifiant utilisé (?), pseudos utilisés, les données permettant à un utilisateur de vérifier ou de modifier son mdp (email de secours, CE : tous les « canaux de communication déclarés au préalable par l'utilisateur pour permettre la récupération de comptes ») dont 2FA. Conservation : 1 an après la fin du contrat ;
- Facturation. Type de paiement, référence du paiement, montant, date et heure (et lieu si transaction physique). Conservation : 1 ans après la fin du contrat ;
- Informations techniques sur un terminal ou la source d'une connexion. Conservation : 1 an à compter de la connexion ou de l'utilisation du terminal ou la création d'un contenu.
  
  Pour les opérateurs : identifiant de la connexion (adresse IP, d'après le CE), identifiants attribués à l'abonné, adresse IP et port source (CE : IP publique + port pour les FSI & co, et IP publique + identité civile ou IP privée pour les FAI. Pour l'IP privée, côté FAI, donc, je pensais CGNAT, mais le CE écrit « lorsque elle est partagée entre plusieurs terminaux dans le cas des réseaux locaux », ce qui englobe aussi le NAPT d'une box qui a une IP publique) ;
  
  Pour les hébergeurs : identifiant de la connexion à l'origine de la communication (adresse IP), les types de protocoles utilisés pour la connexion au service et le transfert des contenus.
- Données de trafic et de localisation. Conservation : 1 an après la connexion ou la création d'un contenu. Uniquement sous injonction du premier ministre (ce qui est le cas, cf. décret 2025-980).
  
  Pour les opérateurs : dates et heures de début et de fin de la connexion ;
  
  Pour les hébergeurs : l'identifiant attribué au contenu (ID dans la BDD, etc.), la nature de l'opération (ajout, modification, suppression ?), les date et heure de l'opération, l'identifiant de l'utilisateur ayant produit le contenu s'il l'a fourni.
Il en va de même pour identifier l'auteur d'une communication (CPCE), à quelques variantes près : il faut conserver également le numéro de téléphone appelant (RTC, par ex.), le numéro d'identification du terminal (CE : « données relatives aux connexions internet fixes par wi-fi ». Je comprends adresse MAC) ; les caractéristiques techniques (CE : « données collectées par l'opérateur pour effectuer et justifier la facturation de l'abonné et gérer son réseau, tels que le sens de l'appel, le type d'appel, le rôle de l'abonné, le type de communication ou le volume de données échangées »), date, heure et durée de chaque communication ; les données relatives aux services complémentaires utilisés (CE : « services complémentaires à la fourniture de communication par internet ou par téléphonie, tels que, notamment, les renvois d'appels ou le recours à un commutateur téléphonique privé ») ; les données techniques relatives au terminal et à la connexion (le 4e jeu de données ci-dessus) du destinataire ; et la localisation des communications par téléphone mobile.

De l'ambiguïté historique à la légende urbaine

Comme le relève Alexandre Archambault, la législation dit que tu peux conserver uniquement ce que tu manipules pour ton usage propre (cf. article 8 du décret 2021-1362, par ex.), mais l'article 39-3 du CPCE et l'article 6, VI de la LCEN prévoient des peines de prison et d'amende pour non conservation…

J'ai toujours interprété ça comme une manière de sanctionner une intention délibérée d'entraver les services enquêteurs : si t'as aucune donnée, c'est louche, s'il t'en manque certaines, ça passe. Exemples : il n'y a pas de facturation dans le cadre d'une prestation gratuite genre devenir auteur sur mon site web ; il n'y a pas de mécanisme de vérification du mdp pour un commentateur de blog ; il est techniquement impossible de fournir les données techniques du terminal du destinataire s'il n'est pas chez le même opérateur ; un hébergeur de machines virtuelles ne peut pas journaliser les modifications de contenus de son client à cause de la démarcation technique (mais il détient les jeux de données 1 à 3) ; etc. L'arrêt 459724 du CE me conforte dans cette interprétation.

De même, si l'on regarde bien, des outils comme Wordpress ou shaarli ne collectent pas toutes les informations exigées d'un hébergeur : date et lieu de naissance d'un commentateur ? Nature, date et heure d'une opération sur les contenus d'un shaarli ? Etc. Wordpress ne permet même pas de supprimer automatiquement au bout d'un an les données personnelles des auteurs de commentaires (son outil « Effacer les données », en sus de ne pas répondre au besoin ‒ il est conçu pour les demandes RGPD ‒, laisse intacte l'adresse IP, seuls le pseudo et l'adresse emails sont effacés).

Je ne peux m'empêcher de penser que c'est à cause de ça qu'il y a une légende urbaine sur une prétendue obligation de conserver le journal des accès à un serveur web ou le journal d'un serveur emails pendant un an. Démystification : 1, décision du CE contre Pages Jaunes, et explications ci-dessus.

En effet, le cœur des informations exigées (identifiant du contenu, adresse IP de l'auteur, protocole, nature de l'opération, date et heure) peuvent apparaître dans le journal des accès d'un serveur web (l'identifiant du contenu et la nature de l'opération peuvent être précisés dans l'URL, genre, pour shaarli : « POST /?edit_link=20230709_204855 »). Un conseil d'avocat sur le vif consistant à recommander cette journalisation permet d'être agnostique du type de site web utilisé et de ses capacités de journalisation, et donc de protéger le client dans le plus de cas possibles (objectif d'un avocat). Sachant que tout dépend de la question posée, du contexte présenté à l'avocat, etc., ça me paraît crédible.

Journaux techniques

Bien évidemment qu'on conserve des journaux informatiques, y compris ceux contenant les consultations de contenus, pour d'autres motifs qu'une obligation légale, tels que l'identification et le diagnostic d'un incident ou la sécurisation d'un système (détecter une compromission, parer automatiquement une attaque, etc.).

Mais cela ne peut pas être fait sous couvert de l'obligation légale présentée dans ce shaarli, il faut distinguer les finalités et la base légale, adapter la durée de conservation, etc., et, si les journaux consignent des données personnelles (comme une adresse IP), il faut les anonymiser (selon la finalité, genre vaut mieux anonymiser après l'usage du journal par fail2ban, par ex., sauf à prendre tout intérêt ;) ).

RGPD

Évidemment, le RGPD s'applique aux journaux contenant des données personnelles.

S'ils répondent aux obligations présentées dans ce shaarli, pour les éléments demandés, alors la base légale est l'obligation légale, la finalité et la durée de conservation sont précisées dans les décrets, etc. Il n'y a plus qu'à y appliquer le reste du RGPD (sécurisation, traçabilité des accès, information, ne pas divulguer tout et n'importe quoi même dans le cadre d'une décision de justice, etc.).

En revanche, si les obligations présentées ci-dessus ne t'incombent pas ou si tu souhaites journaliser plus d'éléments ou pour une durée supérieure à celle prévue par la législation ou en faire un autre usage que ceux prévus par la législation, il faut une base légale et une finalité en adéquation, une nécessité, etc. Ex. : faire des stats d'audience à partir d'un journal des accès d'un serveur web reposera très probablement sur l'intérêt légitime, et la durée de conservation (avant anonymisation) sera proportionnée à cette finalité. Un journal technique pour détecter les attaques et les compromissions reposera probablement sur l'intérêt légitime (idem). Etc.

Dernière mise à jour : août 2025.
Wed Jul 12 09:44:34 2023 - permalink -

- http://shaarli.guiguishow.info/?LxxJsA
J'ai envoyé 10246 CVs avec un bot, voici ce j'ai appris - YouTube
J'aime beaucoup la présentation du protocole et le retour d'expérience (les embûches rencontrées et les contournements mis en œuvre genre les recruteurs qui redirigent vers un site web maison d'où un vivier d'offres limité, les recruteurs qui posent des questions imprévisibles, etc.).

Je ne suis pas surpris :
- ChatGPT sait inventer (genre des exemples de sites web qui n'existent pas…) et bullshiter à la perfection, c'est un outil qui sert uniquement à ça ;
- Plus l'on donne de contexte à ChatGPT avant de l'interroger, plus ses réponses sont pertinentes (d'où le "match" Enthoven versus ChatGPT pour l'épreuve de philo du bac 2023 manquait de sérieux). Dans le cas d'espèce, c'est important car les prétentions salariales et le sens des mots diffère en fonction du métier ;
- Le COBOL est toujours demandé (surtout par les banques), c'est connu ;
- Le bagout a une réelle influence (+22 %, cf. ci-dessous). Est-ce vraiment étonnant dans un monde qui a valorisé Tapie (et tant d'autres), qui se laisse enfumer par n'importe quel label, société commerciale ou politicien, et dans lequel la majorité d'entre nous est impressionnée par ChatGPT plutôt que de remettre en cause la pertinence et l'utilité des situations qui nous imposent de bullshiter et de les refuser ? On a la société que l'on forme.
J'ignorais que :
- Stable Diffusion peut être contraint par des extensions pour ajuster la pose d'un sujet, modifier uniquement une partie de l'image, etc. ;
- Des extensions Chrome toutes simples et gratos permettent de contourner les CAPTCHA (la vidéo illustre ça avec le CAPTCHA de Cloudflare). :O
Chiffres :
- 71 % des candidatures ne reçoivent pas de réponse (cf. ci-dessous) ;
- Les candidatures avec des fautes d'orthographe ont obtenu -3 % de réponses positives. Je suis en désaccord avec Micode : c'est impressionnant sur un grand nombre de candidatures, insignifiant sinon. Aucune influence pour les bac+5 (le diplôme valide de facto le profil ?), mais -12 % de réponse pour un diplôme < bac+5 ;
- Le niveau d'études augmente le nombre de réponses positives de 5 % pour un profil ingénieur, et ne change rien pour un profil commercial (est-il plus pertinent de mettre en avant ses expériences pros sur ce type de poste ?) ;
- Faut-il sourire sur sa photo de CV ? Non. (L'expression sur les photos qu'on aperçoit dans la vidéo est neutre.) ;
- Vendre du rêve, tout enrober, présenter la moindre action comme étant épique (« j'ai ré-organisé le magasin » = « Élaboration d'un plan pour ré-agencer et optimiser les surfaces de vente »), ça rapporte +23 % de réponses positives.
Il reste plusieurs biais dans la méthodologie :
- Je pense que le taux de réponse doit fortement varier en fonction du métier recherché. Ou alors il est révélateur que le CV n'est pas adapté à l'offre. Un taux de 71 % est inhabituel pour un emploi en informatique ;
- La prise en compte des fautes d'orthographe doit dépendre du métier (relations avec le public ou non) et du niveau de qualification. De même, Micode ne précise pas leur ampleur et leur récurrence dans ses candidatures (tout le monde commet des fautes, c'est la fréquence qui est pénalisée, à mon avis) ;
- L'appréciation du niveau d'études dépend de la qualification du métier. De même, la voix off parle de « grande école » ou non quand l'image montre « Bac+5 » / « Si non bac+5 », alors que ce n'est pas équivalent, surtout dans le commerce (la grande école sert à se constituer un réseau social, rien de plus).
Je ne suis pas d'accord pour affirmer qu'un premier entretien coûte rien aux sociétés commerciales. C'est une organisation et du temps supplémentaire pour étudier la candidature de manière plus approfondie, donc du fric.
Sun Jul 9 20:48:55 2023 - permalink -

- https://www.youtube.com/watch?v=9aYgKQDOjI0
Dix ans d'emails auto-hébergés

Cela fait 10 ans que mes seules adresses emails personnelles sont liées à mes noms de domaine personnels, et que j'héberge et administre moi-même mes serveurs emails. \o/

Au global sur dix ans, ça tourne sans trop de douleur ni d'entretien. Mais, attention, cela dépend très fortement de l'usage.

En effet, tout administrateur d'un serveur emails doit s'atteler à deux problématiques : le spam entrant, et l'acceptation collective des emails qu'il envoie (émails sortants).

Je n'ai pas d'antispam, pas même de greylisting. Cela exige organisation et rigueur permanentes. Je communique ma véritable adresse uniquement à des gens de confiance et je file une adresse générique ‒ un alias ‒ ou une version suffixée par un délimiteur / tag aux autres, surtout aux sociétés commerciales, aux windowsiens et aux listes de discussion archivées sur le web. (Les alias et les délimiteurs sont également très pratiques pour tracer la revente / fuite d'une adresse emails et pour trier ses emails ‒ on peut ignorer l'adresse d'expédition et/ou elle peut changer en cours de route, ça n'a pas d'incidence sur le tri opéré sur l'adresse de destination, c'est-à-dire l'alias / le délimiteur ‒.) Mon seul regret est de ne pas avoir filé une telle adresse à plus de gens, par faiblesse. Heureusement, je comptabilise une unique conséquence fâcheuse. Bref, rigueur et ténacité. De plus, je n'ai pas besoin d'être contacté par le tout-venant, ce qui simplifie grandement la problématique.

L'acceptation collective se divise en deux : la norme et l'arbitraire. C’est essentiellement l'usage (volumétrie, contenu, destinataires) qui fait passer un serveur emails de l'une à l'autre de ces catégories.

J'ai mis en place toutes les techniques normalisées et informelles : le nom d'hôte EHLO (durant le dialogue SMTP) est déclaré dans le DNS, les adresses IPv4 et IPv6 pointées par ce nom sont celles de mon serveur, et j'ai configuré un reverse (PTR) pour chacune ; SPF ; DKIM ; ADSP ; DMARC ; TLS (avec un certificat auto-signé) + DNSSEC + DANE TLSA, etc. Pour un petit serveur emails (faible volumétrie), tout cela n'est pas obligatoire : DMARC et DKIM sont rarement imposés (GMail impose SPF ou DKIM), ADSP et DANE TLSA encore moins. C'est un investissement notable, mais quand c'est en place, ça ne coûte pas de temps de maintenance.

Surtout, les adresses IP du serveur emails doivent avoir une excellente réputation, c'est-à-dire ne pas traîner dans des listes de blocage (ce qui n'est pas le cas d'OVH, par ex.). SPF, DKIM, ADSP, DANE, etc. servent à rien si tes IP sont tricardes. Donc, il vaut mieux héberger son serveur emails chez un petit prestataire car plus c'est confidentiel, plus ça diminue la probabilité d'avoir des serveurs voisins spammeurs ou mal configurés. En IPv6, le blocage se fait par réseau de taille /64, donc pour ne pas être pénalisé par le comportement d'un voisin de réseau, il faut que l'hébergeur attribue au moins un /64 à ton serveur emails.

Comme tout cela ne suffit pas pour contrer le spam, il y a l'arbitraire. Des réseaux entiers, notamment ceux résidentiels, et des hébergeurs sont bloqués, temporairement ou non, car ils sont considérés comme des spammeurs notoires. Il existe des formalités administratives spécifiques à chaque fournisseur (ex. : Microsoft SNDS et JMRP) que j'ai toujours refusées d'accomplir (les normes, c'pas pour les chiens). Des mots-clés légitimes dans le corps d'un email sont bloqués. Des liens et des PJ légitimes et sans virus sont bloqués. La cadence de fournisseurs de liste de discussion légitimes est freinée. Sitôt qu'on grossit, à peu près tous les fournisseurs emails d'envergure cassent les pieds. Microsoft et GMail sont souvent cités mais c'est également la corvée avec Orange (qui limite la cadence autant que GMail) ou SFR Business (rejet arbitraire en fonction du contenu) ou…

Beaucoup attribuent une intention malveillante aux gros fournisseurs emails : ils voudraient fermer le marché, maintenir un oligopole afin de rendre captifs les usagers de l'email et exploiter toujours plus leur vie privée (GMail analyse le contenu des emails, La Poste ou ProtonMail modifient celui des emails sortants afin d'ajouter leur pub). C'est vrai, bien sûr, mais il ne faut pas expliquer par la malveillance ce que l'on peut expliquer par l'incompétence : à grande échelle, le spam est difficile à juguler et il est possible que les gros fournisseurs emails agissent pour le Plus Grand Bien (tm), mais leur part de marché, donc l'absence de contre-pouvoir, leur permet des prises de position cavalières qui, de fait, ne sont pas remises en question en interne. Une sorte de "ça marche / ça fait le job, je cherche pas plus loin, je réfléchis pas collectif / global" prononcé par un géant. Le poids des acteurs, voilà le cœur du problème, comme bien souvent. La concentration est néfaste. Et de ça, nous tous sommes responsables (absence de formation, laisser-aller vers la facilité, etc.).

Quand j'écris qu'un serveur emails perso tourne sans douleur ni entretien, c'est donc fonction de l'investissement technique initial sus-relaté, du fait que je suis un utilisateur avancé (alias, délimiteur, etc.), que je n'ai pas une quasi-obligation de recevoir les emails du premier venu, que j'émets un très faible volume d'emails (pas d'emails transactionnels ni de listes de discussion, etc.), que je converse plutôt avec des initiés (donc j'évite de fait les pénibles genre Orange, Microsoft Hotmail / Outlook, etc.), etc. Mon constat n'est pas transposable à des organismes (association, société commerciale, administration, peu importe) qui, eux, ont vocation à être ouverts au public, qui peuvent émettre un volume conséquent d’emails légitimes, qui ont des utilisateurs lambda donc peu formés, peu rigoureux, mais exigeants, etc.

Il y a bientôt un an, cet article a beaucoup circulé. Il dit vrai, bien entendu. Mais il manque des nuances que j'ai tenté d'apporter ici. Sans compter la prédominance erronée de l'analyse économique : à l'échelle de Microsoft / Orange / Google, etc., une analyse bayésienne coûte rien, mais sur un grand volume et une diversité d’usagers, elle est inefficace (beaucoup de faux-positifs), notamment car son apprentissage dépend de chaque usager et de sa bonne volonté et foi. Je partage partiellement son avis sur les bandeaux cookies : beaucoup de traitements de données persos étaient illicites depuis longtemps. Ils ne devaient pas perdurer, mais, plutôt que de changer de modèle économique, les acteurs continuent leurs pratiques crades en essayant d’obtenir un consentement vicié, tel le premier charo venu. Les traitements devraient reposer sur des bases légales plus saines, et le consentement devrait être l'exception, pas un prétexte pour dégainer n'importe quel traitement. La seule chose blâmable est la faiblesse des régulateurs.

En fonction de l'usage, un serveur emails perso est encore vivable.

P.-S. : il y a une différence entre l'offre gratuite de Microsoft (Hotmail / Live / Outlook) et les autres (Office 365, etc.). Mon serveur s'est toujours fait écourter quand je contacte des utilisateurs d'Outlook, et l'année écoulée n'a pas fait exception, mais, comme d'habitude, j'ai reçu des réponses de deux des trois destinataires professionnels dont le nom de domaine est porté par les serveurs emails de Microsoft (aucune idée si le troisième a voulu me répondre, mais, je le suppose, demande de devis, tout ça).
Sun Jul 9 14:02:53 2023 - permalink -

- http://shaarli.guiguishow.info/?7aioyg
RFC 8659 - DNS Certification Authority Authorization (CAA) Resource Record

Mes notes sur CAA.

Quand on a un certificat auto-signé ou signé par une autorité de certification maison :

For example, the following RRset requests that no certificates be issued for the FQDN "nocerts.example.com" by any Issuer.

nocerts.example.com CAA 0 issue ";"

CAA utilise l'aspect arborescent du DNS donc une autorisation vaut pour le domaine visé et ses sous-domaines. ;)
Sun Jul 9 11:41:25 2023 - permalink -

- https://datatracker.ietf.org/doc/html/rfc8659
Comment identifier des hébergeurs informatiques à taille humaine et les évaluer ?
J'ai déménagé mon serveur perso (pas celui qui héberge ce site web). Retour d'expérience.

Historique et problématique

Initialement, ce serveur était hébergé chez moi, sur un Raspberry Pi puis sur un OLinuXino, et raccordé proprement au réseau (condition pour avoir un serveur emails fonctionnel) avec le VPN d'un FAI associatif.

Quand ces ordinateurs ont rendu l'âme (avant les cartes SD, comme quoi), j'avais une contrainte personnelle de forte mobilité. J'ai donc hébergé ce serveur avec les autres auprès d'associations auxquelles je contribuais techniquement et financièrement, ARN et Grifon.

Début 2019, par démotivation et désespoir, j'ai quitté le monde associatif. Comme il est inconvenant de faire porter une charge de travail (héberger mon serveur) sur des bénévoles sans contribuer réellement (ne serait-ce qu'à la prise de décision), j'ai déménagé au plus simple : OVH. Ça fait le boulot pour pas cher. C'était censé être temporaire. Mais la flemme s'est installée.

Mon problème est simple : mes emails arrivent de moins en moins jusqu'à leurs destinataires. Quand j'étais auto-hébergé ou chez des assos, seuls quelques fournisseurs emails hégémoniques donc casse-couilles me rejetaient comme Microsoft. À l'inverse, ces derniers mois, je suis tricard, temporairement ou non, chez pas mal d'autres fournisseurs : Infomaniak, Octopuce (qui utilise Spamhaus), SFR (ceci dit, même les serveurs de Gandi se font rejeter), FDN (qui utilise Spamhaus sur ses anciennes listes de discussion), etc.

Deux explications :
- J'utilise IPv6. OVH attribue une unique IP à chaque client. Or, la norme est d'attribuer un réseau /64 par client. Donc les mécanismes anti-spam bloquent à cette granularité. Donc au moindre voisin (de réseau) spammeur ou mal configuré, vlam, je suis pénalisé. Je suis ainsi listé dans la liste CSS de Spamhaus. Je les ai contactés : un voisin émet en IPv6 sans AAAA ni PTR associé, donc vlam. J'ai contacté ledit voisin : aucune réponse, bien entendu. J'ai contacté l'assistance d'OVH : aucune réponse satisfaisante, bien entendu (l'attribution d'un /64 est en projet, faire un signalement sur l'adresse abuse@). J'ai procédé au signalement abuse : aucune réaction. Quand bien même il y en aurait eu, le problème reviendrait au premier voisin mal-configuré, c'est sans fin ;
- Mon IPv4 et mon domaine ne sont pas listés dans une liste de blocage (soit on fait le tour des principales, soit on trouve des testeurs multi-listes dans un moteur de recherche). En revanche, OVH est réputé pour être un gros émetteur de spam. Donc, ses réseaux /24 (ou plus grand) et/ou son numéro d'AS sont listés dans des listes de blocage. Aucune solution.
Cahier des charges
- Je veux une organisation commerciale. Je ne souhaite pas m'impliquer dans une association ni faire porter une charge de travail (héberger mon serveur) sur des bénévoles sans contribuer réellement. De plus, j'ai déjà vu des comportements douteux d'adminsys associatifs, et je n'ai pas la motivation de faire le tri. Ça exclut les CHATONS (d'autant qu'au moins la moitié d'entre eux reposent sur des gros hébergeurs style OVH, Scaleway ou Hetzner ‒ source ‒) ;
- Je veux une machine virtuelle. Cela exclut beaucoup d'hébergeurs dont O2Switch, Netim, Weboupro, etc. ;
- Je veux une offre grand-public, une commande automatisée et un espace client qui me procure de l'autonomie dans la gestion quotidienne de ma machine virtuelle. Pas de devis ni de montage spécifique à ma personne ni d'infogérance. Là encore, ce critère exclut beaucoup d'entités dont Octopuce, FullSave, Evolix, etc. ;
- Je veux une société commerciale française avec des infrastructures en France et une majorité de ses affaires en France. Deux objectifs : 1) déterminer quelle législation s'applique (une grande partie de ma vie numérique passe par ce serveur perso) ; 2) favoriser des acteurs locaux (voir critère suivant). Ce critère élimine beaucoup d'entités dont Hetzner, Infomaniak, Amen (actionnaire italien, groupe européen), IONOS (ex-1&1), Gandi (qui, au début 2023, a fusionné avec une entité néerlandaise, sans compter la somptueuse augmentation des tarifs annoncée et la fin de services cool dont les emails inclus avec un nom de domaine), Oxabox, MonoVM, etc. ;
- Je veux une entité qui n'est pas marquée au fer rouge comme hébergeant des spammeurs, et qui propose un réseau IPv6 de taille /64 au minimum (lire la fin de la section précédente pour comprendre). Cela est difficile à évaluer objectivement. J'ai utilisé UCEPROTECT et Spamhaus (qui est massivement utilisé) pour vérifier le score de l'AS et de plusieurs réseaux IP de chaque hébergeur. Les chiffres portent sur les 7 derniers jours, donc il faut surveiller quelques semaines pour avoir une vision correcte. J'ai également privilégié les petites entités. L'idée est : plus c'est petit, plus c'est confidentiel, plus ça augmente la probabilité d'éviter les spammeurs et les serveurs mal configurés. Là encore, c'est difficile à évaluer objectivement. J'ai pris en compte le chiffre d'affaires déclaré, la taille du réseau (le nombre d'adresses IP), le contenu et l'aspect du site web (j'ai une expérience qui me permet de juger grosso-modo, tel un Etchebest dans Cauchemar en cuisine). Ça exclut Scaleway (trop gros, mais score spam OK), Ikoula (risque de spam en hausse ces dernières semaines) ;
- Je veux une connectivité décente aux autres réseaux français. Pour l'évaluer, j'utilise le looking glass du NLNOG, RIPEstat, et BGP HE ;
- Je veux les services et outils usuels : paiement par prélèvement ou virement bancaire, IPv6, VNC, mode rescue, reverse IP, etc. ;
- Je privilégie une infrastructure en logiciel libre (KVM, etc.).
Candidats
- MilkyWAN : je leur ai posé deux questions techniques (modèle d'hyperviseur et existence d'un VNC) en septembre 2022, pas de réponse. J'ai bien reçu l'accusé de réception émis par leur formulaire web.
- FirstHeberg (anciennement FreeHeberg) :
  
  Score spam quasi OK. Moyen mis en œuvre pour le conserver : demander un justificatif d'identité et de domicile. La loi dispose qu'un hébergeur doit collecter noms, prénoms, date et lieu de naissance, adresse postale, numéro de téléphone et adresse emails (mais les hébergeurs n'ont pas la charge de vérifier ces informations en collectant des justificatifs), donc ça ne me paraît pas être excessif ;
  
  Le réseau semble avoir IELO comme transitaire principal (HE et IP Max en sus). J'en ai plutôt une bonne image (bien connecté aux réseaux français), donc ça ne m'inquiète pas ;
  
  Site web et espace client épurés, pas trouzemilles scripts, feuilles de style, etc. téléchargés depuis trouzemilles prestataires. Google reCAPTCHA dans la page de contact et Google Fonts sur la page d'accueil tout de même.
- Ikoula :
  
  Score spam en hausse ces dernières semaines, plus élevé que Scaleway. Un réseau blacklisté ;
  
  Quelques merdes sur le site web dont jquery.
  
  Rachetée par Sewan en 2021. Agglomérat de différentes sociétés française, belge, espagnole, allemande, ricaine du monde des télécoms et de l'hébergement. 130 M€ de CA en 2021 (source = societe.com), soit plus que Scaleway. On s'éloigne de la petite entité.
- PulseHeberg :
  
  Site web derrière Cloudflare. Ça retire toute crédibilité. T'es hébergeur, mais t'es pas capable d'héberger ta vitrine ? Tu vantes ta capacité à résister aux DDOS, mais pas pour ton site web ? De plus, vu comment j'asticote un tas d'entité sur la non-conformité au RGPD que cela représente, laisser passer ça serait incohérent ;
  
  Quelques merdes sur le site web : Google Fonts, unpkg.com, etc. ;
  
  Un développement tourné vers l'international, notamment vers les États-Unis (leur site web annonce un futur centre de données à San Jose), donc un potentiel conflit de lois à cause du Cloud Act ricain.
- Ligne Web Services (LWS) :
  
  Site web derrière Cloudflare ;
  
  Adista en transitaire unique, ça craint un peu.
- OuiHeberg :
  
  Cloudflare ;
  
  Connectivité : IPv4 = que des prestataires étrangers dont j'ignore la qualité de leurs interconnexions avec les réseaux français ; IPv6 = uniquement Cogent qui s'est livrée à des guéguerres commerciales avec Google et Hurricane Electric, dont la conséquence était l'impossibilité d'accéder à ces réseaux depuis Cogent.
- OMGSERV :
  
  Cloudflare ;
  
  Numéro d'AS introuvable donc impossible de vérifier la réputation et la connectivité du réseau. S'adresse essentiellement aux joueurs en ligne qui sont rarement de bons adminsys, ce qui renforce ma défiance. (Sans compter Teamspeak qui facilite masse d'attaques volumétriques).
- ONETSolutions :
  
  Cloudflare ;
  
  Le numéro d'AS que j'ai trouvé annonce aucun préfixe IP, donc impossible de vérifier la réputation et la connectivité du réseau.
- Inulogic (anciennement Free-h) :
  
  Pas d'IPv6 ;
  
  Connectivité IPv4 : uniquement Cogent, ça craint.
Ordre de grandeur

Chiffres d'affaires 2021 :
- OVH : 556 millions d'euros ;
- Scaleway : 94 M€ ;
- Ikoula : 6,2 M€ (mais société d'un groupe dont la filiale française a déclaré 130 M€) ;
- FirstHeberg : 1,3 M€ (avec des activités de FAI fibre, téléphonie, etc.) ;
- PulseHeberg et LWS ne publient pas leur CA. Je n'ai pas cherché les autres entités vu qu'elles ne m'intéressent pas.
Source : societe.com.

Retenu

J'ai choisi FirstHeberg.

Concernant le port tcp/25 (email), il est bloqué uniquement en sortie et en IPv4. Mes justificatifs caviardés (j'ai conservé les seules infos légalement obligatoires, cf. ci-dessus) ont été acceptés. Contrairement à ce que prétend le site web, le port tcp/587 n'est pas bloqué.

L'espace client ne permet pas de définir un reverse IPv6, mais une demande d'assistance permet de l'obtenir.

L'assistance est plutôt réactive et les réponses sont plutôt de qualité.

Évidemment, tout n'est pas parfait :
- Propos publics éruptifs (sur le coût de l'électricité, par ex.) ou plaintifs (sur le coût des attaques DDOS il y a quelques années, là où d'autres gens du métier y voyaient une absence d'anticipation et/ou des mauvais choix techniques en connaissance de cause) ou contraire à mes convictions (sur la neutralité du réseau) tenus par le patron. (Twitter est désormais un réseau fermé, donc impossible de pointer les propos, sans compter que telle n'est pas mon intention) ;
- Lacunes techniques (VNC en panne quasiment une semaine, pas de prélèvement bancaire, la section facturation de l'espace client, IPv6 pas au même niveau d'intégration qu'IPv4, rejet des adresses emails contenant un délimiteur « + », etc.) et rédactionnelles qui entraînent de la confusion (sur le site web et l'espace client, genre écart entre ce qui est annoncé et pratiqué, comme la définition du mdp ou le déblocage du port tcp/25). J'ai remonté tout ça à l'assistance.
On verra comment ça se passe à la longue.

Procédure de migration

Mon système Debian GNU/Linux est chiffré en intégralité (sauf /boot, même si GRUB permet de s'en passer).

Même procédure que d'habitude. J'ai rencontré aucun des problèmes mentionnés. Ni partition mal copiée ni difficulté pour monter les partitions fraîchement copiées.

J'ai changé la phrase de passe du conteneur chiffré (cryptsetup luksAddKey /dev/sdX + cryptsetup luksRemoveKey /dev/sdX). J'en ai profité pour passer sans encombre à la version 2 de LUKS (cryptsetup convert --type luks2 /dev/sdX) et à l'algo de dérivation de clé argon2id (cryptsetup luksConvertKey --pbkdf argon2id /dev/sdX).

Prenant en compte la panne du VNC (cf. ci-dessus), j'ai mis en place un système me permettant de saisir la phrase de passe de mon système chiffré via SSH.
Sat Jul 8 18:29:52 2023 - permalink -

- http://shaarli.guiguishow.info/?fVRjRA
#960023 - SSHFP stops working with libc6 2.31 [AD bit stripped] - Debian Bug report logs

Avant de se reposer sur la validation DNSSEC, il faut avoir confiance envers les serveurs DNS récursifs (resolver) que l'on utilise et sur la sécurité du chemin réseau qui nous sépare de lui.

C'est pour ça que, par défaut, le stub-resolver DNS de la libc ne demande pas la validation DNSSEC et retire le bit qui indique qu'une réponse est validée. Pour marquer notre confiance envers les récursifs que l'on utilise (et surtout celle envers le chemin qui nous sépare d'eux), il faut ajouter options trust-ad dans /etc/resolv.conf.

L'utilisation des enregistrements DNS de type SSHFP par le client SSH repose dessus. Sans la validation, il affiche (avec « -v ») : « found 1 insecure fingerprints in DNS ».

Vache, ça fait des années que le comportement du stub-resolver a changé et que je ne m'en étais pas rendu compte. :O
Sat Jul 8 00:37:54 2023 - permalink -

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023
Déverrouiller un système distant et chiffré lors de son démarrage
Le système de mon serveur personnel (pas celui qui héberge ce site web) est totalement chiffré (/boot est une partition indépendante même si GRUB permet de s'en passer). Au démarrage, je saisis la phrase de passe depuis le VNC proposé par l'hébergeur.

Très récemment, j'ai changé d'hébergeur. Avant mon déménagement, son VNC a été dysfonctionnel pendant quasiment une semaine. Ça a été le déclic : comment faire si je dois redémarrer mon serveur pendant une panne ou une maintenance du VNC de mon hébergeur ? Autant une panne du VNC de mon ancien hébergeur me semblait improbable ou très limitée dans le temps au nom du « too big to fail », autant une panne longue de mon nouvel hébergeur me paraît crédible. Donc il m'appartient de concevoir un plan B. (On pourra aussi argumenter qu'une connexion SSH directe sera toujours plus sécurisée que le VNC over HTTPS de l'hébergeur par la simple disparition de l'intermédiaire.)

Il est possible de demander à l'initrd de se connecter au réseau, de proposer un accès SSH (avec l'implémentation minimaliste dropbear) et un terminal (implémentation minimaliste busybox) qui permettent d'ouvrir le conteneur LUKS. J'avais lu ça chez Aeris il y a quelques années, mais on va adapter un peu.
- Installer un serveur SSH minimaliste uniquement dans l'initramfs : apt install dropbear-initramfs ;
- Ajouter sa clé publique SSH dans /etc/dropbear-initramfs/authorized_keys. L'auth par mot de passe est impossible (cela garantit la sécurité du serveur contre la force brute en cas de redémarrage inattendu suite à un plantage ou à une maintenance côté hébergeur) ;
- Créer un fichier /etc/initramfs-tools/conf.d/ip. Format : « IP=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip> » (via) ;
  
  Exemple : (je ne configure ni serveur NFS ni nom d'hôte, ni DNS, ni NTP) : IP=192.0.2.42::192.0.2.1:255.255.255.0::eth0:off ;
  
  ATTENTION : contrairement à ce que dit la doc', « IP= » est en majuscule et sensible à la casse (au moins sur Debian GNU/Linux Bullseye) ;
  
  IPv6 statique n'est pas disponible sans ajouter des scripts persos. Vu la criticité de l'initrd, ça ne me tente pas. Des messages ICMPv6 « Router Solicitation » sont émis par l'initrd, ce qui laisse à penser qu'IPv6 dynamique est disponible. Mais, chez tout hébergeur sérieux, le niveau 2 (ARP, NDP, DHCP, STP, etc.) est filtré ou rendu caduque, donc ça n'a pas d'intérêt.
- Reconstruire les initrd : update-initramfs -uk all ;
- On fabrique un enregistrement DNS de type SSHFP ou une entrée pour le fichier known_hosts (cela permettra d'authentifier la machine, d'être sûr qu'on causera au bon serveur SSH qui aura booté sur l'initrd). Dans les deux cas, ça nécessite de convertir la clé privée du serveur depuis le format dropbear vers une clé publique au format openssh (attention : depuis OpenSSH 8.7, il ne peut y avoir qu'un seul enregistrement SSHFP par nom, donc une seule paire de clés pour l'initrd et le système…) :
  
  known_hosts : ssh-keygen -y -f /dev/stdin <<< $(dropbearconvert dropbear openssh /etc/dropbear-initramfs/dropbear_rsa_host_key -). Ajouter la sortie au fichier known_hosts de la machine qui accédera au serveur ;
  
  Enregistrement SSHFP : ssh-keygen -r <FQDN> -f /dev/stdin <<<$(ssh-keygen -y -f /dev/stdin 2>/dev/null <<<$(dropbearconvert dropbear openssh /etc/dropbear-initramfs/dropbear_rsa_host_key -)).
- reboot le serveur ;
- dropbear n'implémente pas toute la crypto moderne, donc, si comme moi tu blindes ta conf' client SSH, il faudra réduire tes prétentions. Cela peut se faire avec une entrée dédiée dans .ssh/config ;
- ssh root@<serveur> doit fonctionner ;
- Comme nous le dit le prompt, il suffit d'utiliser la commande cryptroot-unlock. Après la saisie de la phrase de passe, le système démarrera :
  
  ~ # cryptroot-unlock Please unlock disk sda2_crypt: cryptsetup: sda2_crypt set up successfully ~ # Connection to 192.0.2.42 closed by remote host. Connection to 192.0.2.42 closed.
Fri Jul 7 23:35:22 2023 - permalink -

- http://shaarli.guiguishow.info/?cgjIQw
Dix ans de DNSSEC
Cela fait plus de 10 ans que j'utilise DNSSEC sur mes noms de domaine personnels. \o/

À l'époque, info. était signé mais la soumission de délégations signées n'était pas ouverte (ou pas disponible chez mon bureau d'enregistrement ‒ Gandi ‒), donc j'utilisais le registre DLV de l'ISC, et BIND ne gérait pas entièrement les clés DNSSEC ni leur renouvellement automatique (source). :D

Je gère moi-même l'hébergement de mes zones DNS (avec BIND9 et NSD) et DNSSEC (avec OpenDNSSEC).

Au global, de nos jours, c'est une affaire qui tourne sans douleur. Ça n'a pas toujours été le cas :
- En 2013, sur Debian Squeeze, OpenDNSSEC n'était pas fonctionnel sur Raspberry Pi (voir) ni sur OLinuXino (voir). Point commun : architecture ARM ;
- En 2013, OpenDNSSEC avait un bug lors du roulement de la KSK (voir) ;
- Je me souviens surtout des mises à jour très pénibles, y compris pour un changement mineur de version (voir). Parfois, comme en 2017 / Debian Stretch, la responsabilité incombait à un paquet Debian mal conçu (voir) ;
- Depuis Debian Buster / 2020, j'ai une race-condition qui se déclenche très rarement et sans impact (voir).
Fri Jul 7 19:36:58 2023 - permalink -

- http://shaarli.guiguishow.info/?w4pvpw
[ Lister les prochains renouvellements de clés planifiés par OpenDNSSEC + forcer un renouvellement ] Rollover with OpenDNSSEC

Visualiser / lister les prochains roulements (renouvellements) de clés DNSSEC planifiés par OpenDNSSEC : ods-enforcer rollover list.

Forcer le renouvellement / roulement / rollover des clés (en cas de compromission, par ex.) : ods-enforcer key rollover --zone <nom_zone>. On peut limiter à un type de clé (KSK ou ZSK) en ajoutant --keytype <KSK|ZSK>.
Fri Jul 7 18:47:31 2023 - permalink -

- https://nsrc.org/activities/agendas/en/dnssec-3-days/dns/materials/labs/en/opendnssec-lab2-rollover.html
La carte aux trésors - Replay et vidéos en streaming - France tv

Depuis le 5 juillet dernier, des épisodes inédits du jeu télévisé La Carte aux trésors sont diffusés les mercredis soirs. \o/

La disponibilité d'une semaine du replay est abusée, mais, comme d'hab, torrent est notre ami. :)

(ÉDIT DU 12/07/2023 : aujourd'hui, la dispo court jusqu'au 04/08/2023. FIN DE L'ÉDIT.)

Pour regarder en direct : yt-dlp -o - 'https://www.france.tv/france-3/direct.html' | vlc -.
Fri Jul 7 18:41:09 2023 - permalink -

- https://www.france.tv/france-3/la-carte-aux-tresors/
Politique de conservation des journaux (logs) basée sur le temps avec journald ?

systemd-journald est conçu pour archiver puis supprimer les vieux journaux (logs) selon une politique d'occupation de l'espace de stockage. Détails ici.

Parfois, on a besoin de conserver un journal un certain temps, ni plus, ni moins. Exemple ? L'obligation de conservation des données de connexion qui, en France, pèse sur les opérateurs de communications et les hébergeurs. Elles doivent être conservées 1 an. En dessous, l'opérateur / l'hébergeur ne remplit pas son obligation. Au-delà, le traitement est illégal au regard du RGPD car dénué de base légale (l'obligation légale court pour 1 an, pas plus).

Exemple moins pertinent : avec un volumineux système de stockage, on se retrouve avec 4 Go de journaux qui peuvent donc remonter loin et être pénibles à exploiter. Mais dans ce cas, on préférera affiner la valeur des paramètres de journald.

Pour une politique temporelle de conservation, journald propose le paramètre MaxRetentionSec. Source. Délai après lequel un journal contenant des entrées plus vieilles que ce délai sera supprimé. Par défaut, sa valeur est 0 afin de mettre en œuvre uniquement une politique de conservation basée sur l'occupation disque.

Il faut également configurer MaxFileSec. Un journal ne peut pas stocker des entrées au-delà de cette durée (1 mois par défaut). Un nouveau journal sera créé (et, l'ancien, archivé, donc supprimable). Il faut la positionner à « 1day ». Ainsi, lors de la suppression d'un journal archivé, après 1 an, seules les entrées d'il y a 366 jours seront supprimées. De même, seules les entrées du jour seront dans le journal courant, le reste sera archivé. Sans ce paramètre, soit journald supprimera le 12^e mois (improbable), soit il conservera 1 an et 1 mois. Dans les deux cas, ça ne répond pas au besoin.

(Cette réflexion est basée sur le fait, qu'à priori, journald efface un journal en entier, pas les entrées d'un journal qui ont dépassé la date de péremption. Sa doc' consigne, pour le paramètre MaxFileSec : « However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. ». Et le manuel de journalctl, pour l'action rotate, consigne : « Journal file rotation has the effect that all currently active journal files are marked as archived and renamed, so that they are never written to in future ».)

Conséquence logique : il faudra également modifier la valeur de SystemMaxFiles, car il y aura jusqu'à 1 an de journaux archivés chaque jour. Et il faudra désactiver la politique de conservation fondée sur l'occupation de l'espace de stockage (cf) sinon journald pourra supprimer des journaux récents si l'espace de stockage vient à manquer.

On peut aussi désactiver totalement ou partiellement journald (Storage). Il continuera à transmettre les journaux à rsyslog (par défaut sous Debian), et on pourra les traiter à l'ancienne avec logrotate.
Mon Jul 3 17:32:00 2023 - permalink -

- http://shaarli.guiguishow.info/?EhB5iA
Un regard sur systemd-journald
systemd-journald est conçu pour archiver puis supprimer les vieux journaux (logs) selon une politique d'occupation de l'espace de stockage. Pour une politique basée sur le temps, lire ici.

Par défaut, il prend le minimum entre 10 % de la taille du système de fichiers (SystemMaxUse) et 85 % (SystemKeepFree), dans la limite de 4 Go soit min( min(10 % ; 4 Go) ; min(85 % ; 4 Go) ). 85 % car SystemKeepFree calcule ce qui doit rester libre, alors que SystemMaxUse calcule la taille maximale du journal. Les deux ne sont pas comparables directement, donc on harmonise : si 15 % doivent rester libre, 85 % peuvent être occupés et se comparent aux 10 % de SystemMaxUse.

Si la valeur de SystemKeepFree est dépassée dès le démarrage de journald, alors le plafond sera l'espace restant.

Évidemment, si tu sépares / et /var dans des systèmes de fichiers différents, journald prend en compte la taille de /var.

SystemMaxFileSize définit la taille maximale d'un fichier journal. Par défaut, 1/8^e de SystemMaxUse. SystemMaxFiles définit le nombre parallèle de journaux. 100 par défaut.

L'occupation du stockage se mesure avec :
- journalctl --disk-usage
et/ou
- du -hs /var/log/journal
et/ou, en version prise de tête inutile :
- journalctl -u systemd-journald -o json | jq 'select(.JOURNAL_PATH | test("/var/log/journal"))' 2>/dev/null | jq -s '.[-1].CURRENT_USE_PRETTY'.
Sur tous mes systèmes Debian GNU/Linux 11 (bullseye), SystemKeepFree est calculé automatiquement pour 5 % du système de fichiers, pas 15 % comme le dit la doc'.

On peut voir ça avec :
- journalctl -u systemd-journald -x
et/ou
- journalctl -u systemd-journald -o json | jq 'select(.JOURNAL_PATH | test("/var/log/journal"))' 2>/dev/null | jq -s '.[-1] | .MAX_USE_PRETTY,.DISK_KEEP_FREE_PRETTY'.
Le manuel (man) livré par Debian dit 15 %. La configuration n'est pas surchargée dans aucun des chemins donnés par la doc' de journald (on peut également vérifier avec systemd-analyze cat-config systemd/journald.conf | grep -e 'SystemMaxUse' -e 'SystemKeepFree'). Donc, a priori, Debian change ça à la compilation. 5 %, ce n'est pas déconnant, ça correspond à l'espace réservé pour root sur un système de fichiers ext, mais ça serait mieux de l'annoncer.

Sur l'un de mes systèmes Debian GNU/Linux, une station de travail, journald dépasse la limite qu'il cale sur SystemMaxUse. Toutes les commandes permettant de mesurer l'occupation disque le montrent, y compris du.

Dès son démarrage, il consigne que le journal dépasse la limite, mais ne prend aucune action correctrice.

Lors du démarrage, il restait, et il reste 40 % de libre sur le système de fichiers /var, donc on n'est pas dans l'hypothèse d'un dépassement de SystemKeepFree (et, toute façon, la limite a été calée sur SystemMaxUse).

J'ai 8 fichiers journaux dont 7 archives, donc il ne s'agit pas d'un unique journal courant volumineux impossible à supprimer (seuls les archives peuvent l'être). Sa taille, comme celle des journaux archivés est inférieure à SystemMaxFileSize.

Après un journalctl --rotate, qui demande d'archiver les journaux courants, je repasse sous la limite. Donc, a priori, journald s'impose la limite au moment de l'archivage, donc la limite est SystemMaxUse + SystemMaxFileSize (source), soit, par défaut, SystemMaxUse + (1/8)*SystemMaxUse.

Je constate également qu'il y a deux journaux dans /var/log/journal : system et user-1000. Et, d'après mes observations sur mon système, chaque fragment (archive + courant) peut grossir jusqu'à 1/8^e de SystemMaxFileSize, donc, forcément, ça peut dépasser SystemMaxUse

Merci Johndescs du coup de main pour démêler tout ça.
Mon Jul 3 16:10:26 2023 - permalink -

- http://shaarli.guiguishow.info/?9dWrxA
Firefox is ready to protect against potentially dangerous downloads | TechRadar

Firefox me gonfle à bloquer des téléchargements avec le motif « Fichier non téléchargé : risque de sécurité potentiel ».

about:config, dom.block_download_insecure => false.

C'est censé gueuler lors d'un téléchargement en HTTP (sans TLS), mais ça semble aussi dépendre de la source : un .deb depuis les serveurs de Debian, ça couine ; le même .deb depuis mon serveur perso, toujours en HTTP, ça passe.

Ça ne fait que le énième paramètre Firefox à changer…
Fri Jun 30 17:15:32 2023 - permalink -

- https://www.techradar.com/news/firefox-is-ready-to-protect-against-potentially-dangerous-downloads
Article R343-3 - Code des relations entre le public et l'administration - Légifrance

Une administration a un mois pour informer la CADA de la suite qu'elle va donner à une demande d'avis dans le cadre d'une communication de documents.

Dans son rapport d'activité 2021, la CADA consigne que le taux de réponse des administrations s'élève à 61,5 %, constant sur les 5 dernières années. Parmi ces réponses, 69,6 % des administrations ont fait part de leur intention de suivre au moins partiellement l'avis de la CADA, en baisse constante depuis 5 ans.

On notera que ce même article prévoit que la CADA rende son avis sous un mois. Ça n'a jamais été le cas pour moi. Le même rapport d'activité consigne un délai moyen annuel de traitement d'une demande d'avis de 82 jours en 2021.
Thu Jun 29 18:01:28 2023 - permalink -

- https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000031370511
Adresser une demande de communication de docs à la CADA, c'est possible
Il est possible de demander la communication d'un certain nombre de documents détenus par une administration française. Si cette dernière s'y oppose (explicitement ou implicitement après un mois sans réponse), il est possible de saisir, dans les deux mois, une autorité administrative indépendante, la CADA, d'une demande d'avis (qui est un pré-requis pour contester le refus de l'administration au contentieux). Lire toutes les notes concernant cette procédure.

La CADA contacte alors l'administration visée afin qu'elle produise des observations (pourquoi a-t-elle refusé ?). Ces observations destinées à la CADA sont des documents administratifs… communicables (sous réserve des habituelles réserves ‒ vie privée, secrets des affaires, fiscal, défense, etc. ‒). Pré-requis : la CADA doit avoir rendu son avis (sinon, documents relatifs à une décision en cours d'élaboration, donc pas communicables). C'est le journaliste Marc Rees qui me l'avait appris (je ne trouve plus le tweet ou l'article NextInpact original, mais il y a ce tweet plus récent).

Il y a deux parties qui échangent (CADA et administration). À qui demander ? Est-il seulement possible d'adresser une demande de communication de docs à la CADA ? Oui ! Il est même possible de saisir la CADA contre un refus de communication de la CADA. :D Pour m'en assurer, j'ai cherché (et trouvé) des avis dans la base des avis de la CADA.

La CADA a répondu à ma demande de communication en me transmettant les observations produites par l'administration.

À titre d'inspiration, voici ma demande adressée à la CADA par email :
Sujet : Demande de communication de documents détenus par la CADA

Bonjour,

Je demande à la CADA de me communiquer une copie des documents suivants :

Tous les échanges (email, courrier, etc.), toute la correspondance bidirectionnelle, entre la CADA et <CENSURE> intervenus dans le cadre de ma demande d'avis numéro <CENSURE> adressée à la CADA le <CENSURE> via son formulaire de saisine en ligne (avis rendu le <CENSURE> qui m'a été transmis le <CENSURE>). Pour les éventuels courriers postaux envoyés par la CADA, vous y joindrez toute preuve de dépôt La Poste (affranchissement, suivi LRAR, tampon La Poste, etc.) ;

L'existence de ces échanges est attestée dans le corps de l'avis rendu par la CADA, cf. PJ 1 (« en réponse à la demande qui lui a été adressée », « ce que fait valoir le président de <CENSURE> », « le président de <CENSURE> […] lui a indiqué », etc.).

Conformément à l’article L311-9, 3° du CRPA, je vous demande de m’adresser ces documents par courrier électronique à l’adresse <CENSURE>.

Cordialement.
Thu Jun 29 17:10:45 2023 - permalink -

- http://shaarli.guiguishow.info/?saasZg
Up : Rotation / rollover des clés DKIM : opendkim-genkey et sélecteurs - GuiGui's Show

Ce tuto reste d'actualité.

Je n'avais pas renouvelé mes clés DKIM depuis 2016. C'est fait. Ça prend moins de 15 minutes par serveur, et encore, en traînant.

Malgré un rejet dû à cela en 2020, je suis resté sur une taille de clé RSA de 3072 bits. La norme (RFC 8301 qui met à jour le RFC 6376) dit que les expéditeurs devraient utiliser une clé RSA d'au moins 2048 bits et que les destinataires doivent savoir valider une taille de clé RSA comprise entre 1024 bits et 4096 bits. Pas d'avancées cryptographiques et pas d'actualisation du référentiel de l'ANSSI, donc je ne vois pas l'intérêt de passer à la taille supérieure.

ÉDIT DU 30/12/2023 : consécutivement à une pièce jointe trop lourde, le serveur emails d'une administration m'a renvoyé mon email. Les entêtes ajoutés par lui montraient une erreur de validation de ma signature DKIM au motif d'une clé trop grosse (sans que ça soit l'origine de mon problème). J'ai décidé de passer à une clé RSA de 2048 bits. DKIM ne sert déjà à rien, ni dans la lutte contre le spam, ni pour l'acceptation d'un petit serveur par les géants de l'email, je ne vais pas en plus me mettre des bâtons dans les roues. Dommage. FIN DE L'ÉDIT DU 30/12/2023.
Sat Jun 24 15:15:53 2023 - permalink -

- http://shaarli.guiguishow.info/?D0LR4Q
Outils de diagnostic DoT / DoH

Liste non exhaustive triée par préférence.

kdig

Ma préférence va à kdig, le dig de l'implémentation DNS Knot, car il donne des informations techniques sur la négociation TLS et le dialogue HTTP (status, etc.). Paquet knot-dnsutils dans Debian GNU/Linux.

DoT avec vérification du certificat x509 : kdig @ns1.fdn.fr +tls +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

DoH avec vérif' du cert' x509 : kdig @ns1.fdn.fr +https +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

dig

À partir de sa version empaquetée dans la version 12 (bookworm) de Debian GNU/Linux (paquet bind9-dnsutils), dig, l'outil de l'implémentation DNS BIND prend en charge DoT et DoH, mais il file aucune info sur la session TLS et les messages HTTP.

DoT avec vérif du cert' x509 : dig @ns1.fdn.fr +tls +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

DoH avec vérif : dig @ns1.fdn.fr +https +tls-ca=/etc/ssl/certs/ca-certificates.crt AAAA shaarli.guiguishow.info.

homer / remoh

Développé en python par Bortz. Dépôt git. Tutoriel. Il n'est plus maintenu (source : échange privé avec Bortz).

La sortie est brute de décoffrage. Outil plus pour s'amuser qu'autre chose et qui ne file aucune info sur la session TLS et les messages HTTPS. Vérif' du cert' x509 effectuée de base.

DoT avec vérif' : ./remoh.py -t ns1.fdn.fr shaarli.guiguishow.info AAAA.

DoH avec vérif' : ./remoh.py https://ns1.fdn.fr/dns-query shaarli.guiguishow.info AAAA.

Je note les options --check et --mandatory-level qui testent la conformité d'un serveur DoT / DoH avec les RFC, les bonnes pratiques, etc.

dog

Dépôt git.

La sortie est minimaliste : pas d'info, ni sur TLS, ni sur HTTPS ni sur le DNS lui-même. Codé en Rust, donc cargo télécharge la moitié de l'Internet (317 Mo pour un binaire de 14 Mo). En revanche, a priori, la vérification du cert' x509 est effectuée de base, sans option supplémentaire, en se reposant sur OpenSSL.

DoT avec vérif' : ./dog -S @ns1.fdn.fr shaarli.guiguishow.info AAAA

DoH avec vérif' : /dog -H @https://ns1.fdn.fr/dns-query shaarli.guiguishow.info AAAA

openssl / gnutls

Évidemment, toute la partie TLS peut être testée avec openssl et gnutls.

openssl s_client -connect ns1.fdn.fr:853

gnutls-cli ns1.fdn.fr:853.
Fri Jun 23 23:10:24 2023 - permalink -

- http://shaarli.guiguishow.info/?AfT46Q
Configurer DoT ou DoH au niveau du système (system-wide)
DoT = DNS over TLS (lire).
DoH = DNS over HTTPS (lire).
Explication en vidéo 1. Explication vidéo 2.

Dans les deux cas, on chiffre et on authentifie le trafic DNS entre une machine (stub resolver) / un serveur récursif local (genre Pi-hole) et un serveur récursif sur Internet.

Le but ? Si l'on utilise un serveur DNS récursif (resolver) différent de celui de son FAI afin d'échapper à différents types de filtrage (judiciaire, administratif, technique, etc.), le FAI peut voir et censurer ce trafic DNS. Donc on le chiffre et on l'authentifie (je ne parle pas d'authentifier la donnée, ça c'est le boulot de DNSSEC). (Évidemment, le FAI pourra bloquer l'adresse IP d'un récursif DoT / DoH ou en fonction du SNI… et on passera alors à Encrypted SNI, etc., etc.)

Un stub resolver (la libc de GNU/Linux, par exemple) ne sait pas utiliser DoT / DoH.

Certains logiciels savent les utiliser (Firefox, par ex.), mais alors seuls eux en bénéficient, le trafic DNS des autres logiciels reste en clair.

Comment utiliser DoT ou DoH pour tous les logiciels d'une machine ? En demandant au stub resolver (la libc de GNU/Linux) de les transférer à un intermédiaire qui, d'un côté, cause DNS, et de l'autre, DoT / DoH. Mais lequel ? (Le transfert s'effectue en mettant l'adresse IP de l'intermédiaire, y compris ::1 / 127.0.0.1 dans /etc/resolv.conf.)

DoT

systemd-resolved implémente DoT mais je souhaite éviter cette pieuvre.

Unbound

(Ou tout autre serveur DNS récursif installé localement.)

Config' à mettre dans /etc/unbound/unbound.conf.d/forward.conf (par exemple) :
```
server:
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt # magasin des certificats racines, apt install ca-certificates

forward-zone:
    name: "."
    forward-tls-upstream: yes # activation DoT 
    forward-addr: 2001:910:800::40@853#ns1.fdn.fr # syntaxe : <IP>@<PORT>#<NOM> (le nom sera comparé avec ceux présentés par le serveur dans son certificat x509)
    forward-addr: 2001:910:800::12@853#ns0.fdn.fr
```
Source.

Tout comme tonton Bortz, j'ai d'abord rencontré une erreur dans la vérification du certificat x509 : « error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed ». openssl s_client et gnutls-cli validaient le certificat avec le même magasin de certificats. Puis Unbound est tombé en marche tout seul… Je l'ai réinstallé en supprimant /etc/ounbound et en vérifiant qu'il n'avait rien laissé dans /var, et ça fonctionne encore avec la conf' ci-dessus… Ce n'est pas un problème de Subject / Subjet Alternative Name, ni un problème de certificat intermédiaire non-fourni dans l'échange TLS, ni… J'ai aucune piste sérieuse.

stubby

Dans le cadre de tests de charge simulant un usage courant, je voulais que les requêtes DNS de mon système soient transférées à un récursif DNS sans mise en cache local des réponses. Or, Unbound pratique une telle mise en cache.

Tonton Bortz m'a signalé deux options censées désactiver la mise en cache dans Unbound :
```
rrset-cache-size: 0
msg-cache-size: 0
```
Mais il n'a pas testé et le manuel d'Unbound ne dit pas explicitement que ça désactive toute forme de cache. Donc ça ne me convient pas : un test doit se faire sur des bases saines.

Bortz m'a parlé de Stubby. Il est empaqueté dans Debian GNU/Linux (paquet du même nom).

Dans /etc/stubby/stubby.yml, on s'assure d'avoir :
```
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
```
Et dans « upstream_recursive_servers: », on choisit ou on ajoute ses serveurs. Exemple :
```
upstream_recursive_servers:
  - address_data: 2001:910:800::40
    tls_auth_name: "ns1.fdn.fr"
  - address_data: 2001:910:800::12
    tls_auth_name: "ns0.fdn.fr"
```
C'est du YAML donc gaffe à bien respecter l'indentation.

On peut aussi pratiquer l'épinglage (le pinning) afin de s'assurer que la clé privée du serveur en face ne changera pas en douce, mais pour moi, il s'agit d'une surenchère inutile.

dnsproxy

Je vais en parler pour DoH. Il suffit de remplacer le schéma « https:// » par « tls:// » dans le paramètre « -u » pour transmettre les requêtes DNS via DoT.

DoH

stubby

Stubby n'implémente pas DoH.

dnsproxy

Le projet Adguard (équivalent à uBlock Origin, mais, d'après mes notes de 2016, il était ouvert à la publicité dite acceptable) propose dnsproxy. Source.

Attention : dans les dépôts Debian, c'est un tout autre logiciel qui est empaqueté sous le même nom.

On télécharge. On décompresse le binaire dans /usr/local/sbin.

On l'utilise (il est possible de passer un fichier de configuration YAML avec --config-path) :
```
sudo dnsproxy -l ::1 -l 127.0.0.1 -p 53 -u https://ns1.fdn.fr/dns-query -u https://ns0.fdn.fr/dns-query --all-servers -b [2001:910:800::40]:53 -b [2001:910:800::12]:53
```
Écouter sur localhost, en IPv6 et en IPv4, sur le port 53. Transférer les requêtes DNS en alternance aux serveurs ns1.fdn.fr et ns0.fr. Les noms ns(1|0).fdn.fr seront résolus en clair en utilisant les serveurs 2001:910:800::40 et 2001:910:800::12 (qui sont ns(1|0).fdn.fr).

Pour gérer dnsproxy, j'ai créé l'unit systemd suivante dans /etc/systemd/system/dnsproxy.service :
```
[Unit]
Description=Proxy DoH
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/dnsproxy -l ::1 -l 127.0.0.1 -p 53 -u https://ns1.fdn.fr/dns-query -u https://ns0.fdn.fr/dns-query -b [2001:910:800::40]:53 -b [2001:910:800::12]:53
RemainAfterExit=no
Restart=on-failure
RestartSec=10s

[Install]
WantedBy=multi-user.target
```
Fri Jun 23 23:06:59 2023 - permalink -

- http://shaarli.guiguishow.info/?DX1ENw
Unbound: error: failed to read /var/lib/unbound/root.key - GUIDE

Si Unbound refuse de résoudre des noms (même s'il est configuré pour transférer toutes les requêtes à un autre serveur DNS récursif) en consignant « error: failed to read /var/lib/unbound/root.key » dans syslog, il suffit de lancer sudo unbound-anchor -vv. :-
Fri Jun 23 19:15:22 2023 - permalink -

- https://guide.no/unbound-error-failed-to-read-var-lib-unbound-root-key/
Factorisation de mes journaux et configurations httpd

J'avais configuré mes serveurs web pour écrire des journaux (accès et erreurs) par virtualhost, au sens littéral, donc deux pour l'accès HTTP à un site web, deux autres pour l'accès HTTPS au même site web.

Cette granularité m'a jamais servi en plus de dix ans. Dans mes différents emplois, nous ne faisions pas la distinction, et nous n'avons jamais regretté un manque d'information ou une difficulté à la retrouver.

Même théoriquement, je ne vois pas l'intérêt de journaliser différemment les requêtes en fonction de la couche de chiffrement. Les erreurs liées à la configuration TLS seront consignées dans l'error.log général (nginx) ou dans le premier virtualhost HTTPS avec parfois une indication dans l'error.log général (Apache httpd).

Donc, désormais, hop, deux journaux par site web (access.log, error.log), plus de discrimination en fonction de la présence ou non du chiffrement.

De même, je stockais la configuration de chaque virtualhost dans un fichier différent. Donc, un pour HTTP, un pour HTTPS (pour un même site web). Évidemment, j'incluais les directives de configuration communes depuis un fichier de config' tiers.

Là encore, ça ne m'a jamais servi, ça ne se faisait pas dans les emplois que j'ai occupés, et je n'en vois pas l'intérêt. Dans quel cas voudrais-je désactiver HTTPS sur un site web sans désactiver HTTP (ou inversement) ? Aucune idée. Si je le veux absolument, je pourrais toujours mettre un virtualhost en commentaire. C'est un poil plus chronophage que la suppression d'un lien symbolique (avec ou sans a2dissite), mais ça cette échelle-là, compter sert à rien.

Donc, désormais, hop, un fichier de configuration par site web contenant un virtualhost HTTP et un HTTPS.
Fri Jun 23 16:16:36 2023 - permalink -

- http://shaarli.guiguishow.info/?JxYxcg

Links per page: 20 50 100

◄Older

page 51 / 297

Newer►

Historique

Actuellement

Droit de communication

Un droit français pas conforme à la jurisprudence de la CJUE

À la recherche d'un paradis inexistant

Futur

Concrètement

Qui est concerné ?

Un site web ?

Un serveur emails ? Un serveur de messagerie instantanée ?

Que faut-il collecter et conserver ? Combien de temps ?

De l'ambiguïté historique à la légende urbaine

Journaux techniques

RGPD

Historique et problématique

Cahier des charges

Candidats

Ordre de grandeur

Retenu

Procédure de migration

kdig

dig

homer / remoh

dog

openssl / gnutls

DoT

Unbound

stubby

dnsproxy

DoH

stubby

dnsproxy