Mesures d’atténuation après l’incident d’interception MitM de Hetzner/Linode sur XMPP.ru
(devever.net)- jabber.ru et xmpp.ru ont subi une attaque MitM combinant l’interception du trafic sur le trajet via l’hébergeur et l’émission non autorisée d’un certificat à validation de domaine ; cela a mis en évidence les lacunes de défense des services TLS non web
- La surveillance des logs Certificate Transparency et le sondage de clés publiques TLS peuvent aider à repérer des anomalies, mais une détection complète reste difficile face aux certificats non consignés en CT et aux MitM sélectifs
- Déployer ACME-CAA (RFC 8657) avec DNSSEC permet de n’autoriser l’émission de certificats qu’à un compte précis d’une AC donnée, de sorte qu’utiliser simplement la même AC ne suffit plus pour un attaquant
- Contrairement aux navigateurs web, de nombreux clients non web n’imposent pas les preuves CT (SCT), et les Baseline Requirements du CA/Browser Forum n’imposent pas non plus la journalisation CT de tous les certificats
- Les opérateurs devraient envisager ACME-CAA, DNSSEC, la surveillance CT, les services onion Tor et la dispersion des juridictions ; les utilisateurs devraient considérer le chiffrement de bout en bout et la vérification d’empreintes comme première ligne de défense
Structure essentielle de l’incident
- Les opérateurs de jabber.ru et xmpp.ru ont indiqué que le service avait subi une attaque de type man-in-the-middle
- L’attaque combinait deux éléments
- Hetzner et Linode ont intercepté le trafic à destination des machines du service
- les attaquants ont obtenu sans autorisation un certificat à validation de domaine pour ce service
- Il est jugé probable que l’opération ait été coordonnée par l’État allemand, ou par l’Allemagne avec un ou plusieurs autres États
- D’autres possibilités restent ouvertes
- Hetzner et Linode auraient pu répondre volontairement à une demande d’écoute d’une puissance étrangère, sans contrainte légale
- mais cette hypothèse semble peu probable, car elle ternirait fortement l’image des deux entreprises et pourrait être illégale
Méthodes de détection et leurs limites
- La première méthode consiste à surveiller les logs Certificate Transparency (CT) afin de détecter l’émission de certificats que l’opérateur n’a pas demandés
- certains services le font déjà à votre place
- les outils capables d’identifier précisément les seuls certificats non demandés peuvent encore être améliorés
- La deuxième méthode consiste à se connecter périodiquement au service pour vérifier que la clé publique du serveur TLS correspond à la valeur attendue
-
Ce que la surveillance CT peut manquer
- même un certificat émis par une AC légitime n’est pas forcément consigné dans les logs CT
- les Baseline Requirements du CA/Browser Forum ne font pas encore de la journalisation CT une obligation pour les AC
- les navigateurs web rejettent les certificats qui n’ont pas de preuve cryptographique d’enregistrement CT, ce qui rend la journalisation CT de fait obligatoire
- la plupart des applications clientes non web ne vérifient pas et n’exigent pas qu’un certificat contienne une preuve d’enregistrement CT
- en théorie, un attaquant peut obtenir un certificat non consigné en CT
-
Contournement via un MitM sélectif
- même si l’on tente de détecter un MitM par sondage du service, l’attaquant peut identifier les connexions de détection et ne pas appliquer le MitM à celles-ci
- au minimum, les sondes devraient passer par Tor pour éviter les cas où elles sont faciles à identifier
- les piles TLS peuvent être fingerprintées à partir de signaux comme l’ordre d’énumération des TLV, ce qui peut permettre de distinguer un vrai client XMPP d’un agent de sondage
- au lieu de mettre sur liste noire les sondes connues, l’attaquant peut aussi n’appliquer le MitM qu’au trafic d’une personne précise d’intérêt
- aucune des deux méthodes de détection n’offre une fiabilité totale
Réduction du risque avec ACME-CAA
- Les certificats TLS servent à empêcher les attaques MitM, mais le modèle de validation de domaine par lequel une AC vérifie le contrôle d’un domaine reste lui-même vulnérable au MitM
- Le risque augmente si l’attaquant peut intercepter non pas une partie, mais l’ensemble du trafic vers le site visé
- ACME-CAA(RFC 8657) peut atténuer ce problème dans certaines situations
- L’idée clé est de spécifier via un enregistrement DNS que seul un compte précis d’une AC donnée peut émettre un certificat pour le domaine
- utiliser simplement la même AC ne suffit plus
- il faut aussi l’accès au même compte auprès de cette AC
- chez Let’s Encrypt, cela implique l’accès à la clé privée ACME utilisée pour demander le certificat
- Au vu des modes opératoires connus, cette extension aurait probablement empêché l’attaque si elle avait été déployée
-
Points d’attention lors du déploiement
- pour fonctionner correctement, ACME-CAA nécessite le déploiement de DNSSEC
- sans DNSSEC, les requêtes DNS de l’AC peuvent elles aussi être interceptées
- quiconque contrôle la clé de signature DNSSEC peut contourner cette barrière
- une zone DNS protégée par DNSSEC peut être exploitée sans confier sa clé de signature à un tiers
- dans ce cas, le fournisseur d’hébergement DNS n’a pas le pouvoir de compromettre la zone
- cette approche est considérée comme la meilleure stratégie de déploiement
- un attaquant peut tenter de faire pression sur le registraire du domaine ou sur le registre du TLD pour modifier la clé de signature DNSSEC enregistrée pour le domaine
- une telle opération risque d’être visible
- du fait du cache DNS, il peut être difficile d’empêcher que des sondages répétés détectent ce changement de clé
- l’attaquant peut aussi chercher à faire pression directement sur l’AC pour provoquer une mauvaise émission de certificat
- si une AC tierce enfreint les règles ou se trompe, la vulnérabilité subsiste
- les Baseline Requirements du CA/Browser Forum imposent aux AC de vérifier DNSSEC
- néanmoins, une AC tierce pourrait encore émettre un certificat sans être autorisée dans l’enregistrement CAA
- comme la journalisation CT n’est pas obligatoire, un tel certificat pourrait ne pas être détecté
Le déroulement qu’un attaquant plus compétent pourrait choisir
- Dans cet incident, les attaquants ont laissé expirer le certificat illégal, ce qui montre qu’ils n’étaient pas parfaits
- Avec la généralisation d’un chiffrement bon marché et simple d’usage, on peut s’attendre à des attaques étatiques plus sophistiquées et plus fréquentes
- Un attaquant étatique plus compétent pourrait suivre le schéma suivant
- demander un certificat non consigné en profitant du fait que l’AC n’est pas obligée d’enregistrer le certificat dans les logs CT
- faire pression sur l’hébergeur pour MitM tout le trafic à destination de la machine visée
- distinguer heuristiquement le trafic d’intérêt du trafic de détection à partir de l’empreinte de la pile TLS et de l’IP source
- utiliser le MitM pour convaincre l’AC que l’attaquant est le contrôleur légitime du domaine ciblé
- si le domaine utilise ACME-CAA et DNSSEC, faire pression sur l’hébergeur DNS, le registraire, le registre du TLD ou l’AC
Les failles de l’infrastructure TLS actuelle
-
Manque d’obligation CT côté clients TLS non web
- les navigateurs web exigent que les certificats des AC incluent une preuve cryptographique d’enregistrement dans les logs CT
- la plupart des autres clients TLS n’imposent pas de preuve CT et peuvent donc accepter des certificats non consignés
- il est probable que de nombreux clients XMPP soient aussi dans ce cas
- la vérification CT n’est pas une fonction activée automatiquement simplement parce qu’on lie OpenSSL ; elle doit être implémentée séparément
- les logiciels utilisés pour des communications sensibles devraient envisager la prise en charge obligatoire de CT
-
Absence d’obligation de journalisation CT des certificats
- les Baseline Requirements du CA/Browser Forum, règles sectorielles applicables aux AC, n’imposent pas d’enregistrer les certificats dans les logs CT
- il faudrait aller vers une exigence de journalisation CT pour tous les certificats
- si l’obligation CT était déployée de manière universelle, ce problème pourrait devenir techniquement sans objet
-
Manque de services de surveillance CT
- il faut davantage de services de surveillance CT
- le principal service d’alerte CT actuel est SSLMate's Cert Spotter
- le prix peut être lourd pour des services communautaires ou reposant sur du bénévolat
- la surveillance CT devrait être conçue pour réduire les faux positifs et n’alerter que sur les émissions de certificats anormales ou apparemment non autorisées
-
Manque de transparence DNSSEC
- il n’existe aujourd’hui aucune infrastructure cryptographique déployée permettant de détecter les changements des clés DNSSEC configurées pour un domaine
- si un registraire ou un registre de TLD est compromis ou subit des pressions et change la clé DNSSEC du domaine, la protection ACME-CAA peut être affaiblie
- une solution de transparence rendant publics les changements de clés DNSSEC de zone serait souhaitable
- cette solution n’aurait pas besoin d’enregistrer tous les enregistrements de la zone, seulement les changements de clé de zone, comme les enregistrements DS
Recommandations pour les opérateurs de services
- Pour les services susceptibles d’être ciblés par des attaques étatiques, une approche consistant à appliquer les défenses par ordre de meilleur rapport coût/efficacité est recommandée
-
ACME-CAA et DNSSEC
- déployer ACME-CAA peut rendre plus difficile pour un attaquant d’obtenir de l’AC un certificat pour le domaine en la trompant
- on peut se référer au guide de déploiement ACME-CAA
- les Security Considerations de la RFC contiennent aussi des avertissements importants
- si ACME-CAA est déployé, DNSSEC doit l’être aussi
- si possible, il faut choisir un fournisseur DNSSEC qui ne nécessite pas de lui confier la clé de signature
-
Services proxy et surveillance CT
- utiliser un service comme Cloudflare revient, selon cette analyse, à se placer déjà soi-même dans une situation proche du MitM
- il faut s’abonner à un service de surveillance des logs CT, ou vérifier soi-même régulièrement les logs
- SSLMate's Cert Spotter propose une surveillance automatisée payante
- Cert Spotter est open source, donc un auto-hébergement est possible
- crt.sh permet une recherche manuelle dans les logs CT
-
Dispersion des juridictions et service onion Tor
- il est possible d’envisager une dispersion des juridictions en répartissant registraire, registre TLD, hébergement DNS, AC et hébergeur entre différents pays
- on peut choisir des pays ou des blocs géopolitiques peu susceptibles de coopérer entre eux
- proposer un service onion Tor permet de contourner les infrastructures centralisées comme TLS et les AC
- dans un service onion Tor, la clé publique du service est l’adresse elle-même
- les utilisateurs doivent toutefois obtenir la bonne adresse onion par un canal de confiance
- un tiers peut autrement les rediriger vers une fausse adresse onion
-
Sondage automatique via Tor
- le sondage automatique via Tor n’est pas une solution complète, mais il peut détecter des erreurs maladroites qui surviennent réellement
- Tor réduit le risque que la sonde soit trop facilement identifiable
- pour limiter les possibilités d’empreinte TLS, il vaut mieux que le logiciel client utilise une bibliothèque TLS couramment employée
- si possible, il est encore préférable d’utiliser le vrai client
- dans le cas d’un service XMPP, on peut utiliser un véritable client XMPP
- même en cas de succès, cela ne permet qu’une détection après compromission, et des utilisateurs peuvent déjà avoir subi un préjudice
-
Autres vecteurs d’attaque et hypothèse du pire
- rendre le MitM plus difficile pousse l’attaquant à exploiter d’autres voies, comme la compromission directe de la machine, le vol de clé privée ou l’exfiltration de données sensibles
- un attaquant étatique peut faire pression sur un fournisseur de VM pour obtenir un dump mémoire au niveau de l’hyperviseur
- même un serveur dédié peut être compromis via un accès physique de l’attaquant
- les opérateurs devraient recommander aux utilisateurs le chiffrement de bout en bout et partir du principe que le service peut être compromis malgré tous les efforts
- le chiffrement « de bout en bout » fourni via une application web est considéré ici comme n’offrant pas de protection significative
Mesures nécessaires côté AC, développeurs de clients et utilisateurs
-
CA/Browser Forum
- imposer l’enregistrement CT de tous les certificats, ou soumettre une proposition en ce sens
-
Développeurs de clients applicatifs
- ajouter une fonction imposant la présence de Signed Certificate Timestamps (SCTs) dans les certificats TLS, et l’activer par défaut
- permettre aux utilisateurs de savoir qu’ils bénéficient de cette protection
- tenir compte aussi des discussions sur certaines limites ou variations possibles de l’obligation de preuve CT
- le logiciel devrait être fourni en open source afin de permettre un audit public
- il faut aussi prendre en compte les risques de supply chain et la possibilité que l’éditeur soit lui-même légalement contraint de compromettre le logiciel
- des canaux de distribution non directement contrôlés par le développeur, comme les dépôts de paquets des distributions Linux, peuvent aider à réduire les dégâts
-
Utilisateurs finaux
- il faut supposer que, même si l’opérateur agit de bonne foi, le service peut être compromis malgré ses meilleurs efforts
- si votre vie dépend du fait qu’un service ne soit pas compromis, vous ne devriez pas lui faire confiance
- dans XMPP, il faut utiliser un chiffrement de bout en bout comme OMEMO ou OTR
- il faut toujours vérifier les empreintes de vos correspondants
- il ne faut pas faire de chiffrement de bout en bout dans un logiciel web, ou au minimum il faut partir du principe qu’il est compromis
- si le fournisseur de service propose un service onion Tor, son usage mérite d’être envisagé, mais l’adresse onion doit venir d’une source fiable
-
AC et auteurs de standards
- si une AC ne prend pas en charge ACME-CAA(RFC 8657), elle devrait envisager de l’implémenter
- même une AC qui n’est pas basée sur ACME peut implémenter ACME-CAA
- même si les règles du CA/Browser Forum autorisent l’absence de journalisation CT, une AC peut adopter une politique consistant à enregistrer tous les certificats dans CT
- les auteurs de standards peuvent au minimum réexaminer la possibilité d’une transparence DNSSEC pour les enregistrements DS
Évaluation du confidential computing
- Si l’on craint jusqu’à la compromission des machines par l’hébergeur, les technologies actuelles de confidential computing ne sont pas considérées comme une solution suffisante
- Les déployer peut être préférable à ne rien faire, mais il ne faut pas les tenir pour sûres
- Les technologies actuelles, notamment chez AMD ou Intel, sont jugées dépendantes de clés maîtres constructeur permettant de backdoorer le système
- Un attaquant étatique peut faire pression sur le fournisseur pour obtenir ces clés, et dans ce cas l’approche s’effondre
- Des formes de confidential computing ne reposant pas sur de telles clés maîtres sont peut-être possibles, mais les approches actuelles n’atteignent pas ce niveau
Ressources associées
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: conseils d’atténuation spécifiques à XMPP
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: rapport initial sur l’incident
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 commentaires
Avis sur Hacker News
Le résumé de l’attaque sur https://notes.valdikss.org.ru/jabber.ru-mitm/ est intéressant
L’attaquant a émis plusieurs certificats SSL/TLS pour jabber.ru et xmpp.ru via Let’s Encrypt à partir du 18 avril 2023, et il a été confirmé que, du 21 juillet au 19 octobre, au moins 100 % du trafic client sur le port XMPP STARTTLS 5222 faisait l’objet d’une attaque de l’homme du milieu
Ensuite, après l’échec du renouvellement des certificats, un certificat expiré a été présenté sur le port 5222 de jabber.ru ; l’attaque a cessé juste après le début de l’enquête et des demandes adressées à Hetzner/Linode, mais une écoute passive via un saut de routage supplémentaire subsistait sur certains serveurs Linode
Les serveurs eux-mêmes ne semblent pas avoir été piratés ; les réseaux Hetzner et Linode semblent plutôt avoir été reconfigurés pour cibler les IP du service XMPP
Ni cette page ni les pages liées ici ne mentionnent l’épinglage de certificat ; je ne sais pas si c’est parce que XMPP ne le prend pas en charge, mais s’il le faisait, cela aurait peut-être pu empêcher ce type d’attaque
Malheureusement, jabber.ru utilise un logiciel serveur datant de 2016, et cette ancienne version ne le prend pas en charge
Aujourd’hui, l’épinglage de certificat pose beaucoup de problèmes, car les certificats ont une durée de vie courte et sont renouvelés fréquemment. Si l’on demande chaque mois aux utilisateurs d’accepter un nouveau certificat, ils finiront aussi par cliquer machinalement sur « Accept » pour le certificat d’un attaquant
Le channel binding fonctionne indépendamment du certificat et garantit que le flux TLS se termine bien auprès de l’entité attendue
Il est étrange de se concentrer sur l’absence de prise en charge CT/SCT dans les clients XMPP. Cette attaque utilisait un certificat valide émis par Let’s Encrypt et inscrit dans les journaux CT, donc CT/SCT ne l’aurait pas détectée
Des enregistrements CAA stricts auraient pu permettre à la vérification SCT de repérer un scénario théorique d’émission par une autre autorité de certification, mais en pratique il n’y avait pas de CAA, et le channel binding est plus respectueux de la vie privée tout en dépendant moins de tiers
Autrement dit, il pouvait soit répondre au protocole ACME depuis le HTTP hébergé, soit écrire des enregistrements DNS TXT ; cela semble indiquer que la victime avait déjà perdu le contrôle du serveur de processus ou des serveurs de noms
Je comprends l’épinglage de certificat comme une méthode possible uniquement lorsque l’on contrôle le client, en y intégrant directement les certificats autorisés afin de contourner toute l’infrastructure de clés publiques du Web
Dans un contexte où des clients génériques se connectent, il n’y a aucun moyen de savoir quels certificats doivent être autorisés, et c’est précisément à cela que sert l’infrastructure de clés publiques du Web
Bien sûr, même si l’on fournit son propre client, le problème ne fait que remonter d’un niveau : l’emplacement depuis lequel les clients téléchargent le client personnalisé peut être compromis et distribuer un client malveillant
La défense la plus évidente manque dans cette liste. Il faut activer SCRAM-xxxxx-PLUS comme méthode d’authentification et, si possible, l’imposer
L’idée des variantes PLUS est simple mais efficace. Au lieu de valider uniquement avec le sel, elles lient la validation à une connexion TLS donnée, de sorte que l’authentification n’est valable que pour une seule connexion TLS
C’est aussi ce qu’on appelle le channel binding
Je me demande qui sont les utilisateurs finaux de xmpp.ru et jabber.ru. Est-ce qu’il s’agit d’intercepter du trafic entre militaires ou espions russes ? Je n’aime pas la surveillance de masse, mais je ne comprends pas pourquoi ils ont ciblé précisément des domaines russes.
Le scénario le plus plausible serait plutôt de chercher à attraper des carders ou des opérateurs de botnets. Jabber/XMPP reste assez populaire dans ces milieux côté russe, et dans des articles comme ceux de Krebs on Security, on voit souvent des captures d’écran ou des logs mentionnant divers serveurs comme @exploit.in, @jabber.ru, etc.
Cela dit, quelle que soit l’intention, la surveillance de masse est globalement répugnante.
Je ne sais pas quelle est exactement la proportion d’usages criminels et non criminels sur ces deux serveurs, mais comme avec Tor, où des contenus manifestement illégaux coexistent avec des usages légitimes, il doit aussi y avoir ici pas mal de conversations tout à fait ordinaires.
Donc, à la base, je ne suis pas vraiment favorable à une atteinte à la vie privée pour surveiller des cybercriminels arbitraires situés dans des pays hors juridiction, où l’extradition est de toute façon difficile.
Je comprends que Hetzner n’avait sans doute pas d’autre choix que de coopérer s’il ne voulait pas finir comme Lavabit, mais en tant que personne qui le recommandait souvent, je serais assez déçu si Hetzner était au courant de l’attaque de l’homme du milieu et l’avait autorisée ou aidée. À part ça, je considère que c’est l’un des meilleurs hébergeurs.
Ils sont transparents, leur disponibilité, leur fiabilité et leur support sont meilleurs que chez la plupart des fournisseurs cloud, et leurs tarifs restent raisonnables. Leurs efforts pour faire de la conception écologique un choix aussi économiquement intelligent sont aussi louables.
Dans « réduire > réutiliser > recycler », la réduction se voit dans leur conception KISS. Par exemple, des toits hauts et inclinés qui facilitent l’évacuation naturelle de la chaleur[2], des châssis serveur qui ressemblent davantage à un support structurel minimal et à un carénage de flux d’air qu’à de vrais châssis, ou encore une conception de carte mère standard avec le socket tourné de 90 degrés pour refroidir les VRM, le CPU et la mémoire avec un seul ventilateur[3].
La « réutilisation » apparaît dans leurs enchères de serveurs. Au lieu de jeter l’ancien matériel, ils le louent via un système d’enchères à la hollandaise, évitant à la fois le coût du nouveau matériel et le coût environnemental d’une fabrication neuve à chaque génération.
J’aimerais les utiliser davantage s’ils proposaient aussi des serveurs dédiés hors d’Europe.
[1] : Le terme « légal » lui-même est difficile à définir. Le journaliste d’un pays est « agent étranger » pour un autre, et le « combattant de la liberté » d’un pays est le « terroriste » d’un autre.
[2] : Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3] : Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
L’article dit que « CT est optionnel », mais au final, n’est-ce pas au client XMPP d’en décider ? Maintenant que les navigateurs l’exigent de fait, je me demande ce qui empêcherait les clients XMPP d’exiger CT.
Je ne sais pas non plus à quel magasin de confiance on se fie pour émettre des certificats qui ne fonctionneraient pas dans les navigateurs.
Le problème est que le comportement exigeant CT n’est activé par défaut dans quasiment aucune bibliothèque TLS. Les développeurs de clients XMPP doivent donc l’activer explicitement, et à l’heure actuelle je pense que la plupart, voire tous, ne le font pas. Bien sûr, cela peut changer.
Cet article propose d’utiliser OTR avec XMPP, mais malheureusement OTRv3 utilise une cryptographie vieillissante et OTRv4 n’est pas encore finalisé.
https://dustri.org/b/time-to-sunset-otr.html
À la question « que ferait un attaquant parfait ? », s’il a un accès physique à l’ordinateur, il me semble qu’il existe des moyens d’exfiltrer des données depuis l’appareil par une forme d’interception de bus.
Cela avait du sens à l’époque du RTC et du haut débit lent à forte latence, mais aujourd’hui beaucoup d’endroits disposent de fibre rapide et d’une faible latence jusqu’aux points de peering.
Plus on s’éloigne des datacenters et du cloud, plus l’infrastructure Internet devrait fonctionner comme elle a été conçue à l’origine, et moins elle doit passer par des points d’agrégation centralisés qui sont aujourd’hui de graves points de défaillance et de gros risques de sécurité.
Je me suis renseigné sur CAA, mais mon fournisseur DNS actuel ne prend pas en charge ce type d’enregistrement. Y a-t-il une raison pour laquelle il fallait un nouveau type plutôt qu’un enregistrement TXT, plus courant ?
Si ce n’est pas possible, il faut demander la prise en charge. Les enregistrements CAA sont de plus en plus utilisés, donc un service qui ne les prend pas en charge aujourd’hui n’est pas vraiment un bon service.
Je ne connais pas les discussions de conception autour de CAA, mais il est très probable qu’elles aient eu lieu sur la liste de diffusion IETF correspondante.
Les fournisseurs DNS devraient prendre en charge différents types de RR, et les propriétaires de domaines devraient voter avec leurs enregistrements NS.
Une liste de fournisseurs DNS prenant en charge CAA se trouve sur https://github.com/StackExchange/dnscontrol/blob/master/docu....
Cela vaut la peine de tester si l’on peut mettre en place un serveur primaire caché et n’utiliser le fournisseur que comme serveur secondaire. C’est comme ça que j’ai contourné cette limite chez Linode.
L’option consistant à exploiter sa propre autorité de certification et à choisir soigneusement les certificats racine a été oubliée.
Le fournisseur pouvant accéder à l’hôte, il peut inspecter ce qui se passe depuis l’extérieur sans que l’utilisateur ne s’en rende compte
Par exemple, il faudrait implanter un module noyau capable de survivre à une mise à niveau du noyau et de se dissimuler de manière très avancée. L’article aborde aussi l’analyse de dumps de mémoire brute
Quelle serait la solution technique fondamentale face à ce type d’attaque menée par un État ou un acteur puissant comparable ? Existe-t-il un moyen de satisfaire ce rêve de geek : un logiciel librement distribuable que personne, hormis son auteur, ne puisse censurer, interférer avec ou modifier ?
Un système P2P correctement conçu au-dessus de l’infrastructure Internet actuelle suffirait-il comme réponse, ou faudrait-il déployer en plus un Internet maillé mondial sans fil à faible bande passante ?
J’espère que Freenet 2023 évoluera vers une expérience développeur sans friction pour les applications P2P