La sécurité de tout système dépend à la fois de la sécurisation de ses différentes composantes et des interactions entre celles-ci. Ce constat est aussi valable pour le DNS (Domain Name System), maillon clé du fonctionnement de l’Internet, car la quasi-totalité des services en ligne utilise des noms de domaine à un moment ou à un autre.
préparation à la certification LPIC2 version 3.5 en français
Chapitre 8 : Topic 208 : Services Web
Configuration de Apache2 et Squid
Partie 3 : sécurisation d'un serveur web avec ssl
Topic 208.2 partie 2
Mise en place de l'https sur Apache2 via mod_ssl et openssl.
Supports créés par Noël Macé sous Licence Creative Commons BY-NC-SA.
Diapositives du Webinar SSL :
INTRODUCTION
Qu’est-ce que le SSL / TLS ?
L’intérêt du SSL
Rapide historique
Déroulement d’une connexion TLS
PARTIE 1
Quel est le rôle d’un certificat SSL ?
Les niveaux de validation
Les options d’un certificat SSL : Wildcard et SAN
Le processus de commande
La chaîne de certification
Algorithmes SSL : chiffrement & authentification
Étude de cas : exemples typiques
PARTIE 2
Modes de déploiement
TLS et épuisement des adresses IPv4
HAProxy et le SNI
Impacts du TLS
SSL offloading
SEO
Sécurité du protocole SSL
Les défis les plus fréquents dans l’implémentation de HTTPSSemrush
Selon Google, HTTPS devient de plus en plus important, il est déjà considéré comme un des facteur de ranking ou “small ranking factor”. Donc, maintenant il n’est plus possible de ne pas prendre en compte HTTPS. Les pages sécurisées influencent positivement l’expérience utilisateur et rendent votre site plus crédible pour les internautes et les moteurs de recherche. Nous avons récemment réalisé une étude intéressante sur les erreurs les plus communes d’implémentation de HTTPS. Pendant cette conférence, Natalia vous fera découvrir les résultats de cette recherche exclusive et partagera avec vous des recommandations pour corriger les erreurs HTTPS.
---------------
The most common HTTPS implementation issues
According to Google, HTTPS is becoming more and more important, it is already considered as a “small ranking factor”. So now, it is no longer possible to ignore HTTPS. Secure pages positively influence user experience and make your website more credible for users and search engines. Recently SEMrush has carried out an interesting study on the most common HTTPS implementation mistakes. During this conference, Natalia presents the results of this exclusive research and shares tips on how to fix these problems.
préparation à la certification LPIC2 version 3.5 en français
Chapitre 8 : Topic 208 : Services Web
Configuration de Apache2 et Squid
Partie 3 : sécurisation d'un serveur web avec ssl
Topic 208.2 partie 2
Mise en place de l'https sur Apache2 via mod_ssl et openssl.
Supports créés par Noël Macé sous Licence Creative Commons BY-NC-SA.
Diapositives du Webinar SSL :
INTRODUCTION
Qu’est-ce que le SSL / TLS ?
L’intérêt du SSL
Rapide historique
Déroulement d’une connexion TLS
PARTIE 1
Quel est le rôle d’un certificat SSL ?
Les niveaux de validation
Les options d’un certificat SSL : Wildcard et SAN
Le processus de commande
La chaîne de certification
Algorithmes SSL : chiffrement & authentification
Étude de cas : exemples typiques
PARTIE 2
Modes de déploiement
TLS et épuisement des adresses IPv4
HAProxy et le SNI
Impacts du TLS
SSL offloading
SEO
Sécurité du protocole SSL
Les défis les plus fréquents dans l’implémentation de HTTPSSemrush
Selon Google, HTTPS devient de plus en plus important, il est déjà considéré comme un des facteur de ranking ou “small ranking factor”. Donc, maintenant il n’est plus possible de ne pas prendre en compte HTTPS. Les pages sécurisées influencent positivement l’expérience utilisateur et rendent votre site plus crédible pour les internautes et les moteurs de recherche. Nous avons récemment réalisé une étude intéressante sur les erreurs les plus communes d’implémentation de HTTPS. Pendant cette conférence, Natalia vous fera découvrir les résultats de cette recherche exclusive et partagera avec vous des recommandations pour corriger les erreurs HTTPS.
---------------
The most common HTTPS implementation issues
According to Google, HTTPS is becoming more and more important, it is already considered as a “small ranking factor”. So now, it is no longer possible to ignore HTTPS. Secure pages positively influence user experience and make your website more credible for users and search engines. Recently SEMrush has carried out an interesting study on the most common HTTPS implementation mistakes. During this conference, Natalia presents the results of this exclusive research and shares tips on how to fix these problems.
Description du protocole SSL/TLS. Présentation du protocole et de ses terminologies. Découverte de divers méchanismes de chiffrement. Ensuite le document abordera la notion de certificat: les différents types de certificats, leur génération et installation. Enfin un bref aperçu sur les diffrérences qui existent entre le TLS et le SSL
Comprendre la sécurité web - Présentation effectuée à "Ubuntu Paris 1610" par Christophe Villeneuve.
La sécurité est une affaire de tous. Il est indispensable d'en prendre comprendre les concepts et de se protéger
Le déni de service existe depuis des années. Cependant, cette attaque retrouve un nouveau souffle avec son évolution, le DDoS (Distributed Denial of Service). Plus difficile à contrer, cette attaque cause également beaucoup plus de dégâts.
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...Afnic
Voir la vidéo de cette présentation sur http://www.youtube.com/watch?v=HW1gkg8D7s8
Stéphane Bortzmeyer (Ingénieur R&D à l'Afnic) présente son tutoriel "Tout réseau a besoin d'identificateurs. Lesquels choisir ?" lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
Au sujet de ce tutoriel, Stéphane Bortzmeyer indique :
Dans tout réseau, il faut identifier les objets (machines, humains, programmes en cours
d'exécution, fichiers, etc.). Cela a toujours mené à des très longs débats. Par exemple, dans les cours universitaires classiques, mais aussi dans des normes techniques comme le RFC 791, on trouve de savantes définitions des noms, des adresses, des routes, définitions que je trouve imparfaites et qui, surtout, ne collent pas du tout avec la réalité de l'Internet. On entend aussi souvent des erreurs comme de prétendre qu'un URL indique où se trouve une ressource (rien n'est plus faux). Il vaut donc mieux adopter une autre perspective, celle des propriétés.
Plutôt que d'essayer de définir la différence entre un nom et une adresse, ou de reprendre le débat philosophique entre URL et URN, attachons-nous à déterminer les propriétés des différents types d'identificateurs et voyons lesquelles sont importantes pour chaque cas d'usage.
La discussion est d'autant plus importante que, si certains identificateurs n'ont qu'on rôle technique et sont largement cachés à l'utilisateur (pensons aux adresses MAC par exemple), d'autres sont un vecteur d'identité.
Sur l'Internet, vous n'êtes pas Jean Dupont, né le 3 octobre 1978 à Bois-le-Roi, vous êtes "jdupont43" sur Twitter, vous êtes jean.dupont.fr, vous êtes jeannot@gmail.com, et
ces identificateurs, qui apparaissent à tous, sont votre identité. La première partie de l'exposé portera donc sur ces vecteurs d'identité. Quel est notre futur ?
Quelle identité sera la principale ? Aurons-nous une pluralité d'identités ou bien Facebook sera t-il le seul fournisseur d'identité (comme c'est le cas aujourd'hui pour certaines entreprises qui mettent leur identifiant Facebook sur leurs cartes de visite et publicités) ? Les identités seront-elles basées sur un système centralisé comme Facebook, sur un système arborescent comme les noms de domaine (avec, par exemple, la technologie WebFinger) ou sur autre chose ?
La deuxième partie sera consacrée aux identificateurs fondés sur le contenu. Popularisés par les magnets (utilisés notamment par BitTorrent), normalisés sous la forme des URI "ni", quelle place prendront-ils dans le bestiaire des identificateurs ? Des systèmes de résolution efficaces seront-ils mis en place pour ces identificateurs ?
Identification, nommage et DNS dans l’Internet du futur: "Toile de fond techn...Afnic
Identification, nommage et DNS dans l’Internet du futur : éléments issus de l’enquête de « toile de fond technologique » AFNIC par Mohsen Souissi lors du Séminaire du Conseil Scientifique AFNIC du 10 juin 2011
Description du protocole SSL/TLS. Présentation du protocole et de ses terminologies. Découverte de divers méchanismes de chiffrement. Ensuite le document abordera la notion de certificat: les différents types de certificats, leur génération et installation. Enfin un bref aperçu sur les diffrérences qui existent entre le TLS et le SSL
Comprendre la sécurité web - Présentation effectuée à "Ubuntu Paris 1610" par Christophe Villeneuve.
La sécurité est une affaire de tous. Il est indispensable d'en prendre comprendre les concepts et de se protéger
Le déni de service existe depuis des années. Cependant, cette attaque retrouve un nouveau souffle avec son évolution, le DDoS (Distributed Denial of Service). Plus difficile à contrer, cette attaque cause également beaucoup plus de dégâts.
JCSA2013 01 Tutoriel Stéphane Bortzmeyer "Tout réseau a besoin d'identificate...Afnic
Voir la vidéo de cette présentation sur http://www.youtube.com/watch?v=HW1gkg8D7s8
Stéphane Bortzmeyer (Ingénieur R&D à l'Afnic) présente son tutoriel "Tout réseau a besoin d'identificateurs. Lesquels choisir ?" lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
Au sujet de ce tutoriel, Stéphane Bortzmeyer indique :
Dans tout réseau, il faut identifier les objets (machines, humains, programmes en cours
d'exécution, fichiers, etc.). Cela a toujours mené à des très longs débats. Par exemple, dans les cours universitaires classiques, mais aussi dans des normes techniques comme le RFC 791, on trouve de savantes définitions des noms, des adresses, des routes, définitions que je trouve imparfaites et qui, surtout, ne collent pas du tout avec la réalité de l'Internet. On entend aussi souvent des erreurs comme de prétendre qu'un URL indique où se trouve une ressource (rien n'est plus faux). Il vaut donc mieux adopter une autre perspective, celle des propriétés.
Plutôt que d'essayer de définir la différence entre un nom et une adresse, ou de reprendre le débat philosophique entre URL et URN, attachons-nous à déterminer les propriétés des différents types d'identificateurs et voyons lesquelles sont importantes pour chaque cas d'usage.
La discussion est d'autant plus importante que, si certains identificateurs n'ont qu'on rôle technique et sont largement cachés à l'utilisateur (pensons aux adresses MAC par exemple), d'autres sont un vecteur d'identité.
Sur l'Internet, vous n'êtes pas Jean Dupont, né le 3 octobre 1978 à Bois-le-Roi, vous êtes "jdupont43" sur Twitter, vous êtes jean.dupont.fr, vous êtes jeannot@gmail.com, et
ces identificateurs, qui apparaissent à tous, sont votre identité. La première partie de l'exposé portera donc sur ces vecteurs d'identité. Quel est notre futur ?
Quelle identité sera la principale ? Aurons-nous une pluralité d'identités ou bien Facebook sera t-il le seul fournisseur d'identité (comme c'est le cas aujourd'hui pour certaines entreprises qui mettent leur identifiant Facebook sur leurs cartes de visite et publicités) ? Les identités seront-elles basées sur un système centralisé comme Facebook, sur un système arborescent comme les noms de domaine (avec, par exemple, la technologie WebFinger) ou sur autre chose ?
La deuxième partie sera consacrée aux identificateurs fondés sur le contenu. Popularisés par les magnets (utilisés notamment par BitTorrent), normalisés sous la forme des URI "ni", quelle place prendront-ils dans le bestiaire des identificateurs ? Des systèmes de résolution efficaces seront-ils mis en place pour ces identificateurs ?
Identification, nommage et DNS dans l’Internet du futur: "Toile de fond techn...Afnic
Identification, nommage et DNS dans l’Internet du futur : éléments issus de l’enquête de « toile de fond technologique » AFNIC par Mohsen Souissi lors du Séminaire du Conseil Scientifique AFNIC du 10 juin 2011
Surveillances de Nom de domaines : fonctionnement, bonnes pratiques et usages...Keep Alert
Keep Alert présente la surveillance des noms de domaine : entre bonnes pratiques et usages méconnus.
Quelles sont les sources de données ? Comment analyser un grand nombre de résultats ? Comment utiliser une surveillance pour faire de l'intelligence économique ?
Cette présentation a été effectuée lors de la 15ème Journée PI organisée par Legiteam
Avec ce livre blanc, Nameshield tente de déchiffrer pour vous toutes les subtilités de l’univers des noms de domaine, de vous apporter des réponses claires sur de sujets souvent méconnus, des pratiques souvent oubliées, de vous éclairer sur les moyens pour être encore plus visible sur internet, pour protéger efficacement vos actifs immatériels.
Découvrez CrowdSec, la plate-forme d’automatisation de la sécurité, gratuite et open source, reposant sur l'analyse comportementale et la réputation des adresses IP. Elle analyse le comportement des visiteurs, identifie les menaces et protège les services numériques contre tout type d’attaques. La solution permet aussi aux utilisateurs de se protéger mutuellement. Chaque fois qu'une IP est bloquée, tous les membres de la communauté en sont informés. Déjà utilisée dans plus de 110 pays sur 6 continents, la solution constitue une base de données d’IP en temps réel qui profitera aux particuliers, aux entreprises, aux institutions, etc.
Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANEAfnic
Alors que la sécurisation des communications sur Internet n’a jamais été autant d’actualité, l’Afnic lance un dossier thématique consacré au protocole DANE
Bonnes pratiques pour sécuriser un serveur LinuxKiwi Backup
Nous vous proposons de partager notre expertise sur le durcissement (procédés de sécurisation) des serveurs Linux :
- Principaux axes d'attaques possibles d'un serveur Linux
- Défenses profondes à mettre en place
- Arbitrage entre la sécurisation et la fluidité de fonctionnement des applicatifs
- Quelques outils indispensables
"Seuls survivent ceux qui adaptent leur sécurité à leurs enjeux". Découvrez qu'en sécurité informatique, des mesures simples peuvent parfois suffire à se protéger de la majorité des attaques. Avec cette nouvelle approche de la sécurité, restez en avance sur vos concurrents... et sur les pirates informatiques.
Comment exploiter le DNS par plaisir et appât du gain ? (Infoblox)Florian Magnat
Voici un document de 8 pages présentant le fonctionnement des services DNS mais aussi les types d'attaques via ce moyen.
Florian Magnat (document Infoblox)
L’Afnic publie désormais un bilan trimestriel de ses procédures alternatives de résolution de litiges. Découverte de l’étude de ce premier trimestre 2015.
Securing Internet communications end-to-end with the DANE protocolAfnic
Highlighting the fact that securing communications over the Internet is more important than ever before, Afnic launches an issue paper on the DANE protocol
AFNIC just published a Practical Guide to DNSSEC deployment: this implementation and deployment manual provides practical guidance for DNS hosts to configure DNSSEC on their infrastructure;
L'Afnic vient de publier un guide pratique de déploiement de DNSSEC : ce manuel de mise en œuvre et de déploiement permet d’aider concrètement les hébergeurs de DNS à configurer DNSSEC sur leurs infrastructures. Plus d'information sur http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/7380/show/l-afnic-s-engage-dans-la-promotion-de-dnssec-2.html
The document discusses the life cycle of .FR domain names. Domain names are registered for 1 to 10 years and must be renewed before expiration to remain active. Domain names that are not renewed on time will first be put on hold, then deleted and made available for new registration after a certain waiting period if not renewed by the original owner.
Voir cette présentation en vidéo sur http://www.youtube.com/watch?v=mLQT_i-Lgsk
Isabelle Chrisment (Inria) présente "L'initiative PLATON (PLATeforme d'Observation de l'interNet) lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
JCSA2013 07 Pierre Lorinquer & Samia M'timet - Observatoire de la résilience ...Afnic
Voir la présentation en vidéo sur http://www.youtube.com/watch?v=lhkAtsCm6fw
Pierre Lorinquer (ANSSI) et Samia M'Timet (Afnic) présentent l'essentiel de l'Observatoire 2012 de la résilience de l'Internet en France lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
L'Observaoire en question est en ligne sr http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/7126/show/l-observatoire-sur-la-resilience-de-l-internet-francais-publie-son-rapport-2012-2.html
JCSA2013 06 Luigi Iannone - Le protocole LISP ("Locator/Identifier Sepration ...Afnic
Voir la présentation en vidéo sur http://www.youtube.com/watch?v=Om1zqb2VuPM
Luigi Iannone (Télécom ParisTech) présente "Vers un renforcement de l'architecture Internet : le protocole LISP ("Locator/Identifier Separation Protocol")" lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
JCSA2013 05 Pascal Thubert - La frange polymorphe de l'InternetAfnic
Pascal Thubert (Cisco) présente "La frange polymorphe de l'Internet" lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
JCSA2013 04 Laurent Toutain - La frange polymorphe de l'InternetAfnic
Voir la vidéo sur http://www.youtube.com/watch?v=tVzz_CSFs8A
Laurent Toutain (Télécom Bretagne) présente "La frange polymorphe de l'Internet" lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
JCSA2013 03 Christian Jacquenet - Nouveau shéma d'acheminement de trafic déte...Afnic
Retrouvez la vidéo en français sur http://www.youtube.com/watch?v=3ezs-JDac0k
Christian Jacquenet (Orange Labs) présente "Un nouveau shéma d'acheminement de trafic déterministe" lors de la Journée du Conseil scientifique de l'Afnic 2013 (JCSA2013), le 9 juillet 2013 dans les locaux de Télécom ParisTech.
The document discusses the introduction of new generic top-level domains (gTLDs) by the Internet Corporation for Assigned Names and Numbers (ICANN). It notes that while most domain names use .com and country code TLDs, ICANN's new gTLD program will allow for greater diversification. The new gTLDs will launch starting in late 2013, with some targeting specific regions, communities or industries. However, uptake of new gTLDs will depend on promotion efforts and whether users find them intuitive. The document analyzes challenges around establishing new gTLDs and ensuring users understand and adopt them.
Observatoire sur la résilience Internet en France-2012Afnic
Créé par l’Afnic & l’ANSSI, il a pour objectifs de définir puis de mesurer des indicateurs représentatifs de la résilience de l'Internet français.
Plus d'information sur http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/7126/show/l-observatoire-sur-la-resilience-de-l-internet-francais-publie-son-rapport-2012-2.html
Afnic Public Consultation overview on the Opening of 1 and 2 charactersAfnic
This document provides an overview of a public consultation conducted by Afnic, the .fr registry, regarding opening registration of 1 and 2 character domain names under .fr. The consultation gathered opinions on possible opening procedures and naming restrictions through an online survey. Most discussion of the consultation was positive on social media. Contributions recommended a sunrise period to protect rights holders, special high pricing to prevent speculation, and limited naming restrictions. In general, the consultation suggested opening with a sunrise period, dissuasive pricing, and limited restrictions for 1 and 2 character .fr domains.
Pour plus d'information sur le Rapport d'Activité 2012 de l'Afnic http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/7047/show/rapport-d-activite-de-l-afnic-focus-sur-les-mutations-de-2012-1.html
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...OCTO Technology
par Claude Camus (Coach agile d'organisation @OCTO Technology) et Gilles Masy (Organizational Coach @OCTO Technology)
Les équipes infrastructure, sécurité, production, ou cloud, doivent consacrer du temps à la modernisation de leurs outils (automatisation, cloud, etc) et de leurs pratiques (DevOps, SRE, etc). Dans le même temps, elles doivent répondre à une avalanche croissante de demandes, tout en maintenant un niveau de qualité de service optimal.
Habitué des environnements développeurs, les transformations agiles négligent les particularités des équipes OPS. Lors de ce comptoir, nous vous partagerons notre proposition de valeur de l'agilité@OPS, qui embarquera vos équipes OPS en Classe Business (Agility), et leur fera dire : "nous ne reviendrons pas en arrière".
OCTO TALKS : 4 Tech Trends du Software Engineering.pdfOCTO Technology
En cette année 2024 qui s’annonce sous le signe de la complexité, avec :
- L’explosion de la Gen AI
-Un contexte socio-économique sous tensions
- De forts enjeux sur le Sustainable et la régulation IT
- Une archipélisation des lieux de travail post-Covid
Découvrez les Tech trends incontournables pour délivrer vos produits stratégiques.
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Laurent Speyser
(Conférence dessinée)
Vous êtes certainement à l’origine, ou impliqué, dans un changement au sein de votre organisation. Et peut être que cela ne se passe pas aussi bien qu’attendu…
Depuis plusieurs années, je fais régulièrement le constat de l’échec de l’adoption de l’Agilité, et plus globalement de grands changements, dans les organisations. Je vais tenter de vous expliquer pourquoi ils suscitent peu d'adhésion, peu d’engagement, et ils ne tiennent pas dans le temps.
Heureusement, il existe un autre chemin. Pour l'emprunter il s'agira de cultiver l'invitation, l'intelligence collective , la mécanique des jeux, les rites de passages, .... afin que l'agilité prenne racine.
Vous repartirez de cette conférence en ayant pris du recul sur le changement tel qu‘il est généralement opéré aujourd’hui, et en ayant découvert (ou redécouvert) le seul guide valable à suivre, à mon sens, pour un changement authentique, durable, et respectueux des individus! Et en bonus, 2 ou 3 trucs pratiques!
L'IA connaît une croissance rapide et son intégration dans le domaine éducatif soulève de nombreuses questions. Aujourd'hui, nous explorerons comment les étudiants utilisent l'IA, les perceptions des enseignants à ce sujet, et les mesures possibles pour encadrer ces usages.
Constat Actuel
L'IA est de plus en plus présente dans notre quotidien, y compris dans l'éducation. Certaines universités, comme Science Po en janvier 2023, ont interdit l'utilisation de l'IA, tandis que d'autres, comme l'Université de Prague, la considèrent comme du plagiat. Cette diversité de positions souligne la nécessité urgente d'une réponse institutionnelle pour encadrer ces usages et prévenir les risques de triche et de plagiat.
Enquête Nationale
Pour mieux comprendre ces dynamiques, une enquête nationale intitulée "L'IA dans l'enseignement" a été réalisée. Les auteurs de cette enquête sont Le Sphynx (sondage) et Compilatio (fraude académique). Elle a été diffusée dans les universités de Lyon et d'Aix-Marseille entre le 21 juin et le 15 août 2023, touchant 1242 enseignants et 4443 étudiants. Les questionnaires, conçus pour étudier les usages de l'IA et les représentations de ces usages, abordaient des thèmes comme les craintes, les opportunités et l'acceptabilité.
Résultats de l'Enquête
Les résultats montrent que 55 % des étudiants utilisent l'IA de manière occasionnelle ou fréquente, contre 34 % des enseignants. Cependant, 88 % des enseignants pensent que leurs étudiants utilisent l'IA, ce qui pourrait indiquer une surestimation des usages. Les usages identifiés incluent la recherche d'informations et la rédaction de textes, bien que ces réponses ne puissent pas être cumulées dans les choix proposés.
Analyse Critique
Une analyse plus approfondie révèle que les enseignants peinent à percevoir les bénéfices de l'IA pour l'apprentissage, contrairement aux étudiants. La question de savoir si l'IA améliore les notes sans développer les compétences reste débattue. Est-ce un dopage académique ou une opportunité pour un apprentissage plus efficace ?
Acceptabilité et Éthique
L'enquête révèle que beaucoup d'étudiants jugent acceptable d'utiliser l'IA pour rédiger leurs devoirs, et même un quart des enseignants partagent cet avis. Cela pose des questions éthiques cruciales : copier-coller est-il tricher ? Utiliser l'IA sous supervision ou pour des traductions est-il acceptable ? La réponse n'est pas simple et nécessite un débat ouvert.
Propositions et Solutions
Pour encadrer ces usages, plusieurs solutions sont proposées. Plutôt que d'interdire l'IA, il est suggéré de fixer des règles pour une utilisation responsable. Des innovations pédagogiques peuvent également être explorées, comme la création de situations de concurrence professionnelle ou l'utilisation de détecteurs d'IA.
Conclusion
En conclusion, bien que l'étude présente des limites, elle souligne un besoin urgent de régulation. Une charte institutionnelle pourrait fournir un cadre pour une utilisation éthique.
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...OCTO Technology
Par Nicolas Bordier (Consultant numérique responsable @OCTO Technology) et Alaric Rougnon-Glasson (Sustainable Tech Consultant @OCTO Technology)
Sur un exemple très concret d’audit d’éco-conception de l’outil de bilan carbone C’Bilan développé par ICDC (Caisse des dépôts et consignations) nous allons expliquer en quoi l’ACV (analyse de cycle de vie) a été déterminante pour identifier les pistes d’actions pour réduire jusqu'à 82% de l’empreinte environnementale du service.
Vidéo Youtube : https://www.youtube.com/watch?v=7R8oL2P_DkU
Compte-rendu :
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
DNSSEC : les extensions de sécurité du DNS
1. DNSSEC - les extensions de sécurité du DNS
1/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
Copyright AFNIC 2010
DNSSEC
les extensions
de sécurité
du DNS
Enjeux de DNSSEC
Lasécuritédetoutsystèmedépendàlafoisdelasécurisation
de ses différentes composantes et des interactions
entre celles-ci. Ce constat est aussi valable pour le DNS
(Domain Name System), maillon clé du fonctionnement
de l’Internet, car la quasi-totalité des services en ligne
utilise des noms de domaine à un moment ou à un autre.
Cependant, le DNS a été mis au point dans les années
80, dans un environnement où sa capacité à répondre aux
besoins de performance et de résilience primait sur sa
sécurisation. Avec le temps, et notamment depuis 2008,
avec la révélation de la « Faille Kaminsky », la nécessité
de mieux sécuriser le DNS est devenue une priorité pour
tous ses acteurs.
S’il ne saurait répondre à l’ensemble des attaques possibles
contre le DNS, le protocole DNSSEC permet d’apporter
une protection durable – et demain, indispensable –
contre les agressions dites « par empoisonnement de
cache » visant à substituer de fausses informations aux
vraies dans le processus de résolution des noms de domaine. L’attaquant peut ainsi espérer leurrer des
utilisateurs et les détourner vers son site à leur insu. Or la capacité croissante des machines et du réseau
en termes de débit rend désormais possible des attaques qui, jusqu’à présent, n’étaient que théoriques,
compte tenu de leur faible probabilité de succès.
Le présent dossier thématique s’inscrit dans la continuité de celui que l’AFNIC a déjà consacré à la
sécurité du DNS
1
, en explorant plus précisément les tenants et les aboutissants de DNSSEC. Il a pour
objectif d’apporter des éléments de compréhension de ses enjeux et de son fonctionnement, afin de
permettre au lecteur de mieux s’approprier cette évolution qui va modifier la physionomie du DNS dans
les années à venir.
1 - Organisation et
fonctionnement du DNS
2 - Les attaques par
empoisonnement de
cache
3 - Qu’est-ce que DNSSEC ?
4 - Ce que n’est pas DNSSEC
5 - Utilisation des clés dans
DNSSEC
6 - Le déploiement de
DNSSEC
7 - Quelques questions à se
poser au regard de la mise
en place de DNSSEC
8 - Pour aller plus loin
9 - Glossaire
1
www.afnic.fr/data/divers/public/afnic-dossier-dns-attaques-securite-2009-06.pdf
Introduction
Les dossiers thématiques de l’AFNIC
2. 2/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
DNSSEC - les extensions de sécurité du DNS Copyright AFNIC 2010
RésolveurUtilisateur
.
fr
wikipedia.fr
www.wikipedia.fr ?
www.wikipedia.fr ?
www.wikipedia.fr ?
www.wikipedia.fr ?
74.125.39.99
74.125.39.99
serveur wikipedia.fr
serveur fr
1
2
3
La résolution DNS
1 Organisation et fonctionnement du DNS
2 Les attaques par empoisonnement de cache
Le DNS est organisé sous la forme d’une arborescence inversée, avec une « racine » dont dépendent
les différentes « branches ». Au premier niveau de l’arborescence se trouvent les « Top Level Domains »
ou domaines de premier niveau, comme les .fr, .com etc. Au second niveau, nous avons les noms de
domaine « classiques » comme « afnic.fr ».
Dans l’exemple ci-dessus, l’utilisateur veut se
connecter au site http://www.wikipedia.fr. Il envoie
sa requête via son navigateur. Celle-ci est reçue par
un serveur dit « résolveur » qui a pour première
mission d’identifier la machine sur laquelle est
installé le nom de domaine wikipedia.fr. Le résolveur
s’adresse d’abord à la « racine » du DNS, qui lui
indique quelles sont les serveurs « faisant autorité »
(c’est-à-dire compétents) pour .fr puisque le nom
de domaine est en .fr. Dans un second temps, les
serveurs du .fr indiquent à leur tour au résolveur que
le nom de domaine wikipedia.fr est hébergé sur tel
serveur. Celui-ci est alors en mesure d’indiquer au
navigateur l’adresse IP du serveur web hébergeant
les contenus du site web www.wikipedia.fr.
Ce schéma est vrai quel que soit le site web auquel
on souhaite accéder, et quelle que soit l’adresse
électronique à laquelle on souhaite écrire.
Fonctionnant comme une base de données
distribuée sur des millions de machines, le DNS
repose sur des interactions entre ces machines
permettant d’identifier celle qui est la plus
susceptible de pouvoir répondre à la requête d’un
internaute.
Le dossier thématique de l’AFNIC consacré à la
sécurité du DNS dresse un panorama des grands
types d’attaques possibles, depuis les attaques ne
visant pas directement le DNS (cybersquatting,
vol de noms de domaine…) jusqu’à celles qui se
concentrent sur lui, telles les attaques par déni de
services ou empoisonnement de cache.
DNSSEC répond spécifiquement aux attaques par
empoisonnement de cache visant à intoxiquer le
« résolveur » pour qu’il considère que le serveur
« pirate » est légitime, en lieu et place du serveur
originel. Cette opération permet notamment de
capter et de détourner les requêtes vers un autre site
web sans que les utilisateurs puissent s’en rendre
compte, avec à la clé le risque de les voir confier
des données personnelles en se croyant sur le site
légitime de la victime de l’attaque.
3. 3/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
DNSSEC - les extensions de sécurité du DNS Copyright AFNIC 2010
Les attaques par empoisonnement de cache
3 Qu’est-ce que DNSSEC ?
4 Ce que n’est pas DNSSEC
Ces extensions utilisent les mécanismes de la
signature cryptographique asymétrique pour
authentifier les enregistrements. Les signatures et
les clés publiques se présentent sous la forme de
nouveaux enregistrements complémentaires et
permettent d’assurer l’authentification.
Ces nouveaux enregistrements engendrent une
augmentation de la taille des messages et du
nombre d’échanges pour vérifier les signatures et
les clés. DNSSEC nécessite donc plus de ressources
machines, ainsi que des versions récentes et à jour
de logiciels DNS.
Le protocole a naturellement été conçu
pour pouvoir fonctionner sans problème dans
un environnement qui, au départ tout au moins,
ne sera pas entièrement composé de résolveurs
DNSSEC validants. Dans le cas où un résolveur non
DNSSEC validant interroge des serveurs DNSSEC,
ceux-ci renvoient simplement les informations
habituellement échangées sans les signatures ni les
enregistrements propres à DNSSEC.
Il n’a, par exemple, pas vocation à crypter les
enregistrements DNS, ni à assurer la confidentialité
des échanges sur le réseau, ni à garantir la sécurité
d’une transaction comme le font les certificats
SSL. Il ne protège pas contre le phishing ou le vol
de noms de domaine, contre les virus et autres
techniques d’infection des postes informatiques, ou
encore contre les attaques visant les sites web eux-
mêmes (injections SQL…).
Le bon fonctionnement du DNS dépend donc
étroitement de la fiabilité des données transmises
à chaque étape. Les extensions de sécurité du DNS
cherchent à répondre à cette contrainte en assurant
l’intégrité des données transitant sur le réseau,
notamment entre résolveurs et serveurs faisant
autorité.
DNSSEC est l’acronyme de Domain Name System Security Extensions, il désigne un ensemble défini
d’extensions de sécurité du protocole DNS.
Bien qu’étant à juste titre présenté comme une évolution nécessaire en termes de sécurisation du DNS,
DNSSEC ne prétend aucunement répondre à tous les types d’attaques pouvant survenir.
Pirate
Serveur DNS
A
Serveur DNS
B
RequêtesD
N
S
Requêtes transmises
Bonne
Réponse
Réponses erronées
4. 4/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
DNSSEC - les extensions de sécurité du DNS Copyright AFNIC 2010
privée
publique
Information DNS
Message DNS
Signature
numérique
wikipedia.fr
Réside à
l’adresse
...
wikipedia.fr
Réside à
l’adresse
...
wikipedia.fr
Réside à
l’adresse
...AwEAAdzt
V8QQzRLg
Hko0P9nI
...
AwEAAdzt
V8QQzRLg
Hko0P9nI
...
clé privée
clé publique
Chiffrement
Déchiffrement
comparaison
Erreur
Identique
Message
authentique
Message
non
authentique
Réseau-Réseau-Réseau-Réseau-Réseau-Réseau
Logiciel de
signature
Serveur maître
faisant autorité
Validation d’une signature par le
serveur récursif DNSSEC validant
Signature et validation de signature dans le cas du DNS
5 Utilisation des clés dans DNSSEC
DNSSEC utilise un mécanisme reposant sur une paire de clés ayant des rôles complémentaires. La
première clé, privée, signe par chiffrement alors que la seconde clé, publique, vérifie les signatures par
déchiffrement.
Un message est chiffré grâce à la clé privée, créant
une signature accompagnant le message. Cette
signature pourra être authentifiée par les résolveurs
DNSSEC validant à l’aide de la clé publique
correspondante publiée dans la zone.
Afin d’éviter qu’un attaquant n’utilise son propre jeu
de clés, les concepteurs de DNSSEC ont prévu que
chaque zone parente, située au niveau supérieur de
l’arborescence du DNS, garantisse l’authenticité des
clés de ses zones filles en les signant, les échanges
de clés entre zones parentes et filles se faisant
exclusivement par des canaux sécurisés. Ce système
permet de créer de véritables chaînes de confiance
jusqu’à la racine du DNS.
DNSSEC nécessite par ailleurs une bonne gestion
de la durée de vie des signatures par rapport à la
publication des clés, des signatures expirées pouvant
conduire au blocage de la résolution pour la zone
concernée.
À l’instar des autres enregistrements DNS, les
enregistrements DNSSEC ont en effet des durées
de vie limitées afin de permettre la résilience
du système et d’autoriser des mises à jour en
temps utile. Lorsqu’une signature expire, elle est
considérée comme invalide et il n’est plus possible
de joindre le service. Il est donc nécessaire de
resigner régulièrement les enregistrements, en
plus des nouvelles signatures produites suite à des
créations ou à des modifications d’enregistrements.
Le déploiement de DNSSEC induit par conséquent
un travail supplémentaire et génère potentiellement
de nouveaux risques d’erreurs (mauvaises
configurations, expirations de signatures…). Ainsi,
si la clé insérée dans la zone parente n’est pas
celle qui est utilisée pour signer, la zone fille sera
considérée comme invalide et il se produira une
erreur de résolution.
De plus, chacun des niveaux de sécurité n’a de
sens qu’au sein de la chaîne de confiance : ainsi,
des enregistrements signés ne peuvent pas être
authentifiés tant que la clé de la zone n’a pas été
publiée dans la zone parente. À l’inverse, aucune
sécurité particulière n’est apportée à l’utilisateur tant
que son résolveur n’a pas mis en oeuvre DNSSEC.
Enfin, DNSSEC ne protège pas l’intégrité des
données qui auraient été modifiées de manière
accidentelle ou volontaire en amont de leur
publication dans le DNS.
5. 5/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
DNSSEC - les extensions de sécurité du DNS Copyright AFNIC 2010
6 Le déploiement de DNSSEC
Ce n’est pourtant qu’en 2005, après maints travaux
au sein de la communauté technique, que le registre
de l’extension .se (Suède) fut le premier à signer sa
zone. C’est aussi lui qui fut le premier à ouvrir ce
service aux titulaires de noms de domaine en 2007.
Considéré avec intérêt mais sans caractère d’urgence
jusqu’en 2008, DNSSEC devient une priorité forte
pour tous les registres d’extensions à partir de l’été
2008, lorsque la Faille Kaminsky révèle à tous de
l’ampleur du problème potentiel. Par conséquent,
depuis, une quinzaine de registres ont signé leur
extension à la mi-2010 et la plupart des autres
y travaillent. Le .fr pour sa part a été signé le 14
septembre 2010.
S’il passe par les registres, le déploiement de
DNSSEC ne s’arrête pas là : les gestionnaires
des résolveurs (FAI, bureaux d’enregistrement,
entreprises…) doivent à leur tour mettre en place
DNSSEC pour que celui-ci fonctionne à plein.
Un certain nombre de solutions existent, depuis les
solutions de logiciels libres telles qu’Open-dnssec
jusqu’aux boîtiers propriétaires, en passant par les
bibliothèques de programmation qui simplifient les
développements.
Bien qu’ayant connu une forte montée en puissance depuis la révélation de la Faille Kaminsky, DNSSEC
n’est pas une découverte pour les experts du DNS. L’IETF (Internet Engineering Task Force) a en effet
commencé à travailler dès 1995 sur un tel protocole de sécurisation du DNS.
FAI
Entreprises
...
Résolveur simple
Applications
Services
internet
Titulaire
de nom
Internaute
Serveur faisant autorité DNSSEC
Serveur récursif DNSSEC validant
Requêtes et réponses DNS
Approvisionnement NS + empreinte KSK
La clé qui signe les clés
Chaîne de confiance
Web
Email
Voip
...
DS
DS
DS
Registre
de TLD
Bureau
d’enregis-
trement
Hébergeur
de zone DNS
Racines
du DNS
Composantes de la chaîne de confiance DNSSEC
6. 6/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
DNSSEC - les extensions de sécurité du DNS Copyright AFNIC 2010
7 Quelques questions à se poser au regard de la mise en place de DNSSEC
La mise en oeuvre de DNSSEC n’est pas seulement une évolution technique majeure pour le DNS : elle
induit aussi une adaptation de l’organisation de la gestion des noms de domaine et peut conduire à
une nécessaire évolution de celle-ci, notamment du fait de l’émergence de nouveaux aspects comme
la gestion des clés.
Il convient donc d’anticiper une certaine montée
en compétence des équipes techniques – le sujet
restant peu connu – mais aussi une évolution des
procédures tout en conservant une cohérence
globale avec les différents aspects de la politique de
sécurité de l’entreprise.
Voici une liste de quelques questions à se poser, sans prétendre à l’exhaustivité :
Chez qui les zones DNS de l’entreprise sont-elles hébergées ?
Quelle est la compétence de ce prestataire dans la gestion de DNSSEC ?
Quel niveau de transparence ce prestataire offre-t-il à ses clients en termes de pratiques ?
Quels sont les dispositifs de sécurité dont ce prestataire dispose au-delà de DNSSEC ?
Ce prestataire offre-t-il des canaux de transactions sécurisés ?
Quel mode d’organisation ce prestataire préconise-t-il pour la gestion des clés, au sein de son équipe
et en articulation avec celles de l’entreprise ?
Y a-t-il une incidence en termes de coûts à la mise en place de DNSSEC ?
Si l’entreprise passe par un prestataire pour la signature de ses zones, comment gérer un transfert à
un autre prestataire de ses noms de domaine signés ?
Le niveau de dépendance induit à l’égard de ce prestataire est-il acceptable, ou de nature à inciter
l’entreprise à internaliser cette fonction au moins pour ses noms de domaine les plus stratégiques ?
Si oui, quelles sont les ressources et les capacités dont dispose l’entreprise sur ces problématiques et
quels moyens seraient-ils nécessaires pour accompagner une éventuelle montée en puissance ?
La charge induite par le déploiement de DNSSEC,
aussi bien en coûts qu’en termes de mise à niveau
des équipes, peut être perçue comme importante
en regard des risques qu’il prévient. Bien que
potentiellement justifiée à court terme, cette
approche ne tient cependant pas compte de
l’accroissement du débit des réseaux et des capacités
machines, qui fait progresser mécaniquement les
chances de succès des attaques par empoisonnement
de cache dans le format actuel du fonctionnement
du DNS. La mise en oeuvre de DNSSEC doit donc
être envisagée comme une nécessité incontournable
à moyen terme.
La principale problématique dans le déploiement de
DNSSEC est de mettre en place un système efficace
de gestion des clés. Celles-ci doivent en effet être
régulièrement modifiées afin d’éviter leur vol ou
leur recalcul, mais aussi protégées par des dispositifs
physiques et numériques. Les mises à jour doivent
par ailleurs être opérée de manière à prendre en
compte les temps de propagation des informations
dans le DNS, afin d’éviter que les résolveurs fassent
correspondre une nouvelle signature à une ancienne
clé ou l’inverse. Ceci impose des périodes de latence
entre la déclaration des clés et la signature avec
celles-ci.
La mise en œuvre de DNSSEC implique donc pour
chaque zone de :
• Créer des clés.
• Signer ses enregistrements.
• Publier la zone signée.
• Gérer des périodes de validité.
• Gérer les publications du résumé de la clé
dans la zone parente avec chaque rotation de
KSK.
• Contrôler la publication d’une nouvelle clé
avant de l’utiliser pour signer.
7. 7/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
DNSSEC - les extensions de sécurité du DNS Copyright AFNIC 2010
8 Pour aller plus loin
9 Glossaire
Espace DNSSEC du site de l’AFNIC : www.afnic.fr/dnssec
Page DNSSEC de Wikipedia en français : http://fr.wikipedia.org/wiki/DNSSEC
DNS :
Domain Name System. Service distribué permettant d’enregistrer les
ressources de l’Internet (adresse de serveurs, de routeurs, ...) sous la
forme d’un nom de domaine.
DNSKEY :
Enregistrement DNS servant à stocker la partie publique d’une clé.
DNSSEC :
Domain Name System Security Extensions. Ensemble d’extensions
de sécurité du protocole DNS.
DS :
Delegation Signer. Enregistrement DNS qui correspond à
l’empreinte de la partie publique d’une clé.
KSK :
Key Signing Key. Clé qui signe les clés ZSK. L’empreinte de sa partie
publique est publiée dans la zone parente pour créer une chaîne de
confiance garantissant son authenticité ainsi que l’authenticité des
clés signant la zone.
NS :
Name Server. Appelé aussi serveur DNS ou serveur de nom. Serveur
utilisé pour héberger un nom de domaine.
SSL :
Secure Sockets Layer. Protocole de sécurisation des échanges sur
Internet.
SQL :
Structured Query Language. Langage informatique normalisé qui
sert à demander des opérations sur des bases de données.
ZSK :
Zone Signing Key. Clé qui signe les enregistrements de la zone. La
partie publique de la ZSK permet de vérifier les signatures.
web
Pour toute information supplémentaire sur les actions
de l’AFNIC relatives à DNSSEC :
solutions@afnic.fr
8. DNSSEC - les extensions de sécurité du DNS
8/8
Reproduction des contenus rédactionnels autorisée
sous réserve de mentionner la source : www.afnic.fr
Copyright AFNIC 2010
Retrouvez tous les dossiers thématiques de l’AFNIC :
www.afnic.fr/actu/presse/liens-utiles
www.afnic.fr - afnic@afnic.fr
web