Les certificats SSL assurent le chiffrement et l’intégrité des données échangées entre un navigateur et un serveur web. Il existe différents niveaux de certificats, Extended Validation (EV), Organizational Validation (OV) et Domain Validation (DV), qui varient en fonction du degré d’authentification. Le certificat SSL de type Extended Validation fournit le plus haut niveau d’authentification SSL. Son obtention passe par un processus de vérification d’identité complet et normalisé à l’échelle mondiale ratifié par le forum CA/Browser Forum.
Le certificat SSL EV active la sécurité HTTPS et le cadenas, maintenant gris, dans la barre d’adresse du navigateur, tout comme les certificats DV et OV. Le coût et le temps supplémentaires consacrés à la vérification rendent plus difficile l’obtention de certificats de niveau EV pour les sites de phishing. Les internautes peuvent donc utiliser ce certificat comme marque de confiance et se sentent plus en sécurité lorsqu’ils communiquent et effectuent des achats.
Le 12 juin 2007, le CA/Browser Forum ratifie officiellement la première version des directives SSL Extended Validation qui entrent en vigueur immédiatement. L’approbation formelle clôture alors avec succès plus de deux ans d’efforts et fournit un cadre pour l’identité de site Web afin d’accroitre la confiance sur Internet.
La plupart des principaux navigateurs créent des indicateurs visuels pour les pages chargées via HTTPS et sécurisées par un certificat EV peu après la création de la norme : ils affichent l’identité validée, soit une combinaison du nom de l’organisation et de la juridiction, dans la barre URL. Safari pour iOS, Windows Phone, Firefox pour Android, Chrome pour Android et iOS, ajoutent également ces indicateurs.
En mai 2018, Google annonce son intention de repenser les interfaces utilisateur de Google Chrome afin de ne plus mettre l’accent sur les certificats EV. Chrome 77, sorti en 2019, supprime l’indication du certificat EV de l’omnibox. Firefox 70 fait de même et retire la distinction dans la barre d’URL : les certificats EV et DV sont affichés de la même manière, mais le statut du certificat EV peut toujours être consulté en cliquant sur l’icône cadenas, puis en vérifiant le nom de l’entité légale sous « certificat ».
Affichage d’un certificat EV dans Firefox
L’utilisation croissante des appareils mobiles et la suppression de l’indicateur visuel EV par les navigateurs a fait diminuer de manière significative l’intérêt de certaines entités à utiliser ce niveau de sécurité, mais l’EV a toujours une très grande importance dans notre quotidien.
Aujourd’hui les sites de phishing représentent malheureusement toujours une menace majeure pour les sites web et services en ligne légitimes. Ces « hameçonneurs » utilisent des certificats DV, généralement obtenus auprès d’un service SSL gratuit qui ne mène pas de contrôles de phishing adéquats, afin que leurs sites paraissent plus fiables. Ils trompent ainsi facilement les victimes peu méfiantes et les incitent à communiquer des informations financières ou personnelles.
Il a été remarqué une très forte hausse du phishing depuis Mars 2020, début du confinement et du télétravail pour beaucoup de personnes : le volume des sites de phishing a augmenté de 47 % pour le premier trimestre de 2020, et 82,7% des attaques de phishing ont utilisé des certificats SSL DV. Ce problème ne fait que s’accroitre et accentue la nécessité de vérifier les identités en ligne.
Un certificat SSL ou TLS authentifie un serveur et chiffre les données échangées avec celui-ci. Les données sont ainsi échangées en confiance, entre deux acteurs dont l’identité est connue. Les données échangées ne peuvent être espionnées ni altérées par un tiers : confidentialité et intégrité.
Téléchargez cette fiche « 5 minutes pour comprendre : les certificats SSL / TLS » depuis notre page ressources.
Selon un rapport conjoint d’iYouPort, de l’Université du Maryland et du Great Firewall Report, les connexions TLS utilisant l’extension préliminaire SNI chiffrée (ESNI) sont bloquées en Chine. Un nouveau pas vers la censure et une volonté de pouvoir tracker les internautes.
Qu’est-ce que le SNI (Server Name Indication) ?
Lorsqu’un internaute consulte un site web en HTTPS://, cela signifie que le site est sécurisé par un certificat SSL/TLS. La consultation du site web commence par l’établissement de la connexion sécurisée, le « handshake ». Cette poignée de main se déroule en plusieurs étapes et vise à vérifier le certificat et établir le niveau de chiffrement de la connexion. Le premier message d’un handshake TLS est appelé « client hello ». Avec ce message, le client demande à voir le certificat TLS du serveur web. Le serveur doit joindre le certificat à sa réponse.
Présenter le bon certificat ne pose aucun problème dans le cas d’hébergements dédiés : une adresse IP, un seul certificat, contenant éventuellement plusieurs SAN (Subject Alternative Name) appartenant à la même organisation. Le problème intervient lors d’hébergements mutualisés où l’hébergeur dispose de la même adresse IP mais souhaite installer plusieurs certificats différents sous peine de devoir être le propriétaire du certificat en ajoutant des SAN pour tous ses clients. Pratique peu recommandée.
Le SNI répond à cette demande spécifique des hébergeurs et leurs hébergements mutualisés. Avec le protocole SNI, le client indique le nom de l’hôte (hostname) avec lequel il tente de démarrer une négociation TLS. Cela permet au serveur de présenter plusieurs certificats pour la même adresse IP (mais des noms d’hôte différents). Le SNI pourrait être comparé au numéro d’appartement d’une adresse postale : un immeuble comprend plusieurs appartements, et chaque appartement doit donc être identifié par un numéro différent. De même, si le serveur est indiqué par l’adresse IP, les appareils clients doivent intégrer le SNI dans leur premier message adressé au serveur pour indiquer quel site web (quel appartement) ils essaient d’atteindre.
Qu’est-ce que l’ESNI (Encrypted Server Name Indication) ?
L’établissement d’une connexion TLS chiffrée commence à la fin du handshake. Problème, le SNI n’est donc pas chiffré, car le message « client hello » est envoyé au début du handshake TLS. Un pirate peut reconstituer le parcours d’un internaute en lisant la partie SNI du handshake, même s’il n’est pas en mesure de déchiffrer les communications ultérieures. Le principal intérêt pour le pirate étant de pouvoir flouer l’internaute en créant un site de phishing. Par ailleurs, les géants du web aiment la confidentialité, et souhaitent préserver la confidentialité des données de navigation des utilisateurs. L’ESNI est donc né.
L’ESNI (Encrypted server name indication) chiffre la partie Server Name Indication (SNI) dans le handshake TLS. L’extension ESNI est accessible via la dernière version du protocole TLS, 1.3, de plus en plus largement adopté aujourd’hui. Le principe est de récupérer une clé de chiffrement via le DNS (qui lui-même peut être sécurisé via DNS via HTTPS). Encore à l’état de draft, certains gros hébergeurs l’implémentent déjà.
Et la Chine dans tout ça ?
Dans leur rapport, l’iYouPort, l’Université du Maryland et le Great Firewall Report, détaillent comment la Chine voit d’un très mauvais œil le chiffrement du handshake. Cela empêche effectivement l’outil de surveillance Great Firewall du gouvernement chinois de voir ce que font les internautes en ligne. La Chine a donc décidé de purement et simplement bloquer les connexions HTTPS établies via la dernière version du protocole TLS (la 1.3) associées à ESNI. De plus, les adresses IP impliquées dans la connexion sont bloquées temporairement pendant deux à trois minutes.
Des méthodes de contournement existent… mais jusqu’à quand ?
Les trois organisations semblent avoir trouvé des méthodes de contournement à appliquer côté client (dans les applications et les logiciels) ou côté serveur pour contourner le blocage actuel mis en place par le Great Firewall. « Malheureusement, ces stratégies spécifiques ne constituent peut-être pas une solution à long terme : à mesure que le jeu du chat et de la souris progresse, le Great Firewall continuera probablement à améliorer ses capacités de censure », écrivent les trois organisations dans leur rapport.
Let’s Encrypt a récemment
fait parler dans le petit monde des certificats TLS, en révoquant soudainement 3 048 289
certificats qui n’auraient pas dû être délivrés. Un bug dans leur logiciel de
validation empêchait les contrôles des enregistrements CAA, et les certificats
en question n’auraient pas dû être initialement délivrés. Des perturbations
importantes ont résulté de cette révocation massive, mais il est difficile de
se plaindre d’un service gratuit.
On me demande souvent ce que je
pense de Let’s Encrypt, et j’ai toujours cette même réponse : Let’s
Encrypt a fait énormément pour chiffrer le web, mais met à mal la sécurité du
web. Le chiffrement permet d’assurer la confidentialité (personne ne peut
espionner) et l’intégrité (personne ne peut modifier) des échanges. Mais le
chiffrement seul ne peut suffire si je n’ai aucune garantie de
l’identité de celle ou celui avec qui j’échange (légitime ou frauduleux ?)…
Et c’est bien là tout le problème.
En 2015, l’initiative Let’s
Encrypt, 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. Plus de cinq ans après sa
création, l’organisation sécurise 190 millions de sites web et vient d’annoncer
avoir distribué un milliard de certificats. Le cap a été franchi le 27 février
2020. C’est indiscutablement une belle performance.
96% du web chiffré en janvier 2020
En 2015, moins de la moitié du
trafic web était chiffrée, pour grimper à 96% en janvier 2020. Bien sûr Let’s
Encrypt n’est pas le seul acteur responsable de cet essor. Edward Snowden a
lancé la première alerte, Google s’est largement engouffré dans la brèche,
entre politique de référencement et modification des indicateurs de sécurité
web. Mais en mettant à la disposition de tous, des certificats gratuits et
basés sur un système largement automatisé, Let’s Encrypt a démocratisé le
chiffrement… et mis aux oubliettes la notion d’identité.
Pas d’identité, pas de sécurité
Le credo de Let’s Encrypt est la
simplicité, pour « simplifier à
l’extrême le déploiement du HTTPS et en finir avec sa bureaucratie horriblement
complexe » (dixit l’EFF dans la campagne de lancement). La bureaucratie
horriblement complexe a pourtant une raison d’être : l’authentification
forte, garante de l’identité du titulaire du certificat. Peut-être pas une
garantie absolue de légitimité, pas une garantie de contenu non plus, mais la
garantie d’une société enregistrée, légitimement propriétaire du nom de domaine
concerné et avec un certificat validé selon une procédure drastique.
Let’s Encrypt, se contente de
vérifier le contrôle du nom de domaine (DV, Domain Validation). Il suffit de
cliquer sur un lien dans un email ou de renseigner un record TXT sur la zone
DNS du nom de domaine. Or l’enregistrement de noms de domaine dans la plupart
des TLD est purement déclaratif. Il est assez facile d’enregistrer un nom de
domaine, de demander un certificat à Let’s Encrypt et de publier un site web en
HTTPS://.
Résultat des courses ?
En cinq ans, l’ensemble des sites de phishing et sites frauduleux sont passés en HTTPS://. Dès 2016, Vincent Lynch alertait sur ce problème, 15 270 certificats contenant le terme « Paypal » avaient été émis par Let’s Encrypt, dont 14 766 frauduleux.
Le marché a été tiré vers le bas
en termes de niveau d’authentification. Let’s Encrypt est loin d’être le seul
responsable, Google et Mozilla, du haut de leurs 70% de parts de marché, ayant
largement soutenu l’initiative, les gros hébergeurs du Cloud ont suivi, de même
que les Autorités de Certification, challengées sur les prix. Nous avons
aujourd’hui un web sécurisé avec 77% (novembre 2019) de certificats dont la
légitimité du propriétaire n’est pas vérifiée.
L’authentification forte change la donne
Le web est devenu chiffré par
défaut. Est-il plus sûr pour autant ? Rien n’est moins sûr. L’internaute,
éduqué depuis 20 ans à vérifier la présence du cadenas dans sa barre d’adresse,
fait confiance à un web dont tous les sites frauduleux affichent le cadenas de
sécurité. L’Internet est aujourd’hui
confidentiel, mais il n’est pas sûr pour autant.
Il est urgent de revenir à l’authentification forte. L’authentification forte garantit un ensemble d’étapes obligatoires, drastiques et contrôlées pour l’obtention des certificats. Les procédures sont édictées par le CA/B Forum, renforcées régulièrement et suivies d’audit des Autorités de Certification.
23% des certificats sont encore
délivrés sur la base de l’authentification forte, la plupart dans le monde de
l’entreprise où les RSSI poussent pour la préserver. Nous devons tous nous
appuyer sur eux, et soutenir les initiatives supportant les certificats OV
(Organization Validation) et EV (Extended Validation), en particulier EV pour
garantir l’identité des sites visités par les internautes.
Si l’identité sur Internet semble avoir été quelque
peu oubliée depuis quelques temps au profit de la confidentialité, elle risque
de revenir rapidement sur le devant de la scène, poussée notamment par les
internautes et le besoin de protection des données personnelles.
Apple a annoncé cette semaine que la durée de vie maximale des certificats SSL/TLS sur ses appareils et son navigateur Safari serait limitée à 398 jours (1 an, et 1 mois pour couvrir la période de renouvellement). Le changement, annoncé par Apple lors de la réunion CA / Browser Forum à Bratislava, en Slovaquie, entrera en vigueur pour les certificats émis après le 31 août 2020.
L’annonce d’Apple fait suite à un échec du vote du CA/B Forum sur les certificats d’un an (bulletin SC22), qui s’est tenu en août 2019, et reflète une tendance continue à raccourcir la durée de vie des certificats. A la suite de ce vote, Google avait d’ailleurs exprimé son intention de réduire la durée de vie des certificats en dehors du cadre du CA/B forum si celui-ci ne se positionnait pas rapidement. Cette annonce est une demi-surprise, nous aurions plutôt pensé que Google ou Mozilla ferait le premier pas.
Quelles conséquences pour les sociétés et leurs certificats SSL/TLS?
La validité plus courte est-elle une bonne chose?
Plus la période de validité
d’un certificat est courte, plus le certificat est sûr. En exigeant le
remplacement des certificats sur une période plus courte, les mises à jour de
sécurité sont apportées aux certificats, elles se déploient plus rapidement. La
durée de vie de la clé privée d’un certificat, plus courte, est aussi une forte
recommandation des acteurs de la sécurité en ligne afin de limiter la durée
potentielle d’une fraude suite à une compromission.
D’un point de vue sécurité,
tout le monde s’accorde à dire qu’une réduction de la durée de vie des
certificats est une bonne chose. Le problème se situe du côté opérationnel avec
les conséquences annoncées de cette réduction : plus d’interventions sur
les certificats, donc une plus grande complexité dans le maintien d’un
inventaire à jour et le besoin d’une organisation optimale avec les partenaires
pour l’émission des certificats.
Faut-il tenir compte de l’annonce d’Apple ?
Safari est l’un des deux principaux
navigateurs web, avec 17,7% en janvier 2020, derrière Google Chrome (58,2%) et
devant Microsoft Internet Explorer et Edge (7,1%). Il parait difficile de faire
fi de cette annonce qui touchera 1/5 des internautes, qui plus est si Google
suit, il vaut mieux anticiper et se préparer. C’est d’ores et déjà le conseil
de Nameshield.
Ce qu’il faut garder à l’esprit
Les certificats émis avant le 1er septembre 2020 ne sont pas affectés par cette modification. Ils resteront valides pendant toute la période de deux ans et n’auront pas besoin d’être modifiés ou remplacés. Tous les certificats émis le 1er septembre ou après devront être renouvelés chaque année pour rester fiables par Safari.
Il faut donc se préparer à
passer à des certificats d’une durée d’un an maximum contre deux actuellement.
S’appuyer sur un partenaire et des outils efficaces est plus que jamais
indispensable.
Vers la fin de la corrélation entre l’authentification et la gestion technique des certificats
Ce qui semble se dessiner au
sein du CA/B Forum est le fait de permettre une durée d’authentification
identique à celle que l’on connait aujourd’hui (deux ans) tout en forçant les
certificats à être remplacés plusieurs fois durant cette même période.
Les principales Autorités de
Certification, les organismes qui délivrent les certificats, anticipent ces
changements et travaillent sur plusieurs systèmes d’automatisation du cycle de
vie des certificats. Elles limiteraient ainsi le besoin de passer par une
procédure de réauthentification potentiellement lourde à chaque remplacement.
Les entreprises pourraient remplacer leurs certificats autant de fois qu’elles
le souhaiteraient durant cette période. Cela permettrait notamment d’anticiper
d’éventuelles nouvelles réductions de la durée de vie maximale des certificats.
La tendance est également à la
mise en place d’outils d’automatisation pour le maintien d’un inventaire précis
des certificats d’une part et la réinstallation technique de l’autre.
Nameshield suit de près ces différentes évolutions et vous permettra de
continuer à travailler en toute confiance.
Notre équipe se tient également à votre disposition pour anticiper ces changements et répondre à vos éventuelles questions.
Navigateurs et Autorités de Certification, le combat continue.
Source de l’image : TheDigitalArtist via Pixabay
2019 fut une année bien remplie, avec un renforcement des divergences de point de vue entre fabricants de navigateurs et Autorités de Certification, l’explosion du nombre de sites de phishing chiffrés en HTTPS et l’avancée significative sur la dépréciation de TLS v1.0.
Les débats autour de la
validation étendue, plus généralement du traitement visuel des certificats dans
les navigateurs, et de la réduction de la durée des certificats ont pris une
place prépondérante. Aucune de ces conversations n’est terminée, aucun
consensus ne semble se dessiner, 2020 s’annonce comme une année chargée. Place
à l’anticipation…
Le sort d’Extended Validation sera-t-il fixé ?
2019 a vu les principaux
navigateurs cesser d’afficher la fameuse barre d’adresse en vert avec le
cadenas et le nom de l’entreprise, le tout au profit d’un affichage classique
et unique, ne tenant plus compte du niveau d’authentification des
certificats :
Les discussions sont pour autant toujours en cours au niveau du CA/B forum, comme au sein du CA Security Council. Ces deux instances de régulations des certificats chercheront en 2020 un moyen intuitif d’afficher les informations d’identité des sites Web.
Historiquement approuvé par tous,
notamment par l’industrie financière et les sites comprenant des transactions,
EV (l’acronyme pour Extended Validation) a été la cible de Google en 2019. Les
autres navigateurs, sous l’influence de Google, entre Mozilla financé par
Google et Microsoft et Opera basés sur Chromium open source, ont suivi dans
cette direction. Seul Apple continue à afficher EV.
Pour les navigateurs, la question
est de savoir si TLS est ou non le meilleur moyen de présenter les informations
d’authentification des sites web. Il semble que non. Google part du principe
que ce n’est pas aux Autorités de Certification de décider du contenu légitime
d’un site web et souhaite l’utilisation des certificats à des seules fins de
chiffrement.
Bien sûr les Autorités de Certification voient les choses différemment. Certes on peut y voir une réaction purement mercantile, les certificats EV sont bien plus chers. On peut aussi se demander l’intérêt de l’authentification au-delà du chiffrement. La réponse semble se trouver dans les statistiques ahurissantes des sites web de phishing chiffrés en HTTPS. Les navigateurs ont pour l’instant imposé un web chiffré certes… mais plus authentifié !
2020 sera donc l’année des
propositions de la part des Autorités de Certification : fournir une
meilleure authentification, en incluant les identifiants d’entité juridique, en
suivant la voie de la PSD2 en Europe… Une chose est sûre, l’identité n’a
jamais été aussi critique sur Internet et il incombe à toutes les parties
intéressées de trouver une solution, y compris aux navigateurs de trouver un
moyen d’afficher l’authentification forte des sites. A suivre…
Des certificats d’une durée plus courte : vers des certificats d’un an
825 jours, soit 27 mois ou encore 2 ans, la durée maximale autorisée actuellement pour les certificats SSL. Pour autant, depuis 2017 et une première tentative au sein du CA/B forum, l’industrie se dirige vers une réduction de cette durée à 13 mois (1 mois supplémentaire pour couvrir la période de renouvellement).
Google et les navigateurs sont revenus à la charge en 2019 avec un autre vote soumis au CA/B forum, là encore rejeté mais à une moins vaste majorité. Le marché bouge. Des acteurs comme Let’sEncrypt proposent des certificats d’une durée de 3 mois, d’autres souhaitent plutôt garder des durées longues pour éviter les surcharges d’intervention sur les serveurs. Une chose est sûre, le marché ne dispose pas encore des systèmes d’automatisation pour rendre plus simple la gestion et l’installation des certificats, un délai d’un ou deux ans supplémentaires serait sinon souhaitable, en tout cas judicieux.
Mais tout ça est sans compter sur
Google qui menace d’agir de manière unilatérale si le régulateur ne suit pas…
certainement en 2020.
De TLS 1.0 à TLS 1.3 : marche en avant forcée
Prévue pour janvier 2020, Microsoft, Apple, Mozilla, Google et Cloudflare ont annoncé leur intention de déprécier la prise en charge de TLS 1.0 (protocole créé en 1999 pour succéder au SSL 3.0, devenu fortement exposé) et TLS 1.1 (2006), tous deux en souffrance aujourd’hui d’une trop grande exposition à des failles de sécurité.
Si TLS 1.2 (2008) est toujours
considéré comme sûr aujourd’hui, le marché semble vouloir pousser rapidement
pour TLS 1.3, la version la plus récente de la norme, finalement publiée à
l’été 2018. TLS 1.3 abandonne le support des algorithmes trop faibles (MD4,
RC4, DSA ou SHA-224), permet une négociation en moins d’étapes (plus rapide),
et réduit la vulnérabilité aux attaques par repli. En termes simples, c’est le
protocole le plus sûr.
Petit problème cependant, le
passage à l’action de nombreux sites web. Début 2019, seuls 17% des sites web du
Alexa Top 100 000 prenaient en charge TLS 1.3, tandis qu’un peu moins de 23%
(22 285) ne supportaient même pas encore TLS 1.2. Si la décision de déprécier
les anciennes versions de protocole est une bonne décision, la forme adoptée
par les grands acteurs du web peut être critiquée, notamment par son caractère
unilatéral. En attendant, préparez-vous, nous y allons tout droit.
La menace de l’informatique quantique
Les entreprises parlent de plus
en plus de l’informatique quantique, y compris Google. Mais la réalité est la
suivante, alors que le quantum va avoir un impact sur notre industrie, ce ne
sera certainement pas en 2020, ni pendant au moins une décennie. Il y a encore
de nombreuses questions auxquelles il faut répondre, telles que: Quel est le
meilleur algorithme pour la résistance quantique? Personne n’a cette réponse et
tant qu’il n’y aura pas de consensus dans l’industrie, vous ne verrez aucune
solution quantique en place.
L’IoT gagne du terrain, mais le manque de sécurité continue d’être problématique
L’IoT est un succès, mais un
certain nombre de déploiements sont retardés en raison d’un manque de sécurité.
En 2020, les fournisseurs de services cloud fourniront ou travailleront en
partenariat avec des sociétés de sécurité pour fournir un approvisionnement et
une gestion sécurisés des appareils, ainsi qu’un écosystème IoT sécurisé
général, pour leurs clients.
Les cadres réglementaires pour la fabrication et les déploiements de l’IoT seront très certainement dirigés par l’UE, même si nous assisterons également à une augmentation aux États-Unis. Les attaques, les compromissions et les piratages IoT continueront, malheureusement. De plus, les normes de sécurité ne seront pas respectées et nous ne serons même pas proches d’un pourcentage plus élevé d’appareils sécurisés. Pourquoi ? Les fabricants d’équipement d’origine (FEO) ne sont toujours pas disposés à payer les coûts impliqués ou à les répercuter sur les consommateurs, de peur de perdre des ventes.
Les lois de chiffrement en Chine créeront beaucoup d’incertitude
Au cours des dernières années,
une partie de la transformation numérique du monde a entraîné la codification
des droits et restrictions des données dans des lois nationales et des
organisations régionales. PSD2, RGPD, CCPA, LPRPDE… un vrai casse-tête pour les
entreprises internationales face aux normes réglementaires et à la conformité.
Le 1er janvier 2020, la loi chinoise sur le chiffrement devait entrer en vigueur. Une donnée supplémentaire et… toujours floue pour ceux qui font des affaires en Chine. Des clarifications sont encore nécessaires sur plusieurs fronts. Par exemple, le chiffrement commercial des sociétés internationales doit être approuvé et certifié avant de pouvoir être utilisé en Chine – mais ce système de certification n’a pas encore été créé. De même, il existe une incertitude concernant le séquestre clé et les données qui doivent être mises à la disposition du gouvernement chinois. Cela a conduit à une vague de spéculations, de désinformation et, finalement, de réactions excessives. Compte tenu de l’opacité des parties de la nouvelle réglementation, de nombreuses entreprises optent pour une approche attentiste. Il s’agit d’une tactique judicieuse, en supposant que votre organisation ne dispose pas d’un expert juridique chinois expérimenté.
En conclusion, l’industrie des certificats continue sa mue. L’équipe certificats de Nameshield se tient à votre disposition pour aborder tous ces sujets.
Les acteurs de l’industrie envisagent de réduire la durée de vie des certificats SSL/TLS, permettant l’affichage du HTTPS dans les navigateurs, à 13 mois, soit environ la moitié de la durée actuelle de 27 mois, afin d’améliorer la sécurité.
Google, via le CA/Browser Forum a en effet proposé cette
modification, approuvée par Apple et une autorité de certification, la rendant
éligible au vote. Si le vote est accepté lors des prochaines réunions du CA/B
Forum, la modification des exigences entrera en vigueur en mars 2020. Tout certificat délivré après la date d’entrée en
vigueur devra respecter les exigences de la période de validité abrégée.
L’objectif de cette réduction est de compliquer la tâche des cyber-attaquants en réduisant la durée d’utilisation des certificats potentiellement usurpés. Cela pourrait également obliger les entreprises à utiliser les algorithmes de chiffrement les plus récents et les plus sécurisés disponibles.
Si le vote échoue, il n’est pas à exclure que les
navigateurs parrainant cette exigence l’implémentent de manière unilatérale
dans leur programme racine, forçant ainsi la main aux autorités de
certification. Il y a fort à parier que ce soit le chemin suivi, ce changement
fait suite à l’initiative précédente de Google visant à réduire la durée de vie
de trois à deux ans en 2018, époque à laquelle Google souhaitait déjà une durée
réduite à 13 mois voire moins.
Qui est touché ?
Les modifications proposées par Google auraient une
incidence sur tous les utilisateurs de certificats TLS de confiance publique,
quelle que soit l’autorité de certification qui émet le certificat. Si le vote
passe, tous les certificats de confiance émis ou réémis après mars 2020 auront
une validité maximale de 13 mois. Les entreprises utilisant des certificats
dont la période de validité est supérieure à 13 mois seront encouragées à
revoir leurs systèmes et à évaluer l’incidence des modifications proposées sur
leur déploiement et leur utilisation.
Les certificats TLS émis avant mars 2020 avec une période de
validité supérieure à 13 mois resteront fonctionnels. Les certificats non-TLS
public, pour la signature de code, le code privé TLS, les certificats clients,
etc… ne sont pas concernés. Il ne sera pas nécessaire de révoquer un certificat
existant à la suite de la mise en place de la nouvelle norme. La réduction
devra être appliquée lors du renouvellement.
Qu’en pensent les acteurs du marché ?
Il s’agirait d’un changement global du secteur, qui aurait
des répercussions sur toutes les autorités de certification. Celles-ci voient
cette proposition d’un mauvais œil. On peut y voir avant tout un intérêt
économique mais pas uniquement…
Leur argument principal est que le marché n’est pas encore
prêt en termes de système d’automatisation des commandes et installations de
certificats. De fait les interventions humaines seraient plus nombreuses, avec
les risques associés à une mauvaise manipulation, ou tout simplement un risque
plus élevé d’oubli de renouvellement d’un certificat.
Pour les autorités de certification, réduire à si court
terme la durée des certificats présente surtout une augmentation significative
des coûts humains liés à la gestion du portefeuille de certificats. Si elles ne
sont pas fondamentalement contre cette décision, elles voudraient surtout des
délais un peu plus long pour étudier notamment ce qu’en pensent les
utilisateurs et les entreprises.
La position des fabricants de navigateurs ?
Que ce soit Google ou Mozilla, fers de lance de l’adoption
massive du HTTPS natif pour tous les sites web, et supporters de l’initiative
Let’sEncrypt, l’important c’est le chiffrement de tout le trafic web. Une
réduction de la durée des certificats réduit le risque d’usurpation des
certificats sur une longue durée et favorise l’adoption massive de systèmes de
gestion automatisés. Pour ces deux acteurs, un monde idéal contiendrait des
certificats d’une durée maximale de 3 mois. S’ils sont à l’écoute du marché
pour ne pas imposer trop rapidement leurs vues, il y a fort à parier qu’à long
terme la durée de vie des certificats continuera à diminuer.
L’avis de Nameshield
Le marché poursuit son évolution vers des durées de
certificats de plus en plus courtes, tout comme une diminution continuelle des
niveaux d’authentification et en conséquence un besoin qui va aller croissant
pour des solutions de gestion automatisées. Nous nous alignerons sur ces
impératifs et conseillons à nos clients de se préparer à cette diminution qui
arrivera, à n’en pas douter. Nos autorités de certification partenaires
suivront également cette évolution et permettront d’offrir tous les systèmes
d’inventaire permanent et d’automatisation requis.
Être entendu
Le forum CA/Browser accepte les commentaires de participants extérieurs et toutes les discussions sont publiques. Vous pouvez soumettre vos commentaires directement à la liste de diffusion du Forum : https://cabforum.org/working-groups/ (en bas de page). Nameshield est en contact avec des participants du CA/B forum et vous tiendra informés des décisions à venir.
Le navigateur Chrome représente entre 62% et 68% de parts de marché mondial. Alors, quand en 2016 Chrome a annoncé son intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter !
Depuis juillet 2018, avec l’arrivée de Chrome 68, les sites en HTTP sont considérés comme « Non Sécurisé », ceux en HTTPS sont marqués « Sécurisé » dans la barre d’adresse.
Et depuis le 25 mai 2018, le RGPD est entré en vigueur et les sites
qui récoltent des données personnelles doivent disposer du HTTPS.
Passer au HTTPS par défaut sur l’ensemble de vos sites Web est devenu
indispensable, en faisant l’acquisition de certificat(s) SSL et permet de
bénéficier de différents avantages.
Au programme de ce webinar, nos
experts reviennent sur :
Qu’est-ce qu’un certificat SSL ?
Quels sont les avantages et les risques liés aux certificats SSL ?
Quelle stratégie adopter pour vos sites web ?
Retrouvez ce webinar animé par Christophe GERARD, Security Product Manager et Lucie LOOS, Directrice Marketing Experte cybersécurité de Nameshield group, en replay sur la plateforme Webikeo :
Plus intuitive, plus complète, plus jolie… la nouvelle interface SSL de Nameshield arrive le jeudi 13 juin, pour vous permettre de gérer l’ensemble de vos certificats.
Vous disposerez maintenant d’indicateurs clés sur votre portefeuille de certificats, de différentes vues de consultation des certificats (ensemble du portefeuille, vue détaillée, certificats proches de l’expiration, commandes en cours, certificats expirés ou révoqués), d’un système de gestion des Organisations et Contacts et d’un système de commande repensé.
Enfin, un outil d’aide à la décision a été intégré pour vous aider dans le choix du bon certificat en cas de doute.
La gamme de certificats est mise à jour, à disposition les certificats SSL, RGS, Code Signing, Individuels, tous types et tous niveaux d’authentification.
L’équipe SSL se tient à votre disposition pour une démonstration, un guide complet d’utilisation est à votre disposition pour l’ensemble des opérations et actions disponibles. Contactez-nous directement sur certificats@nameshield.net.
Ou comment en profiter pour mettre en place une stratégie de certification propre à votre société ?
En Janvier 2013, un nouveau type de Resource Record DNS a vu le jour pour améliorer la chaîne de contrôle dans l’émission des certificats SSL. Ce record appelé CAA pour Certificate Authority Authorization permet de préciser pour un nom de domaine donné, quelles sont les Autorités de Certification autorisées à émettre des certificats.
C’est une création extrêmement intéressante, particulièrement pour les grandes sociétés et groupes dont les équipes techniques sont éparpillées dans le monde et pour lesquelles il est souvent difficile d’imposer une stratégie globale de certification. Il n’est pas rare que les sociétés découvrent par hasard l’existence de certificats demandés par des équipes ne connaissant pas les processus, par des consultants externes, émis par des Autorités de Certification ayant une mauvaise image, ou encore pour des certificats de faible niveau d’authentification (DV). La mise en place de record CAA sur vos noms de domaine est une bonne solution pour contrôler ce que font les équipes et l’actualité du monde du SSL va vous y aider.
En effet, si le CAA a été détaillé dans la RFC-6844 de 2013, il n’était jusqu’à présent pas obligatoire pour une Autorité de Certification, de vérifier si elle était autorisée ou non à émettre un certificat sur un nom de domaine donné, d’où une certaine inutilité de la chose et une adoption très faible.
8 Septembre 2017 – Le CAA checking devient obligatoire
Il aura fallu attendre mars 2017 et un vote positif du CAB/forum (ballot 187) pour rendre cette vérification obligatoire. Depuis le 8 septembre, les Autorités de Certification se doivent de faire cette vérification sous peine de sanctions de la part du CAB/forum et des navigateurs, l’actualité récente entre Google et Symantec nous a montré à quel point ce n’est pas dans leur intérêt.
Trois cas de figure se présentent lors de cette vérification sur un nom de domaine donné :
Un CAA record est en place et mentionne le nom de l’Autorité de Certification, celle-ci peut émettre le certificat ;
Un CAA record est en place et mentionne un nom d’Autorité de Certification différente, celle-ci NE peut PAS émettre le certificat ;
Aucun CAA record n’est en place, n’importe quelle Autorité de Certification peut émettre un certificat SSL
Il est important de noter que pour un nom de domaine donné, plusieurs records CAA peuvent être déclarés. Un outil simple (parmi tant d’autres) pour tester vos noms de domaine est disponible en ligne : https://caatest.co.uk/
Comment profiter du CAA pour ma société ?
Si ce n’est pas déjà fait, l’avènement du CAA checking est l’opportunité pour votre société de définir une stratégie de certification et de pouvoir s’assurer qu’elle soit respectée. Définir une (ou plusieurs) Autorité de Certification qui correspond à vos valeurs et à votre attente en terme de qualité de service est une première étape. Il faudra pour cela mettre autour de la table les intervenants du marketing pour valider l’impact sur l’affichage dans les sites web et les services techniques pour s’assurer de la qualité du fournisseur choisi. Il conviendra ensuite de déclarer ces records CAA dans les différentes zones de vos noms de domaine.
Il convient ensuite de bien communiquer auprès de l’ensemble des opérationnels pour qu’ils prennent conscience des règles imposées au sein de la société, afin de ne pas les bloquer dans l’obtention d’un certificat. En effet, l’expérience de Nameshield montre que très souvent les certificats SSL sont demandés dans l’urgence ; de plus les dernières versions des navigateurs ne sont pas tendres vis-à-vis des erreurs de certificats en affichant de manière ostentatoire du « Not Secure ». En conséquence, bloquer l’émission d’un certificat parce que la communication n’est pas passée peut être dommageable.
Une telle stratégie présente de réels avantages dans la maîtrise des certificats, sur le plan marketing, technique, maîtrise des risques et coûts liés aux certificats. Il convient de la mener en toute connaissance de cause et pour se faire, notre équipe d’experts SSL peut vous accompagner.
Nameshield utilise des cookies
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience🍪.
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience. Plus d'informations dans notre politique de cookies 🍪.
Ces cookies sont essentiels au bon fonctionnement du site web. Ils assurent les fonctionnalités de base et les fonctions de sécurité du site web, de manière anonyme.
Cookie
Durée
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-functional
1 year
The cookie is set by the GDPR Cookie Consent plugin to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
Ces cookies aident à réaliser certaines fonctionnalités comme le partage du contenu du site web sur les plateformes de médias sociaux, la collecte de commentaires et d’autres fonctionnalités de tiers.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Ces cookies sont utilisés pour comprendre comment vous arrivez sur notre Site et pour mesurer le nombre de visiteurs.
Cookie
Durée
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
Ces cookies sont utilisés pour vous proposer des offres et services personnalisés, plus adaptés à vos centres d’intérêts.
Cookie
Durée
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
