Remplacement de la clé KSK de la zone racine : Êtes-vous prêts ? Voici quelques tips pour bien vérifier que votre résolveur connait KSK-2017 ▻https://www.afnic.fr/fr/ressources/blog/remplacement-de-la-cle-ksk-de-la-zone-racine-etes-vous-prets.html
Replacement of the KSK of the root zone : Are you ready ? Here are a few tips to help you check your resolver is familiar with KSK-2017 ▻https://www.afnic.fr/en/resources/blog/replacement-of-the-ksk-of-the-root-zone-are-you-ready.html
« Selon la légende, 14 personnes contrôlent Internet, à l’aide de 7 clés secrètes. Dans ce second épisode Goat In The Shell, nous nous pencherons sur ces fameux maîtres d’Internet… »
▻https://www.youtube.com/watch?v=uxCeG-XpLdU
[Bonnes explications dans la seconde partie.]
#humour #darknet #hackers #DNSSEC #DNS #pipeautage_médiatique
Le renseignement militaire et les « petits pédés » de 4chan
►http://www.slate.fr/story/140342/le-renseignement-militaire-4chan
Qualifié de « poubelle du web », le forum 4chan est également connu pour être le plus prolixe générateur de mèmes mais aussi pour ses « fake news ». L’une d’entre elles, délirante et conspirationniste, a pourtant été reprise, au premier degré, par le service de renseignement militaire français en charge du contre-espionnage et l’un des experts « cyber » de la gendarmerie nationale.
La revue de la gendarmerie nationale omettait de même de préciser que ledit blogueur définissait aussi l’informatique quantique comme « quelque chose dont le nom est « falcighol dérivation polymère » (resic), ou encore qu’il existe, et au-delà dudit « Marianas Web », trois autres « couches (6, 7, 8) : les niveaux 6 et 7 ne sont que des conneries. Le huitième, et le dernier niveau, est celui qui intéresse la plupart des gens », et pour cause :
« Le niveau 8 du web est censé contrôler l’ensemble d’Internet. C’est apparemment une anomalie découverte dans les années 2000. Il est complètement insensible, mais envoi des signaux directement dans les ordinateurs du monde entier, ce qui lui permet de contrôler Internet, mais cela dépend du hasard. Personne ne semble avoir le contrôle. D’après ce qu’on dit, une organisation / gouvernement secret détient le contrôle sur ce niveau, mais on ne sait pas. Apparemment, vous devez résoudre un simple puzzle… verrouillage des fonctions de niveau 17 niveau quantique TR001. Il s’agit essentiellement de l’informatique quantique le plus avancé, totalement impossible à résoudre avec nos ordinateurs. Vous avez besoin d’une technologie profonde que personne ne possède. »
RFC 8198 : Aggressive Use of DNSSEC-Validated Cache
Lorqu’un client #DNS interroge un résolveur, celui-ci peut répondre très vite si l’information demandée est dans sa mémoire (son « cache ») mais cela peut être beaucoup plus lent s’il faut aller demander aux serveurs faisant autorité. Il est donc essentiel, pour les performances du DNS, d’utiliser le cache le plus possible. Traditionnellement, le résolveur n’utilisait le cache que si la question posée par le client avait une réponse exacte dans le cache. Mais l’arrivée de #DNSSEC autorise un usage plus énergique et plus efficace du cache : ce nouveau #RFC permet aux résolveurs de synthétiser des réponses à partir des informations DNSSEC.
RFC 8063 : Key Relay Mapping for the Extensible Provisioning Protocol
Un des problèmes pratiques que pose #DNSSEC est le changement d’hébergeur #DNS. Si on sous-traite sa gestion des clés cryptographiques, et ses signatures à un tiers, que faire lors du changement de prestataire, pour ne pas casser la chaîne de confiance DNSSEC ? On ne peut évidemment pas demander à l’ancien hébergeur de transmettre la clé privée au nouveau ! Même pour les données non confidentielles, comme la clé publique, la transmission est difficile car les deux hébergeurs n’ont pas de canal de transmission sécurisé commun. Ce nouveau RFC propose d’utiliser comme canal sécurisé le registre de la zone parente et, plus concrètement, de définir une extension au protocole #EPP, qui permet un mécanisme de « messagerie » électronique sécurisée, afin de l’utiliser entre deux clients du même registre.
DNS issues? Who Ya Gonna Call? ZoneMaster! A blog article by Sandoche Balakrichenan from Afnic for CENTR
Read now and share ! ▻https://www.centr.org/news/news/who-ya-gonna-call-for-dns-issues.html
#DNS #ZoneMaster #Afnic #DNSSEC
RFC 7958 : DNSSEC Trust Anchor Publication for the Root Zone
Le mécanisme d’authentification des informations DNS nommé #DNSSEC repose sur la même structure arborescente que le #DNS : une zone publie un lien sécurisé vers les clés de ses sous-zones. Un résolveur DNS validant n’a donc besoin, dans la plupart des cas, que d’une seule clé publique, celle de la racine. Elle lui servira à vérifier les clés des TLD, qui serviront à valider les clés des domaines de deuxième niveau et ainsi de suite. Reste donc à configurer la clé de la racine dans le résolveur : c’est évidemment crucial, puisque toute la sécurité du système en dépend. Si un résolveur est configuré avec une clé fausse pour la racine, toute la validation DNSSEC est menacée. Comment est-ce que l’#ICANN, qui gère la clé principale de la racine, publie cette clé cruciale ? Six ans après la signature de la racine du DNS, c’est enfin documenté, dans ce #RFC.
RFC 7929 : DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
Un problème classique du système de cryptographie #OpenPGP est de vérifier les clés publiques des correspondants. Les trouver, c’est relativement facile : le correspondant pense à vous les envoyer ou bien on se sert tout simplement d’un serveur de clés. Mais ceux-ci ne garantissent rien sur la clé. N’importe qui peut créer une clé marquée flotus@whitehouse.gov et la mettre sur les serveurs de clé, même si cette clé n’a rien à voir avec la Maison-Blanche. Avant la solution de ce nouveau #RFC, il n’existait pas de mécanisme sécurisé pour récupérer une clé publique PGP. Que propose ce RFC ? De mettre les clés dans le #DNS (nouveau type d’enregistrement OPENPGPKEY), dans le domaine de la partie droite de l’adresse de courrier, sécurisée par #DNSSEC. En gros, il s’agit de faire pour le courrier et PGP ce que fait déjà #DANE pour le Web/TLS.
Avant la solution de ce nouveau #RFC, il n’existait pas de mécanisme sécurisé pour récupérer une clé publique PGP.
/me s’étouffe dans son verre d’eau
PKA ?
DNSSEC as DDoS amplification attack vector
Here is a report that explains how DNSSEC can be subverted as an amplifier in DDoS attacks.
• Average DNSSEC amplification factor : 28.9 x
• Average response to a 80 byte “ANY” query : 2313 bytes
• Largest amplification response : 17377 bytes
▻https://ns-cdn.neustar.biz/creative_services/biz/neustar/www/resources/whitepapers/it-security/dns/neustar-dnssec-report.pdf
We ran DNS queries from four separate and independent open recursive servers to look for DNSSEC name servers that responded to queries using the DNS command “ANY,” which is a favorite malicious query used by hackers.
[...]
Of the 1,349 domains that we examined, 1,084 were signed with DNSSEC and responded to the “ANY” query.
Which means: 80% of the domains in this one community could be repurposed as a DDoS amplifier and
used maliciously.
[...]
For organizations that use and rely on DNSSEC, Neustar
recommends ensuring that your DNS provider does not
respond to the “ANY” queries or has some mechanism in
place to identify and stop misuse.
L’observatoire de la résilience de l’Internet français publie son rapport 2015 ▻https://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/9991/show/l-observatoire-de-la-resilience-de-l-internet-francais-publie-son-rapport-2015
#ANSSI #AFNIC #INTERNET #RESILIENCE #WEB #TLS #BGP #SMTP #DNSSEC #IPv6 #HTTPS #RPKI #DDoS
La newsletter Afnic de janvier est en ligne ! Consultez la ici ▻http://afnic-media.fr/newsletter/20160119.html
Pour vous inscrire ►https://www.afnic.fr/fr/ressources/newsletter-afnic-36.html
Afnic newsletter for January is out! Read it here ▻http://www.afnic-media.fr/newsletter/20160119-english.html
Subscribe directly here ▻https://www.afnic.fr/en/resources/afnic-newsletter-43.html
[Blog Afnic] IPv6 et DNSSEC ont 20 et 19 ans. Même combat et mêmes défis !? par Mohsen Souissi ▻https://www.afnic.fr/fr/ressources/blog/ipv6-et-dnssec-ont-20-et-19-ans-meme-combat-et-memes-defis.html
[Afnic blog] IPv6 and DNSSEC are respectively 20 and 19 years old. Same fight and challenges? by Mohsen Souissi ▻https://www.afnic.fr/en/resources/blog/ipv6-and-dnssec-are-respectively-20-and-19-years-old-same-fight-and-challenges
NTP - Network Time Protocol - can be abused for attacks on HTTPS, DNSSEC, and Bitcoin.
Researchers at University of Boston describe how unencrypted NTP traffic can be intercepted and then used to change the time of clients. For example, the clock can be turned back to a point where the host would accept a fraudulent digital certificate that has been revoked.
Or by advancing the time on a DNS resolver the DNSSEC validation can be made to fail.
The researches also give advice on how to protect yourself against these various attacks.
Attacking the Network Time Protocol
Abstract—We explore the risk that network attackers can
exploit unauthenticated Network Time Protocol (NTP) traffic to
alter the time on client systems. We first discuss how an onpath
attacker, that hijacks traffic to an NTP server, can quickly
shift time on the server’s clients. Then, we present a extremely
low-rate (single packet) denial-of-service attack that an off-path
attacker, located anywhere on the network, can use to disable NTP
clock synchronization on a client. Next, we show how an off-path
attacker can exploit IPv4 packet fragmentation to dramatically
shift time on a client. We discuss the implications on these
attacks on other core Internet protocols, quantify their attack
surface using Internet measurements, and suggest a few simple
countermeasures that can improve the security of NTP.
▻http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf
backup: ▻http://docdro.id/Cf0QqBD
RFC 7583 : DNSSEC Key Rollover Timing Considerations
Contrairement au #DNS classique, le système de sécurité #DNSSEC est très dynamique : il faut changer les signatures régulièrement et il est souvent recommandé de remplacer (changer) les clés. Compte-tenu du fait que le DNS n’est pas synchrone (les changements n’apparaissent pas instantanément partout dans l’Internet), ce changement, ce remplacement (rollover, dans la langue d’Alan Turing) est une opération délicate et qui nécessite le strict respect d’un certain nombre de durées. Ce #RFC donne des conseils sur la temporalité des opérations DNSSEC.
La vaste blague Images d’art — Medium
▻https://medium.com/@symac/la-vaste-blague-images-d-art-644e83124136
Et commençons par l’élément le plus critique, comment peut-on, en 2015, espérer faire rayonner la France en proposant des images de 768 pixels par 650 ? Pour donner un ordre d’idée et sans entrer dans des considérations techniques sur ce qu’est une résolution d’image, cela correspond à un demi écran du dernier iPhone ! Et très concrètement, cela s’illustre par la comparaison suivante pour La liberté guidant le peuple d’Eugène Delacroix proposée par Gallorum sur twitter. Ce rayonnement international est un peu flou…
On peut aussi noter que le domaine est mal signé avec #DNSSEC et donc inaccessible depuis les gens qui utiisent un résolveur DNS validant (Free, Google). ▻https://zonemaster.net/test/40381 ▻http://dnsviz.net/d/images-art.fr/ViTnig/dnssec
Ce problème est désormais réparé. Leçons en ▻http://www.bortzmeyer.org/dnssec-qui-est-coupable.html
à comparer aux musées nationaux norvégiens ▻http://seenthis.net/messages/421876
RFC 7646 : Definition and Use of DNSSEC Negative Trust Anchors
Comme toutes les techniques de sécurité, #DNSSEC, qui vise à assurer l’autenticité des réponses #DNS, a ses inconvénients. De même qu’une serrure fermée à clé peut avoir pour conséquence de vous empêcher de rentrer chez vous, si vous avez oublié la clé, de même DNSSEC peut empêcher d’accéder à un domaine si le gérant de la zone a commis une erreur technique. Autant le DNS d’avant était très tolérant (il fallait vraiment insister pour « planter » une zone), autant DNSSEC est délicat : les erreurs ne pardonnent pas, puisque le but de DNSSEC est justement d’empêcher l’accès aux données si elles sont suspectes. Mais les outils et les compétences pour gérer DNSSEC ne sont pas encore parfaitement au point et ne sont pas utilisés partout. Il y a donc de temps en temps des plantages, qui ont pour conséquence la panne d’une zone DNS entière. Face à ce problème, les gérants des résolveurs DNS validants aimeraient bien temporairent suspendre les vérifications, après avoir vérifié qu’il s’agissait bien d’un problème et pas d’une attaque. Cette suspension temporaire et limitée se nomme #NTA pour Negative Trust Anchor et est décrite dans ce #RFC.
Après un lecture rapide, je comprends que les arguments principaux sont :
– la technologie est vieille
– la sécurité n’augmente avec DNSSEC que dans peu de cas
– personne n’utilise DNSSEC alors que ça fait des années que c’est disponible
– c’est trop compliqué à implémenter et utiliser
– ça revient à transférer la confiance des autorités de certification PKI (privées pour la plupart) aux gouvernements qui gèrent les noms de domaine de primer niveau (et ça serait mal selon l’auteur).
J’ai bien lu ? Et qu’en penses-tu, ce sont des arguments valables pour conseiller de ne pas implémenter ni utiliser DNSSEC ?
Qu’en pense @stephane ?
Stéphane il en pense que « réfuter les conneries prend bien plus de temps que de les produire » et qu’il n’a pas de temps à perdre avec un travail trollesque d’aussi mauvaise foi.
Discussion sur #HN :
▻https://news.ycombinator.com/item?id=8894902
J’avoue que je pensais très fort à @stephane en postant ça...
ISOC has some ideas to keep the beginning hackers active on weekends: “Do you have some vacation time during Christmas and New Year’s Day? Are you looking for a weekend project to try out something new? Maybe improve your home network? Or learn a new skill for 2015? If so, why not check out our list of weekend projects [...]”
▻http://www.internetsociety.org/deploy360/blog/category/weekend-projects
Faut-il changer la clé #DNSSEC de la racine ?
Voici le genre de question qui ne va pas angoisser le célèbre M. Michu, mais que se posent sérieusement des tas de techniciens de l’Internet. Cette question a suscité la création récente d’une liste de diffusion très animée, et fera l’objet d’une réunion à la rencontre ICANN de Los Angeles en octobre prochain.
RFC 7344 : Automating DNSSEC Delegation Trust Maintenance
Un des obstacles à un plus large déploiement de #DNSSEC est la nécessité de faire mettre, par le gestionnaire de la zone parente, un enregistrement faisant le lien avec la clé de signature de la zone fille. Cet enregistrement, nommé DS (pour Delegation Signer) est indispensable pour établir la chaîne de confiance qui va de la racine du DNS à la zone qu’on veut sécuriser. Mais, autant signer sa zone ne nécessite que des actions locales, qu’on peut faire tout seul, mettre cet enregistrement DS dans la zone parente nécessite une interaction avec une autre organisation et d’autres personnes, ce qui est souvent compliqué et réalisé d’une manière non standardisée. Ce nouveau #RFC propose une méthode complètement automatique, où la zone fille publie les enregistrements de clé localement, et où la zone parente va les chercher (via le DNS) et les recopier.
Document simple et concret, en français, pour les administrateurs système qui veulent utiliser #DNSSEC (validation et signature) mais sont un peu perdus.
C’est trop débile pour être ignoré : la presse poubelle se préoccupe de la sécurité d’Internet, ou plutôt du risque qu’« un virus contamine le Web ».
▻http://www.parismatch.com/Actu/Environnement-et-sciences/Ils-detiennent-les-cles-du-reseau-564381
Je pense qu’il y avait peu de liens vers Paris Match sur SeenThis :-)
tous les liens vers ton journal préféré ;-) ▻http://seenthis.net/sites/20803
@James Dont beaucoup par @mona / @beautefatale qui semble apprécier ParisMatch encore plus que moi :-)
@robin N’est-ce pas ? Finkie a bien raison, on trouve des conneries sur le Web, il faudrait le réguler et que seuls les pros aient le droit d’écrire.
@stephane Je viens de me rendre compte que pour qu’en plus il y a une belle faute dans le titre : pas d’accent à « réseau ». Top.
Franchement, je trouve souvent plein de choses intéressantes dans la revue de presse en ligne de Paris Match
Les mêmes nimportequoi ont ensuite été repris dans GQ ▻http://www.gqmagazine.fr/pop-culture/gq-enquete/articles/qui-detient-vraiment-les-cles-dinternet-/15382 Ma réponse ▻http://www.bortzmeyer.org/les-quatorze-qui-controlent-tout.html
