Quels enseignements tirer de l’ICANN62 de Panama ?

Quels enseignements tirer de l’ICANN62 de Panama ?

Fin juin, l’ICANN a tenu son 62ième sommet dans la capitale de Panama. Ce sommet dit « intermédiaire » dans la mesure où il s’agit du second des trois rendez-vous annuels que donne l’ICANN à la communauté internet, a été l’occasion d’annonces suivies par Nameshield qui était sur place.

Un sommet plus mesuré

Du 25 au 28 juin dernier, l’ICANN tenait à Panama city son 62ième sommet. Ce rendez-vous de milieu d’année se veut habituellement moins démonstratif que les sommets de début et de fin d’année. En pratique rien ne change mais quand on y regarde de plus près on note de petites différences dans les pauses et les déjeuners qui se transforment en déjeuners privés et les cocktails plus rares et davantage mesurés. Selon nos sources, il s’agirait avant tout d’une question d’équilibre budgétaire car l’ICANN a une feuille de route budgétaire pour ses événements et cela relève plutôt du sens d’une bonne gestion que de limiter les dépenses en milieu d’année.

Davantage de transparence et d’échanges entre instances

Autre fait notable, comparativement à des sommets antérieurs, l’agenda des meetings sur place employait moins souvent la terminologie « Closed session » (session fermée). Cette évolution vers davantage de transparence est notamment illustrée par le GAC, le comité consultatif des gouvernements, dont presque toutes les sessions étaient ouvertes au public alors qu’il y a peu leurs sessions étaient majoritairement fermées. Parallèlement à cette évolution, on note également que les instances représentatives de certains acteurs comme les registres, les registrars ont davantage échangé entre elles et cela de manière publique. Cela veut-il pour autant dire que tout va bien dans le meilleur des mondes ?

De gauche à droite : Donna Austin Chair du groupe des registres RySG, Heather Forrest chair du GNSO (Generic Names Supporting Organization), et Manal Ismail chair du GAC (Governmental Advisory Committee).

Le RGPD encore et toujours

Non, il y a bien des écueils. Le RGPD, le fameux règlement européen sur la protection des données personnelles, voté en 2016 par le Parlement Européen et entré en vigueur le 25 mai dernier en est la meilleure illustration. Sur ce sujet, la communauté internet n’est pas parvenue à un consensus pour adapter l’industrie des noms de domaine aux enjeux de ce Règlement. Si certains diront que l’ICANN s’y est intéressée trop tardivement, l’ICANN a dû imposer à l’arrachée des Spécifications Temporaires qui ont été votées le 17 mai pour application le 25 mai. Ces mesures souvent contraignantes pour les  registres et registrars, comme le masquage de toutes les données personnelles du Whois, dans un délai aussi court, ont occasionné un surcroit de charge et pour la première fois une fragmentation de services entre prestataires, tous n’appliquant pas ces règles de la même manière.

Pour sortir de cette situation inédite, l’un des enjeux principaux de Panama, était donc de lancer un processus qui doit permettre de remplacer ces règles temporaires par des règles consensuelles avant mai 2019. Il faut savoir en effet que la durée d’application de règles temporaires ne peut pas excéder une année.

Sur ce plan, Panama aura atteint son objectif car le lancement du processus de consultation et de révision a été officialisé à Panama. Ce travail qui doit aboutir pour la fin d’année par la remise d’un rapport va être suivi de près par les autorités européennes ainsi qu’Europol qui ont demandé à ce que les choses avancent vite.

Dans ce contexte, Nameshield était heureux de porter les intérêts des entreprises européennes dans des débats où les entreprises américaines étaient omniprésentes.

L’audit du dernier round dans le timing

L’autre grand sujet de Panama était l’avancée de la revue du dernier round des nouvelles extensions qui remonte déjà à 2012. L’audit de ce round qui a débuté en 2016 devait aboutir à un rapport global en fin d’année. Panama aura permis de constater que le timing de ce travail de longue haleine était globalement tenu dans la mesure où quatre des cinq groupes de travail qui ont planché sur ce sujet ont présenté à Panama un rapport préliminaire qui sera complété d’ici à la fin de l’année par le travail du dernier groupe de travail qui se penche lui sur l’utilisation plus large de termes géographiques en tant qu’extension internet.

Rendez-vous à Barcelone pour l’ICANN63

Dans un peu plus de trois mois, se tiendra à Barcelone le dernier sommet annuel de l’ICANN. Ce sommet auquel participera Nameshield sera l’occasion de mesurer l’avancée des sujets précités.

[INFOGRAPHIE] Phishing, slamming, e-mails frauduleux : Soyez vigilants pendant les périodes de vacances !

En forte augmentation, les attaques de phishing, slamming et autres e-mails frauduleux reposent sur des techniques d’« ingénierie sociale », consistant à exploiter non pas une faille informatique, mais la « faille humaine », en dupant les internautes par le biais d’un e-mail semblant provenir d’une entreprise de confiance.

Les périodes de vacances estivales correspondent à l’envoi en masse de ces e-mails frauduleux. En effet, les cybercriminels tentent de profiter d’une vigilance qui peut être particulièrement relâchée pendant ces périodes.

Voici une infographie vous expliquant quelles sont ces attaques et comment s’en protéger grâce à des règles simples de vigilance et de prudence.

Phishing, slamming, e-mails frauduleux : Soyez vigilants pendant les périodes de vacances!

Bataille juridique autour du nom de domaine France.com

France.com, un nom de domaine qui fait parler de lui
Source de l’image : jackmac34 via Pixabay

France.com, un nom de domaine qui fait parler de lui

L’entrepreneur Jean-Noel Frydman attaque la République Française pour récupérer son nom de domaine France.com, dont le Ministère des Affaires étrangères s’est réapproprié l’usage par décision de justice.

Petit retour sur l’origine de France.com

Pour rappel, les faits ont commencé lors de l’éveil du web en 1994. A cette époque, l’homme d’affaire américain, d’origine française, Jean-Noel Frydman a déposé le nom de domaine France.com auprès de web.com, destiné à l’exploitation de sites commerciaux, tels que la première agence de voyage en ligne française.

Si le nom France.com hébergeait sans heurt depuis 20 ans un site de tourisme et de réservations de voyage relativement prospère, c’était sans compter sur l’attaque en justice du propriétaire par le Ministère des Affaires étrangères en 2015, revendiquant la titularité légitime du gouvernement français.

Le Ministère des Affaires étrangères soutient en effet que « France » est un nom de marque déposé et que de ce fait le nom « France.com » lui revient légitimement. On reproche de plus à l’entrepreneur de faire concurrence à Atout France, l’agence chargée du développement touristique du pays.

Le tribunal de grande instance de Paris accédera d’ailleurs à la requête du Ministère et ordonnera le transfert du nom à l’Etat français en juillet 2016, décision confirmée en appel en septembre 2017.

Face à cela, le 22 septembre 2017, la Cour d’appel de Paris a décidé que France.com était en train d’enfreindre les lois relatives à la propriété intellectuelle, alors des contre-mesures ont été déployées à la Cour de cassation. Par la suite, sans compensation et à l’insu de son initiateur, web.com a remis le nom de domaine France.com entre les mains de l’Etat français. De nos jours, le portail de tourisme français France.fr tend vers une interprétation anglophone.

La France dans le box des accusés

L’affaire ne s’arrête bien sûr pas à cela. Après un pourvoi déposé devant la Cour de cassation, M. Frydman conteste la décision en portant plainte le 19 avril dernier auprès du tribunal américain contre la République Française, Atout France, le Ministère de l’Europe et des Affaires étrangères, et le Ministre Jean-Yves Le Drian. Son but : tenter de recouvrer la titularité du nom de domaine France.com mais également de percevoir des dédommagements pour ce qu’il qualifie de « cybersquatting » de la part de l’Etat français. Il estime en effet que la perte de son nom de domaine lui aurait déjà coûté plusieurs millions d’euros.

Swaziland, le pays qui change de nom, et d’extension

swaziland
Source de l’image : OpenClipart-Vectors via Pixabay

Nous avons appris par voix de presse que le Swaziland allait changer de nom à la volonté de son monarque.

En effet, ce petit territoire d’Afrique du Sud n’a pas changé de dénomination à la suite de la décolonisation, cinquante ans plus tôt. Ce sera donc bientôt chose faite, avec le terme eSwatini, le pays des Swazis. Si cette information relève de la géopolitique, elle aura un impact sur l’abréviation des pays, au sein de la norme ISO 3166-1 alpha 2, et son extension évoluera donc ; une situation analogue à celle du Kazakhstan et déjà abordée dans ces colonnes.

Un nouvel exemple qui souligne l’importance de la stabilité du pays dans le choix d’une extension utilisée pour une communication active.

Google rend le chiffrage HTTPS obligatoire pour ses 45 nouveaux TLDs : .dev / .app / .how…

Google rend le chiffrage HTTPS obligatoire pour ses 45 nouveaux TLDs - HSTS
Source de l’image : Sean MacEntee via flickr

Dans un article récent de ce blog, nous avions évoqué l’arrivée de Chrome 68 en juillet 2018 et le HTTP désormais considéré comme « non sécurisé ». Et ce n’est pas la seule arme que Google a dégainé pour favoriser l’adoption massive du chiffrage des sites web !

Vous ne le savez peut-être pas, mais Google a soumis un certain nombre de candidatures auprès de l’ICANN dans le cadre du programme des nouveaux TLDs, et obtenu la gestion en tant que registre de 45 domaines de premier niveau*. A l’instar des .bank et .assurance par exemple, qui imposent certaines règles de sécurité très strictes, Google a annoncé l’implémentation et le pré-chargement HSTS sur les nouveaux TLDs qu’il contrôle et donc rendu obligatoire la mise en place de HTTPS.

Qu’est-ce que HSTS ?

HSTS (HTTP Strict Transport Security), est un moyen pour un site Web d’insister pour que les navigateurs s’y connectent en utilisant le protocole HTTPS chiffré, au lieu du HTTP non sécurisé. Un navigateur qui tente de visiter le site http://www.nameshield.net, par exemple, est redirigé vers une URL qui utilise HTTPS et dit d’ajouter le site à sa liste de sites auxquels il faut toujours accéder via HTTPS. A partir de là, le navigateur utilisera toujours HTTPS pour ce site, quoi qu’il arrive. L’utilisateur n’a rien à faire, qu’il ait accédé au site via un favori, un lien ou simplement en tapant HTTP dans la barre d’adresse.

HSTS a été adopté pour la première fois par Chrome 4 en 2009, et est depuis intégré dans tous les principaux navigateurs. La seule faille dans ce schéma est que les navigateurs peuvent toujours atteindre une URL HTTP non sécurisée la première fois qu’ils se connectent à un site, ouvrant une petite fenêtre pour que les attaquants puissent effectuer des attaques de type Man-in-The-Middle, détournement de cookies ou encore l’attaque Poodle SSLv3 très médiatisée en 2014.

Un Top Level Domain sécurisé dans son ensemble

Le pré-chargement HSTS résout ceci en pré-chargeant une liste de domaines HSTS dans le navigateur lui-même, fermant complètement cette fenêtre. Mieux encore, ce pré-chargement peut être appliqué à des TLDs entiers, et pas seulement à des domaines et sous-domaines, ce qui signifie qu’il devient automatique pour tous ceux qui enregistrent un nom de domaine se terminant dans ce TLD.

L’ajout d’un TLD entier à la liste de pré-chargement HSTS est également plus efficace, car il sécurise tous les domaines sous ce TLD sans avoir à inclure tous ces domaines individuellement. Comme les listes de pré-chargement HSTS peuvent prendre des mois à se mettre à jour dans les navigateurs, le paramétrage par TLD a l’avantage supplémentaire de rendre HSTS instantané pour les nouveaux sites Web qui les utilisent.

Pour utiliser un .app ou un .dev il faudra donc obligatoirement déployer HTTPS

Google rendra donc HSTS obligatoire pour ses 45 TLDs dans les mois à venir. Qu’est-ce que cela signifie ? Des millions de nouveaux sites enregistrés sous chaque TLD seront désormais HTTPS (et les propriétaires de domaines devront configurer leurs sites Web pour passer en HTTPS sous peine de ne pas fonctionner). Pour pouvoir utiliser un nom de domaine en .dev, .app, .ads, .here, .meme, .ing, .rsvp, .fly… il faudra donc acquérir un certificat SSL et déployer HTTPS.

Pour toute question sur ces TLDs, noms de domaine ou certificats SSL, notre équipe se tient à votre disposition.

* Les 45 TLDs de Google : .gle .prod .docs .cal .soy .how .chrome .ads .mov .youtube .channel .nexus .goog .boo .dad .drive .hangout .new .eat .app .moto .ing .meme .here .zip .guge .car .foo .day .dev .play .gmail .fly .gbiz .rsvp .android .map .page .google .dclk .search .prof .phd .esq .みんな .谷歌 .グーグル