Dernières modifications des exigences de base du CA/B Forum affectant les certificats SSL d’une validité de 3 ans

 

À la suite des modifications des exigences de base du CA/B Forum, Namebay et son partenaire GlobalSign doivent mettre à jour sa politique et ses procédures relatives aux certificats SSL afin de se conformer aux deux obligations importantes indiquées ci-dessous.

1) À compter du 1^er mars 2018, la période de validité de tous les certificats SSL sera limitée à 825 jours (27 mois) maximum.

Par conséquent, à partir du 20 avril 2017, nous ne proposerons plus de certificats avec une période de validité de 3 ans afin de limiter l’incidence de cette exigence sur ses clients après le 1^er mars 2018. Nous proposons une date un peu antérieure à celle du CA/B Forum pour éviter les périodes de validité de certificat tronquées en cas de réémission de certificats de trois ans.

2) La vérification de l’organisation et du domaine doit être effectuée dans les 825 jours (27 mois) précédant l’émission ou la réémission du certificat (auparavant, cette période était de 39 mois).

Remarque : ces exigences n’ont aucune incidence pour les clients qui commandent de nouveaux certificats. Cependant, si des certificats sont réémis ou si des SANs sont ajoutés ou supprimés, les informations relatives à l’organisation et au domaine ne devront pas dater de plus de 27 mois. Ces modifications, qui jouent sur la capacité de nos clients à réémettre des certificats, est décrite plus en détail ci-dessous.

Dépréciation des certificats SSL à validation de domaine d’une validité de 3 ans

GlobalSign dépréciera les certificats SSL à validation de domaine d’une validité de 3 ans (y compris DomainSSL et AlphaSSL) pour éviter les scénarios ci-dessous :

• Scénario 1 – à partir du 1^er mars 2018 : un utilisateur réémet un certificat avec une période de validité restante de plus de 27 mois.
• Résultat : le certificat sera réduit à 27 mois puisqu’il s’agit de la période maximale autorisée. Pour éviter la perte de durée de validité des certificats en 2018, GlobalSign a choisi de déprécier les certificats avec une validité de 3 ans dès le 20 avril 2017.

• Scénario 2 – à partir du 20 avril 2017 : un utilisateur tente de réémettre un certificat d’une validité de 3 ans après le délai de 27 mois.
• Résultat : la vérification des domaines doit avoir été effectuée dans les 27 mois qui précèdent, les tentatives de réémission de certificats à validation de domaine seront rejetées. Autrement dit, à partir du 20 avril 2017, toute demande de réémission de certificat SSL à validation de domaine d’une validité de 3 ans, effectuée au-delà de 27 mois après sa date d’émission, sera refusée.

Dépréciation des certificats SSL à validation d’organisation d’une validité de 3 ans

GlobalSign dépréciera les certificats SSL à validation d’organisation d’une validité de 3 ans pour éviter le scénario ci-dessous :

• Scénario 1 – à partir du 1^er mars 2018 : un utilisateur réémet un certificat avec une période de validité restante de plus de 27 mois.
• Résultat : le certificat sera réduit à 27 mois puisqu’il s’agit de la période de validité maximale autorisée. Pour éviter la perte de période de validité des certificats en 2018, GlobalSign a choisi de déprécier dès le 20 avril 2017 les certificats avec une validité de 3 ans.

Dépréciation de la réémission des certificats SSL à validation d’organisation

Pour se conformer aux exigences de base du CA/B Forum, nous avons décidé de désactiver provisoirement la réémission des certificats SSL à validation d’organisation.

Conclusion

Nous sommes convaincus que vous comprendrez qu’il s’agit là d’obligations imposées par le CA/B Forum auxquelles nous sommes tenus de nous conformer.

Nous vous invitons à nous contacter pour toute question à l’adresse tech@namebay.com

 

Vers un web 100% crypté, les nouveaux challenges du HTTPS

Entre mars 2016 et mars 2017, Let’s Encrypt a émis 15 270 certificats SSL contenant le terme « PayPal » ; 14 766 d’entre eux ont été émis pour des domaines menant vers des sites de phishing. C’est le résultat de la récente analyse menée par Vincent Lynch, expert SSL.

Lynch s’est intéressé de près à ce cas à la suite d’un article très intéressant publié par Eric Lawrence (Google Chrome Security Team) en janvier 2017, le visuel ci-dessus est tiré de cet article, dénommé « Certified Malice » qui dénonçait les certificats SSL frauduleux et dénombrait alors « seulement » 709 cas pour Paypal, et bien d’autres sur toutes les plus grandes marques américaines : BankOfAmerica, Apple, Amazon, American Express, Chase Bank, Microsoft, Google…

Quel impact pour l’internaute ?

En Janvier 2017 Google et Mozilla ont mis à jour leur navigateur avec Chrome 56 et Firefox 51, et un changement majeur est intervenu pour les internautes, l’apparition des termes « Sécurisé » ou « Non sécurisé » dans la barre d’adresse.

En 2015, l’initiative Let’sEncrypt, supportée par les grands noms de l’internet (EFF, Mozilla, Cisco, Akamaï…) voyait le jour avec pour objectif de diffuser en masse et gratuitement des certificats SSL au monde entier. Un an et demi plus tard Let’sEncrypt a délivré des millions de certificats, et d’autres initiatives de ce type ont suivi.

Qui dit gratuit, dit peu ou pas de vérification pour délivrer les certificats, et toute une armée de cyber-criminels qui se sont rués vers ceux-ci pour sécuriser leurs contenus illicites : phishing, malware… et afficher le terme « Sécurisé » eux aussi dans la barre d’adresse. Comment l’internaute lambda peut-il facilement différencier le vrai du faux !

Pour mémoire il existe trois niveaux de vérification lors de l’émission des certificats permettant d’afficher HTTPS : Domain Validation (DV) considéré comme de l’authentification faible, Organization Validation (OV) à authentification forte et Extended Validation (EV) à authentification renforcée. Les certificats gratuits sont des DV, et représentent près de 90% des certificats la plupart du temps sur des « petits » sites web. Les certificats OV (9%) et EV (1%) sont peu nombreux mais protègent la quasi-totalité des sites web à très fort trafic. Les GAFA sont tous en OV ou EV par exemple.

Le problème pour l’internaute est l’absence de différenciation dans les navigateurs entre les certificats DV et OV. Ces deux types sont affichés de la même manière étant comme « Sécurisé » alors que les certificats EV affichent le nom du titulaire dans la barre d’adresse.

 

En reprenant le visuel du début de cet article on comprend aisément l’intérêt du EV pour Paypal pour permettre de distinguer facilement le vrai du faux, et c’est la raison pour laquelle Nameshield conseillera systématiquement l’emploi du EV pour les sites vitrines, en particulier pour ses clients exposés au cybersquatting, phishing ou encore contre-façon.

Deux forces qui s’opposent pour l’avenir du HTTPS

Malheureusement les choses ne sont pas aussi simples et là où la logique voudrait qu’on différencie clairement les 3 types de certificat, ou en tout cas au moins deux types (DV/OV), Google ne l’entend pas de cette oreille et souhaite à l’inverse supprimer cette notion d’affichage EV. Chris Palmer (Senior Software Engineer pour Chrome) le confirme à demi-mot dans son article (fort intéressant au demeurant) paru ici.

Nous sommes donc aujourd’hui dans une situation où les Autorités de Certification historiques, Microsoft et dans une moindre mesure Apple font face à Google, Mozilla et Lets’Encrypt dans une vision que l’on peut résumer comme suit :

Vision de Google/Mozilla/Let’sEncrypt :   HTTP = Non Sécurisé HTTPS = Sécurisé

Vision des AC historiques/Microsoft/Apple : HTTP = Non Sécurisé HTTPS DV = pas d’indicateur dans la barre d’adresse HTTPS OV = Sécurisé HTTPS EV = Nom de la société dans la barre d’adresse

 

La discussion est ouverte en ce moment même au sein de l’instance supérieure du SSL qu’est le CAB/forum. On peut facilement comprendre que les Autorités de Certification voient d’un très mauvais œil la fin de la différenciation visuelle entre DV/OV/EV dans les navigateurs, c’est leur raison d’être que de délivrer des certificats à authentification forte, mais est-ce seulement un tort ? Il s’agit quand même de rassurer l’internaute en lui garantissant l’identité du site qu’il visite.

A l’inverse Google et Let’sEncrypt n’hésitent pas à dire que les notions de phishing et de garantie de contenu des sites web ne sont pas du ressort des Autorités de Certification, et que d’autres systèmes existent (par exemple Google Safe Browsing), et qu’en conséquence il faut avoir une vision binaire : les échanges sont cryptés et inviolables (= HTTPS = Sécurisé) ou ils ne le sont pas (= HTTP = Non sécurisé). On peut simplement se demander si au travers de cette vision qui se défend également, ce n’est pas plutôt un problème de sémantique du terme employé : Sécurisé.

Que veut dire « Sécurisé » pour l’internaute ? Est-ce qu’en voyant « Sécurisé » dans sa barre d’adresse il sera enclin à entrer ses login/password ou son numéro de carte bancaire ? On peut penser que oui et dans ce cas le risque actuel est bien présent. Kirk Hall (Director Policy and Compliance – SSL, Entrust) a fait une intervention remarquée à la dernière conference RSA sur ce sujet, si vous avez un peu de temps, l’enregistrement est ici.

Enfin il ne faut pas négliger le poids de l’industrie financière ni des grandes marques qui voient d’un très mauvais œil l’augmentation du risque de fraude en ligne et que ne peut décemment pas totalement ignorer Google.

Comment rassurer l’internaute ?

Pour le moment nous ne pouvons que vous encourager à opter pour les certificats Extended Validation pour vos sites vitrine et ou de e-commerce afin de faciliter la tâche des internautes et à rester à l’écoute de ce qui se passe sur le web ; Rassurer et éduquer également les internautes en n’hésitant pas à mentionner sur vos sites les choix que vous faites en termes de sécurité et d’authentification ;

Au même titre que vous surveillez certainement les dépôts de nom de domaine sur vos marques, vous pouvez aujourd’hui également surveiller les enregistrements de certificats, et ce pour réagir rapidement.

Et en tant qu’internaute, lorsque le terme « sécurisé » et mentionné dans la barre d’adresse, systématiquement contrôler les détails du certificat pour voir qui en est le titulaire.

Christophe Gérard
Business Development Expert SSL – Nameshield group

Augmentation sur le .RU/.РФ

 

Le Centre de Coordination pour l’extension .RU/.РФ a annoncé qu’une augmentation conséquente serait réalisée sur les tarifs d’enregistrement, renouvellement et transfert à compter du 1er juillet prochain.
Discutée depuis 2012 en interne, cette augmentation devrait être de l’ordre de 71% !
Le sondage réalisée par le Registre sur cette augmentation a montré que cela ne devrait pas impacter le nombre de noms de domaine enregistrés.
Titulaires de .RU, nous vous invitons à renouveler vos noms de domaine sur www.namebay.com avant la date butoire afin de ne pas être touché par la hausse cette année.

Intervention sur nos services

Le lundi 3 avril à partir de 18:30 heure de Paris, notre Equipe Technique va effectuer une intervention sur notre réseaux qui pourrait entrainer de micro-coupures.
Nos Equipes mettent tout en œuvre pour que l’impact de cette intervention soit minimal.

Pour toute question, n’hésitez pas à nous contacter à l’adresse contact@namebay.com

Alerte sur les .RU

Le Registre du .RU, RU-CENTER appelle les titulaires de .RU à la plus grande vigilance.

En effet, certains détenteurs de .RU ont reçu un message d’escrocs se faisant passer pour le RU-CENTER, leur demandant de placer un fichier malveillant à la racine de leur site Internet, sous prétexte de vérifier les droits de propriété sur le domaine.
Ces messages sont frauduleux, envoyés sur des adresses e-mail récupérées dans les bases publiques.

Le Registre du .RU indique qu’il ne procède jamais de cette façon pour vérifier l’identité des titulaires de .RU. Il rappelle qu’il ne demande jamais non plus de mots de passe par e-mail.

Vous avez reçu un e-mail de ce type ou avez un doute sur la provenance d’un e-mail vous demandant de renouveler votre nom de domaine ?
L’Equipe de Namebay se tient à votre disposition pour toutes questions à l’adresse contact@namebay.com

Le .TEL lève les restrictions DNS

Le 13 mars 2017, le Registre du .TEL, TELNIC, va lever les restrictions de DNS sur son extension. Ainsi, les titulaires de .TEL auront dorénavant le choix pour l’hébergement de leur domaine et son utilisation.

En effet, jusqu’à présent, le .TEL avait la vocation d’être « une carte de visite virtuelle » permettant à chacun de donner accès à ses coordonnées sous une forme normée par le Registre. Les informations étaient intégrées directement dans le DNS et n’étaient pas hébergées sur un serveur comme le sont habituellement les sites Web.

Les titulaires de .TEL auront donc maintenant le choix entre ces deux solutions.
Vous pouvez enregistrer votre .TEL sur www.namebay.com au tarif de 16 € HT/an.
Déjà titulaire d’un .TEL ? Contactez-nous si vous souhaitez changer de formule !

Game Over HTTP, Welcome HTTPS

Chrome 56 et Firefox 51 sont arrivés et sonnent le glas de l’ère du HTTP.
Annoncée depuis longtemps, l’apparition des termes « Non sécurisé » dans la barre d’adresse est maintenant effective pour toutes les pages contenant la saisie de mots de passe qui seraient encore en HTTP.
Plus qu’un long discours, voilà à quoi cela peut ressembler sur un site à très fort trafic :

Nous vous laissons imaginer les conséquences sur l’image de marque qui n’offre pas la sécurité attendue à ses internautes peu enclins à poursuivre leur navigation avec de telles alertes : perte de confiance, baisse des taux de clic et conversion, augmentation du taux de rebond et, au final, perte de chiffre d’affaires au profit d’autres sites web. Dramatique.

N’oublions pas non plus que les pages concernées pour l’instant sont uniquement celles contenant des données à sécuriser (mot de passe, paiement en ligne), mais que la volonté des deux géants du web est de considérer à l’avenir toutes les pages en HTTP comme « Non Sécurisé », affiché en rouge.

Pas de calendrier annoncé pour l’instant, mais la machine est en marche comme l’a confié Emily Schechter, chef de produit Chrome Security dans son fameux post de septembre 2016 :

“Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP sites that transmit passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure,”

Comment s’organiser

Le trafic HTTPS mondial vient de passer le cap symbolique des 50% (50,15% à fin janvier 2017, contre 39% un an plus tôt), porté notamment par l’initiative Let’s Encrypt. Actuellement, au niveau mondial le protocole HTTPS est déployé sur plus de la moitié du top 100 des sites figurant sur l’indice Alexa et 44 % d’entre eux l’ont activé par défaut.

Mais la France est en retard (voir notre article précédent sur le sujet), en particulier dans le monde de l’entreprise où l’inertie est importante, de même que la peur du déréférencement ou de la chute des revenus publicitaires.

Demain tous les sites web seront concernés, du site web de vente en ligne au simple site vitrine, tous devront passer au HTTPS pour rassurer les internautes. Si la réflexion n’est pas déjà lancée au sein des équipes web et marketing de votre entreprise, il est plus que temps de se positionner.

• Former et informer vor équipes : HTTPS, certificats SSL ;
• Définir votre stratégie de certification : Autorité de Certification, types de certificats, workflow ;
• Identifier l’ensemble des sites web de votre société… et définir les priorités d’action :

1-Sites contenant un espace de saisie de données personnelles (formulaire, login, mot de passe, récupération de mot de passe, achats en ligne) => vérifier la présence de httpS
2-Sites corporate, vitrine, flagship : prévoir de passer en httpS par défaut en 2017
3-Sites secondaires

• Préparer la transition vers le httpS avec vos équipes web
• Effectuer la transition vers le httpS des sites identifiés et surveiller le bon déroulement
• Gérer vos certificats

Namebay vous accompagne

Notre équipe d’experts SSL vous accompagne dans le choix de vos certificats SSL .

Nous mettons également à votre disposition les outils nécessaires à la prise de décision (audit, analyse, conseil).

Namebay est fournisseur reconnu de solutions de sécurisation de vos sites web : certificats SSL, DNS, registry lock, n’hésitez pas à contacter nos équipes pour plus de renseignements.

Le JDN vient de publier un article très intéressant sur le décollage du HTTPS sur le top 100 des sites les plus visités en France. Il en ressort que 44/100 sont maintenant en HTTPS par défaut (dont 12 dans le top 20) et 54% des pages vues sont en HTTPS. C’est une bonne nouvelle pour les internautes français MAIS…

…on peut surtout remercier les acteurs américains. Sur le top 20, le seul acteur français aujourd’hui en HTTPS par défaut est Leboncoin.fr ! Si on pousse jusqu’au top 50, on ne trouve que quatre acteurs français supplémentaires : La Poste, Le Crédit Agricole, Mappy et Service Public.fr. Sur le top 100, 44 acteurs sont en HTTPS par défaut, dont seulement 15 acteurs français. Du côté du e-commerce c’est encore pire avec 33 acteurs français dans le top 40 mais seulement 7 en HTTPS par défaut.

La France est à la traine… et doit réagir

Google et Firefox, les deux fers de lance de la généralisation du HTTPS, continuent à annoncer des mesures toujours plus fermes en vue de l’adoption généralisée du HTTPS par défaut :

• bonus sur le référencement naturel,
• « malus » au cours de la navigation avec de plus en plus d’alertes,
• limitation de fonctionnalités au seul HTTPS : HTTP2, géolocalisation, utilisation de la caméra, auto-remplissage des formulaires…
• dépréciation des versions trop anciennes : SHA1 remplacé par SHA256

Chrome 56 arrive en Janvier 2017 avec une première série d’alertes dans les barres d’adresse pour les pages de connexion et contenant des champs de carte de crédit… et annonce déjà la couleur pour la suite avec la volonté clairement affichée d’une alerte pour tous les sites en HTTP (voir visuels ci-dessous).

Firefox n’est pas en reste et annonce la mise en place d’une alerte sur les saisies de mot de passe

Et d’autres acteurs majeurs comme WordPress, Apple ou Microsoft suivent le mouvement.

Pourtant le HTTPS peine à s’imposer pour la plupart des acteurs français du Web. Pourquoi ?

La transition d’un site Web en HTTPS par défaut n’est pas une mince affaire et deux freins importants existent encore : le risque d’un déclassement en termes de SEO si la transition est mal opérée, et certaines régies publicitaires qui restent en sources HTTP. Le trafic et les revenus publicitaires, le nerf de la guerre pour beaucoup de sites web.

Et donc, on attend ! On attend le dernier moment en espérant que Google et Firefox reculent ? C’est peu probable et le calendrier se resserre. Même si Google n’a pas encore annoncé de date pour la mise en place des alertes sur le HTTP, il y a fort à parier qu’ils le feront le plus tôt possible, et les conséquences risquent d’être désastreuses s’il faut agir dans l’urgence.

Nous recommandons d’étudier au plus tôt un calendrier de transition vers le HTTPS par défaut, projet à mener en étroite collaboration avec les équipes web et référencement, pour tous les sites vitrine dans un premier temps et pour l’ensemble des activités web dans un second.

Les équipes de Namebay pourront vous accompagner en termes de conseil pour la mise en place et la gestion des certificats qui permettront d’afficher le HTTPS.

Christophe Gérard
Business Development Expert SSL – Nameshield group

La Tanzanie légifère sur l’utilisation du .co.tz et passe à l’action !

 

La TCRA (Tanzania Communications Regulatory Authority) a rendu obligatoire en 2011 l’utilisation  d’un nom de domaine en .TZ pour tout business sur le territoire tanzanien. En effet, la loi Electronic and Postal Communications Act oblige toute personne ayant une activité sur internet en Tanzanie à utiliser l’extension locale.

Bien que peu respectée en pratique, certains en ont tout de même fait les frais récemment, comme le fondateur du site Jamii Forums, arrêté en décembre non seulement pour obstruction à la justice mais aussi pour ne pas avoir respecté cette obligation.

Ainsi, l’utilisation d’un .com, .net, ou encore .biz qui était monnaie courante jusqu’alors doit impérativement être remplacée par un .co.tz (la plus utilisée) pour pouvoir continuer à communiquer sans difficulté dans ce pays de 51 millions d’habitants (le classant à la 24^e  position sur 203 pays).

En cas de présence marchande sur le territoire tanzanien ou volonté de s’y développer, et afin d’éviter tout risque de cybersquatting, Nameshield recommande l’enregistrement d’un .co.tz sur vos marques principales et stratégiques, à l’identique. Une présence locale peut vous être fournie par Nameshield si nécessaire.

Pour rappel, il est également possible d’engager une action UDRP (procédure de récupération d’un nom de domaine devant l’OMPI) pour récupérer un nom de domaine enregistré en .co.tz.

Pour toute information supplémentaire, n’hésitez pas à contacter votre commercial Namebay ou écrire à contact@namebay.com.

Perrine DELERUE
Consultante Juriste – Nameshield Group

Attaques contre les sites Joomla

Des failles récemment patchées responsables

Les sites utilisant Joomla, deuxième système de gestion de contenu (CMS) le plus populaire après WordPress, sont victimes depuis mercredi 26 octobre d’attaques qui ont rapidement augmenté en nombre.

Tout a commencé par la découverte de 3 failles qui permettaient, sans rentrer dans les détails techniques, aux personnes mal intentionnées de jouer avec la création de comptes sur votre site web, de modifier les utilisateurs existants et de s’octroyer des privilèges de comptes. Malgré un correctif mis à disposition le 25 octobre, de nouvelles failles ont été trouvées par les pirates et de nombreuses attaques se sont produites dans les jours à venir.

Pour s’assurer que votre site ne soit plus vulnérable et qu’il n’ait pas été infecté, le CMS doit impérativement être mis à jour dans sa version 3.6.4.
Il est également nécessaire de vérifier de la création d’éventuels nouveaux comptes « pirates » ainsi que les journaux d’accès du site  pour repérer les demandes qui contiennent la séquence « task = user.register ».

Sources :

Joomla
Developpez.com
Le Monde Informatique