Auteur/autrice : Christophe Gérard

CPO - Nameshield Group

La croisade de Google pour l’adoption du HTTPS par défaut

Le navigateur Chrome représente en octobre 2018, selon les sources et toutes plateformes confondues, entre 62% et 68% de parts de marché mondial. Une croissance d’une régularité implacable depuis le lancement du navigateur qui en fait aujourd’hui un acteur incontournable du web. Alors, quand le 8 septembre 2016, les équipes de développement de Chrome annoncèrent leur intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter.

HTTP not secure

L’objectif de Google était d’avertir simplement, et donc visuellement, l’internaute qu’une page en HTTP n’était pas sûre, d’autant plus pour les pages avec saisies de données à caractère personnel (login, mot de passe, informations personnelles, numéro de carte de crédit) :

” We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure. The goal of this proposal is to more clearly display to users that HTTP provides no data security. ”

Un peu plus de deux ans et 17 versions du navigateur plus tard, le temps d’une transition graduée pour un peu plus de douceur, et Google est arrivé à ses fins avec une adoption massive du protocole HTTPS ;  la quasi-totalité des autres navigateurs, Firefox en-tête, ayant suivi la même évolution.

Retour sur l’évolution des indicateurs de sécurité dans Chrome depuis 2 ans :

  1. HTTP not secureSeptembre 2016 – Chrome 53 : le HTTP est la norme, et en dehors de certaines erreurs de sécurité liées à un défaut de la page (notamment lié aux certificats SSL), aucun indicateur particulier concernant le manque de sécurité
  2. Janvier 2017 – Chrome 56 : pour commencer, Chrome met l’accent sur les pages contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit. Firefox s’aligne immédiatement.
  3. Octobre 2017 – Chrome 62 : Google avance vers un test grandeur nature du traitement de l’ensemble des pages HTTP considéré comme non sécurisé avec le lancement en mode « Chrome Incognito » de l’indicateur HTTP « Not secure » au lancement de la page, quel que soit son contenu
  4. Juillet 2018 – Chrome 68 : toute page chargée en HTTP, quel que soit son contenu, quel que soit le mode de navigation, est désormais considéré comme « not secure »
  5. Septembre 2018 – Chrome 69 : pour Google, HTTPS est désormais la norme. La prochaine étape, pour le moins controversée, consiste à éventuellement faire disparaître le cadenas de sécurité tant apprécié des internautes.HTTP not securePour beaucoup c’est un sérieux pas en arrière, il faudra suivre de près cette évolution et penser à mettre en place des certificats SSL Extended Validation EV, qui pour l’instant ne sont pas remis en cause par Google.Validation EV
  6. Octobre 2018 – Chrome 70 : c’est maintenant !Chrome 70Désormais, l’affichage des pages HTTP contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit, est barré d’un indicateur non sécurisé et pour la  première fois de couleur rouge. Les autres pages HTTP sont indiquées non sécurisées en gris. Les pages HTTPS classiques avec un cadenas noir et celles avec un certificat EV affichent en plus le nom de la société… vous suivez ?
    1. Date non définie – Chrome XX : la finalité de Google est la dualité sur le traitement des urls avec HTTPS ouvertement affichés en rouge pour alerter l’internaute et le HTTPS considéré comme normal, donc ne bénéficiant plus d’aucun indicateur « positif » :

Certificats SSL

  1. HTTP à la CorbeilleDate non définie – Chrome YY : toujours dans une optique d’augmentation de la sécurité et de protection des identités, Google a dans ses cartons une réflexion en cours sur la fin du système d’url tel que nous le connaissons aujourd’hui… Pour le remplacer par un système nouveau et plus simple, affaire à suivre…

D’ici là, et si cette réflexion n’a pas encore été menée au sein de votre entreprise, il est grand temps de passer l’ensemble de vos sites web et applications en HTTPS. La réflexion doit également comprendre le fait d’insérer le nom de votre entreprise dans la barre d’adresse des navigateurs, au moins sur les sites vitrine et à fort trafic.

Google verse 9 Milliards de dollars pour rester le moteur de recherche par défaut d’Apple

Google verse 9 Milliards de dollars pour rester le moteur de recherche par défaut d'Apple
Source de l’image : 377053 via Pixabay

En Septembre 2017, Apple changeait de moteur de recherche par défaut pour son assistant numérique personnel Siri. Depuis, toute question posée à Siri et nécessitant une recherche sur le Web passe par le moteur de recherche de Google, et non plus par Bing, celui de Microsoft. Ce changement suivait ainsi une certaine cohérence dans la mesure où le moteur par défaut dans le navigateur Safari, en version macOS ou iOS, était également celui de Google. Mais au-delà de la simple cohérence, c’est surtout le possible accord financier évoqué alors sur une note du cabinet d’analyses Bernstein qui attirait l’attention : Google aurait versé 3 milliards de dollars à Apple pour être le moteur de recherche par défaut sur iPad et sur iPhone.

Un an plus tard c’est l’analyste Rod Hall, de la banque d’investissements Goldman Sachs, qui donne un nouvel éclairage à cet accord financier officieux. En effet, Google aurait payé 9 milliards de dollars à Apple pour l’année 2018 et prévoirait près de 12 milliards de dollars pour l’année 2019. A titre d’éclairage complémentaire, ces transactions rapportent plus d’argent à Apple que ses propres services iCloud ou Apple Music et seraient même la deuxième source de revenus de la division « services » derrière l’App Store.

Ces sommes paraissent folles ?

Rod Hall base ses estimations sur la part de marché du navigateur Safari, en croissance constante. Sur ordinateurs, tablettes et téléphones mobiles confondus, Safari représente aujourd’hui entre 15% et 17% de parts de marché selon différentes sources (NetMarketShare ou Statcounter) contre 60% à 61,6% pour Chrome. C’est surtout le trafic généré via Safari qui ne cesse d’augmenter et qui sert de base de calcul dans cet accord.

Même si les chiffres avancés par Rod Hall restent des estimations, non confirmés par les deux géants du web, ou encore jugés trop importants par d’autres cabinets, la facture finale pour Google semble salée. Mais ces chiffres restent presque raisonnables au vu des enjeux financiers. En effet, selon différentes sources, Google représente plus de 92% du marché des moteurs de recherche dans le monde et entend bien par tous les moyens maintenir cette position dominante.

L’acquisition de trafic est primordiale pour Google qui se rattrape directement via le canal publicitaire, indirectement sur la collecte d’information des utilisateurs venant ainsi alimenter ses bases de données et, par voie de conséquence, ses programmes d’intelligence artificielle, sans parler de la préservation de son omnipotence.

Google a ainsi renégocié l’an dernier les contrats de ses partenaires en augmentant leur rémunération. Les sommes que Google reverse à ses partenaires au titre de l’acquisition de trafic ont régulièrement augmenté ces dernières années. Ils ont dépassé les 20 milliards de dollars en 2017, représentant 22,7 % des revenus publicitaires du groupe… ça donne le tournis.

Les entreprises ne sont pas assez préparées face aux attaques DNS

Les entreprises ne sont pas assez préparées face aux attaques DNS
Source de l’image : typographyimages via Pixabay

La sécurité du DNS est souvent négligée en matière de stratégie de cybersécurité, la plupart des entreprises n’étant pas suffisamment préparées pour se défendre contre les attaques DNS.

Dimensional Research * a interrogé plus de 1 000 professionnels de la sécurité et de l’informatique dans le monde et a constaté que 86% des solutions DNS n’alertaient pas les équipes de sécurité lors d’une attaque DNS et près du tiers des professionnels doutaient que leur entreprise puisse se défendre.

Ces résultats font suite à la célèbre attaque DDoS subie par DNS Dyn en octobre 2016, attaque qui a rendu inaccessibles des dizaines de sites majeurs, dont Netflix, Airbnb, Amazon, CNN, New York Times, Twitter et plus. L’impact généralisé de cette attaque a mis en lumière une réalité surprenante : de nombreuses entreprises ne disposent pas de moyens de défense suffisants en matière de sécurité DNS. Malgré ce qui aurait dû être une sensibilisation du fait de la visibilité de l’attaque, seules 11% des entreprises ont des équipes de sécurité dédiées à la gestion du DNS, le DNS n’étant toujours pas traité au niveau de priorité adéquat.

« Nos recherches révèlent un écart sur le marché, alors que nous avons constaté que la sécurité DNS est l’une des trois principales préoccupations des professionnels de l’informatique et de la sécurité, la grande majorité des entreprises ne sont pas suffisamment équipées contre les attaques DNS« , dixit David Gehringer responsable chez Dimensional Research. « Cela vient du fait que les entreprises sont uniquement réactives en matière de sécurité du DNS, n’accordant la priorité à la défense du DNS qu’après avoir subi une attaque. À moins que les organisations d’aujourd’hui ne commencent à adopter une approche proactive, les attaques DDoS telles que celle sur le fournisseur DNS Dyn deviendront de plus en plus répandues. »

Attaques DNS

Les attaques DNS sont extrêmement efficaces 

Trois entreprises sur dix ont déjà été victimes d’attaques DNS. Parmi celles-ci, 93% ont connu une indisponibilité de leurs services suite à leur dernière attaque DNS. 40%  sont tombées une heure ou plus, ce qui a eu un impact considérable sur leurs activités.

Les entreprises tardent à remarquer les attaques DNS 

Bien que 71% des entreprises déclarent avoir une surveillance en temps réel des attaques DNS, 86% des solutions ne sont pas les premières à notifier les attaques de DNS. De plus, 20% des entreprises ont d’abord été alertées par des plaintes de clients à propos d’attaques DNS, ce qui a eu un impact sur leurs activités, leur réputation et la satisfaction de leurs clients.

La plupart des entreprises sont vulnérables aux attaques DNS

Seules 37% des entreprises sont en mesure de se défendre contre tous les types d’attaques DNS (détournements, exploits, empoisonnements de cache, anomalies de protocole, réflexion, amplification), ce qui signifie que la majorité (63%) parie essentiellement sur le fait que la prochaine attaque DNS est une attaque qu’ils peuvent repousser.

Réactif plutôt que proactif 

Avant une attaque, 74% des entreprises se concentrent sur la surveillance antivirus en tant que priorité de leur sécurité. Cependant, après une attaque, la sécurité du DNS passe à la première place avec 70% des personnes interrogées affirmant que c’est le point de sécurité le plus important. Cela démontre une approche réactive et que le DNS n’est pas une priorité tant qu’une entreprise n’a pas été attaquée et n’a subi aucune perte tangible.

Le DNS a un impact direct sur le résultat net 

24% des entreprises ont perdu 100 000 $ ou plus lors de leur dernière attaque DNS, ce qui a eu un impact considérable sur leurs résultats. 54% ont perdu 50 000 $ ou plus. Comme le montrent les chiffres, une fois que les sites Web sont devenus inaccessibles, toutes les activités et tous les revenus numériques s’arrêtent, tandis que les ressources internes sont redirigées vers la résolution de l’attaque plutôt que vers l’activité. Sans parler des pertes de données clés (email), de l’impact sur l’image de marque de la société et du nombre d’internautes qui se détournent au profit d’autres sites disponibles.

Les entreprises ne sont pas assez préparées face aux attaques DNS
Source : Dimensional Research

« La plupart des entreprises considèrent le DNS comme une simple infrastructure plutôt que comme une infrastructure critique nécessitant une défense active », a déclaré Cricket Liu, architecte en chef du DNS chez Infoblox. « Malheureusement, cette enquête confirme que, près de deux ans après l’énorme attaque DDoS contre Dyn, une leçon dramatique sur les effets des attaques sur l’infrastructure DNS, la plupart des entreprises négligent encore la sécurité du DNS. »

Notre approche de la cybersécurité nécessite un changement fondamental : si nous ne commençons pas à accorder à la sécurité DNS l’attention qu’elle mérite, le DNS restera l’un des systèmes Internet les plus vulnérables et nous continuerons à voir des événements similaires. Rappelons-nous qu’un DNS qui tombe impacte potentiellement tous les services clés de l’entreprise : sites web, messageries (email et instantanée), applications mobiles, VOIP, intranet, extranet…

Nameshield vous accompagne sur la sécurisation des DNS, n’hésitez pas à contacter nos experts pour entamer une discussion sur ce sujet clé.

* Dimensional research est une société de consulting américaine qui fournit des études de marché, notamment sur la cybersécurité.

[INFOGRAPHIE] Passer son site web en HTTPS : Pourquoi ? Et quel certificat SSL choisir ?

En juillet 2018, avec l’arrivée de Chrome 68, les sites en HTTP seront considérés comme « Non Sécurisé », ceux en HTTPS seront 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 devront disposer du HTTPS.

De plus, certains nouveaux gestionnaires de noms de domaine imposent également le HTTPS pour pouvoir utiliser le nom de domaine (.app / .dev…).

Passer au HTTPS par défaut sur l’ensemble de vos sites Web va devenir indispensable, en faisant l’acquisition de certificat(s) SSL, avec les avantages suivants :

Confidentialité des échanges, authentification forte et intégrité des communications entre les internautes et vos sites web, jouant sur le niveau de confiance des internautes envers vos sites web et plus généralement votre image de marque liée à la sécurité en ligne.

Mais comment choisir le certificat qui répond à vos besoins ? Ci-dessous notre guide pour vous aider dans votre choix :

Passer son site web en HTTPS : Pourquoi ? Et quel certificat SSL choisir ?

Nameshield vous accompagne

Notre équipe d’experts SSL vous accompagne dans la formation de vos équipes, organise régulièrement des réunions d’information au sein de ses locaux pour vous permettre d’échanger avec d’autres acteurs du marché, met à votre disposition les outils nécessaires à la prise de décision (audit, analyse, conseil) et vous accompagne au quotidien sur tous ces sujets.

A noter : Le 21 juin prochain à Paris, un petit-déjeuner sera organisé autour de ce thème.
Pour plus d’informations et pour vous y inscrire ☛ Invitation au nameshield.cafe.

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 .みんな .谷歌 .グーグル

Chrome 68 : en juillet 2018, les sites en HTTP seront considérés comme « Non Sécurisé »

Chrome 68 : en juillet 2018, les sites en HTTP seront considérés comme « Non Sécurisé »

Nous y sommes ! Google vient d’annoncer dans ce post son intention d’indiquer l’ensemble des pages en HTTP, quel que soit leur contenu, comme étant « non sécurisé ».

Chrome 68 : en juillet 2018, les sites en HTTP seront considérés comme « Non Sécurisés »
Source: Google Security Blog

Le changement est prévu pour le mois de Juillet 2018, avec l’arrivée de la version 68 du fameux navigateur, et confirme la volonté de Google de sécuriser le web. Pour Google le HTTPS doit continuer à être adopté massivement et devenir le standard.

Ce n’est pas une surprise puisque Google a déjà opéré de nombreuses évolutions dans cette direction. Tout d’abord en annonçant un impact positif sur le référencement naturel des sites dont la page d’accueil serait en HTTPS (2014), puis en supprimant le cadenas sur le HTTP (2016), ensuite en indiquant les fameux mots « Non sécurisé » pour toutes les pages de saisies de données personnelles encore en HTTP (2017), et enfin depuis la version 62 avec le mode de navigation incognito affichant déjà toutes les pages HTTP comme « non sécurisé » (2017).

Toutes ces évolutions ont fait l’objet de post sur le blog sécuritaire de Google et étaient systématiquement accompagnées de la fameuse phrase « eventual treatment of all HTTP pages in Chrome : Not Secure » en fin de paragraphe.

Et ça marche ! L’usage du HTTPS se démocratise

Selon Google plus de 68% du trafic généré par Chrome sur Android et Windows est désormais protégé contre plus de 78% sous Chrome OS et Mac. Sur les 100 plus importants sites du monde 81% sont en HTTPS par défaut.

Mais qu’est-ce que le HTTPS ?

Il s’agit d’une extension sécurisée du protocole HTTP, le « S » pour « Secured » signifie que les données échangées entre le navigateur de l’internaute et le site web sont chiffrées et ne peuvent en aucun cas être espionnées  (confidentialité) ou modifiées (intégrité). Obtenir le sacro-saint « S » passe par l’acquisition et l’installation d’un certificat SSL/TLS auprès d’une Autorité de Certification reconnue.

Comment se préparer ?

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 urgent de se positionner.

  • Former et informer vos é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 corporate, vitrine, flagship : prévoir de passer en HTTPS par défaut au plus tôt ;
    2. Sites contenant un espace de saisie de données personnelles (formulaire, login, password, récupération de mot de passe, achats en ligne) => vérifier la présence de HTTPS
    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

  • Nameshield vous accompagne

    Notre équipe d’experts SSL vous accompagne dans la formation de vos équipes ; organise régulièrement des réunions d’information au sein de ses locaux pour vous permettre d’échanger avec d’autres acteurs du marché ; met à votre disposition les outils nécessaires à la prise de décision (audit, analyse, conseil) et vous accompagne au quotidien sur tous ces sujets.

    Nameshield est aussi 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.

A noter : un petit-déjeuner est organisé autour de ce thème, le 21 juin prochain à Paris, n’hésitez pas à vous y inscrire. Pour plus d’informations et pour vous y inscrire ☛ Invitation au nameshield.cafe.

Firefox : les nouvelles fonctionnalités imposent une connexion HTTPS

Firefox : les nouvelles fonctionnalités imposent une connexion HTTPS

Google Chrome a longtemps fait parler de lui comme fer de lance dans la lutte pour imposer le HTTPS à tout le web. Mais ce serait une erreur d’oublier Mozilla et son navigateur Firefox qui adopte également cette volonté d’un internet totalement chiffré. On notera l’utilisation du terme chiffré et non « sécurisé » puis que le httpS est devenu tellement accessible que les premiers à en profiter sont les sites frauduleux, mais c’est un autre débat !

Après sa volonté de marquer les sites en HTTP comme étant non sécurisés, la fondation vient en effet d’annoncer qu’elle va augmenter le nombre de fonctionnalités web de Firefox nécessitant l’usage du HTTPS. Pour Mozilla le HTTPS doit devenir l’usage par défaut.

« À compter d’aujourd’hui, toutes les nouvelles fonctionnalités qui sont exposées sur le web seront restreintes aux contextes sécurisés. Exposée sur le web veut dire que la fonctionnalité peut être observée à partir d’une page web ou un serveur, que ça soit par JavaScript, CSS, HTTP, les formats média, etc. » commente Anne van Kestren.

Autrement dit, les communications entre le navigateur et le serveur externe devront être acheminées par HTTPS, sinon le standard ne fonctionnera pas avec le navigateur. Ce n’est pas réellement une surprise, la géolocalisation faisait déjà l’objet de ce traitement de faveur depuis le mois de mars 2017. Ces fonctionnalités, pour la plupart cachées, sont :

  • Géolocalisation
  • Bluetooth
  • HTTP/
  • Notifications Web (API)
  • Accès à la webcam et au microphone
  • Algorithme de compression web Brotli de Google
  • Accelerated Mobile Pages de Google (AMP)
  • Encrypted Media Extensions (EME)
  • Requête de paiement (API)
  • Service Workers utilisés par la synchronisation en arrière-plan et les notifications

Et bien sûr toutes les pages contenant une saisie d’information personnelle sont toujours accompagnées d’un cadenas barré.

Dans le futur, l’objectif affiché de Mozilla est d’imposer le HTTPS à toutes les fonctionnalités de Firefox.

Google annonce quant à lui son intention d’afficher les termes « non sécurisé » sur toutes les pages en http.

Si vous n’avez pas encore entrepris de migrer vos sites web, au moins les plus visibles, en httpS, il est grand temps de se pencher sur la question.

Réduction des certificats SSL à 2 ans maximum

Réduction des certificats SSL à 2 ans maximum

Le CAB Forum, l’organisme qui définit les règles d’émission et de gestion des certificats SSL a approuvé la réduction des certificats SSL à une durée de 2 ans contre 3 précédemment. Initiée par les navigateurs, Chrome et Mozilla en tête, cette décision va dans le sens d’un Internet toujours plus sécurisé en obligeant les acteurs à renouveler plus souvent leurs clés de sécurité et rester sur les derniers standards du marché.

Cette décision sera applicable pour toutes les Autorités de Certification au 1er Mars 2018. Afin d’assurer une transition en douceur, Nameshield ne proposera plus de certificats d’une durée de 3 ans dès le 1er Février 2018.

Quelle incidence pour vos certificats ?

Les nouveaux certificats auront donc une durée maximale de 825 jours (2 ans et 3 mois pour couvrir la possibilité de renouvellement anticipé de 90 jours). Les certificats EV étaient déjà dans ce cas de figure, sont donc concernés les certificats DV et OV sous toutes leurs formes (standard, multi-sites ou wildcard). Rien de particulier pour ces certificats.

Pour les certificats existants, cette nouvelle durée aura une conséquence puisque qu’elle s’appliquera à tous les certificats à partir du 1er Mars. Un certificat de 3 ans émis récemment et qui aurait besoin d’être remplacé au-delà du délai des 825 jours devra donc être de nouveau authentifié. Il est donc important de le savoir pour éviter des réémissions en urgence, y compris pour le simple ajout d’un SAN. Il faudra donc vérifier au préalable si le certificat à remplacer risque d’être impacté, c’est le cas des certificats DV et OV, les EV ne sont là non plus pas concernés.

L’équipe SSL de Nameshield vous préviendra quant aux certificats concernés.

Le CAA devient obligatoire dans le petit monde du SSL

Ou comment en profiter pour mettre en place une stratégie de certification propre à votre société ?

Le CAA devient obligatoire dans le petit monde du SSL

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

CAA found - not found : Le CAA devient obligatoire dans le petit monde du 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.

Les 3 attaques DNS les plus communes et comment les combattre

Cyberattaque - Attaques DNS

En octobre 2016 de nombreux sites Web populaires tels qu’Amazon, Twitter, Netflix et Spotify sont devenus inaccessibles à des millions d’internautes aux Etats-Unis pendant près de 10 heures, autant dire une éternité. En cause, une des plus grosses attaques de l’histoire d’Internet sur les services DNS de Dyn, un acteur majeur dans ce secteur d’activité.

D’autres sociétés telles que Google, The New York Times et de nombreuses banques ont également été victimes de différentes variétés d’attaques ciblant le DNS ces dernières années et, si dans beaucoup de sociétés le DNS reste un grand oublié, les choses sont en train d’évoluer vers une prise de conscience forcée par ces nombreuses attaques.

Mais au fait, quelles sont ces attaques ?

Attack #1: DNS Cache Poisoning and Spoofing

La finalité de l’empoisonnement DNS est d’acheminer les utilisateurs vers un site Web frauduleux. Par exemple, un utilisateur tape « gmail.com » dans un navigateur Web avec pour objectif d’aller consulter sa boîte email. Le DNS ayant été empoisonné, ce n’est pas la page gmail.com qui s’affiche mais une page frauduleuse choisie par l’attaquant, dans le but par exemple de récupérer les accès aux boîtes emails. Les utilisateurs saisissant le nom de domaine correct, ils ne se rendent pas compte que le site Web qu’ils visitent est un faux, une escroquerie.

Cela crée une opportunité parfaite pour les attaquants d’utiliser des techniques de phishing pour soutirer de l’information, qu’il s’agisse des informations d’identification ou des informations de carte de crédit, auprès de victimes peu méfiantes. L’attaque peut être dévastatrice, en fonction de plusieurs facteurs, selon l’intention de l’attaquant et la portée de l’empoisonnement DNS.

Comment les pirates mènent-ils cette attaque ? En exploitant le système de mise en cache DNS.

La mise en cache DNS est utilisée dans tout le Web pour accélérer les temps de chargement et réduire les charges sur les serveurs DNS. La mise en cache de document Web (ex : page web, images) est utilisée afin de réduire la consommation de bande passante, la charge du serveur web (les tâches qu’il effectue), ou améliorer la rapidité de consultation lors de l’utilisation d’un navigateur. Un cache Web conserve des copies de documents transitant par son biais. Une fois qu’un système interroge un serveur DNS et reçoit une réponse, il enregistre les informations dans un cache local pour une référence plus rapide, sur un laps de temps donné, sans avoir à aller rechercher l’information. Le cache peut donc répondre aux requêtes ultérieures à partir de ses copies, sans recourir au serveur Web d’origine.

Cette approche est utilisée à travers le Web de manière routinière et en chaîne. Les enregistrements d’un serveur DNS servent à mettre en cache des enregistrements sur un autre serveur DNS. Ce serveur sert à mettre en cache les enregistrements DNS sur les systèmes de réseau tels que les routeurs. Ces enregistrements sont utilisés pour créer des caches sur des machines locales.

L’empoisonnement DNS survient lorsque l’un de ces caches est compromis.

Par exemple, si le cache sur un routeur réseau est compromis, alors quiconque l’utilise peut être mal orienté vers un site Web frauduleux. Les faux enregistrements de DNS se ramifient vers les caches DNS sur la machine de chaque utilisateur.

Cette attaque peut également viser des maillons hauts de la chaîne. Par exemple, un serveur DNS majeur peut être compromis. Cela peut endommager les caches des serveurs DNS gérés par les fournisseurs de services Internet. Le « poison » peut se répercuter sur les systèmes et les périphériques de réseautage de leurs clients, ce qui permet d’acheminer des millions de personnes vers des sites Web frauduleux.

Cela vous semble fou ? En 2010, de nombreux internautes américains ne pouvaient plus accéder à des sites comme Facebook et YouTube, car un serveur DNS d’un fournisseur d’accès Internet de haut niveau avait accidentellement récupéré les enregistrements du Grand Pare-feu Chinois [le gouvernement chinois bloquait les accès à ces sites].

L’antidote à ce poison

L’empoisonnement du cache DNS est très difficile à détecter. Il peut durer jusqu’à ce que le TTL (Time To Live – durée de validité d’une requête mise en cache) expire sur les données en cache ou qu’un administrateur le réalise et résolve le problème. En fonction de la durée du TTL, les serveurs peuvent prendre des jours pour résoudre le problème de leur propre chef.

Les meilleures méthodes pour empêcher une attaque par empoisonnement du cache DNS incluent la mise à jour régulière du programme, la réduction des temps TTL et la suppression régulière des caches DNS des machines locales et des systèmes réseau.

Pour les registres qui le permettent la mise en place de DNSSEC est la meilleure réponse afin de signer les zones des noms de domaine sur l’ensemble de la chaine et rendre impossible une attaque par empoisonnement du cache.

 

Attack #2: Attaque par amplification DNS (de type DDoS)

Les attaques par amplification DNS ne sont pas des menaces contre les systèmes DNS. Au lieu de cela, elles exploitent la nature ouverte des services DNS pour renforcer la force des attaques de déni de service distribuées (DDoS). Ces attaques ne sont pas les moins connues, ciblant par exemple des sites bien à forte notoriété tels que BBC, Microsoft, Sony…

Accrocher et amplifier

Les attaques DDoS se produisent généralement à l’aide d’un botnet. L’attaquant utilise un réseau d’ordinateurs infectés par des logiciels malveillants pour envoyer de grandes quantités de trafic vers une cible, comme un serveur. Le but est de surcharger la cible et de ralentir ou de l’écraser.

Les attaques par amplification ajoutent plus de puissance. Plutôt que d’envoyer le trafic directement d’un botnet à une victime, le botnet envoie des demandes à d’autres systèmes. Ces systèmes répondent en envoyant des volumes de trafic encore plus importants à la victime.

Les attaques par amplification DNS en sont un exemple parfait. Les attaquants utilisent un botnet pour envoyer des milliers de demandes de recherche pour ouvrir des serveurs DNS. Les demandes ont une adresse source falsifiée et sont configurées pour maximiser la quantité de données renvoyées par chaque serveur DNS.

Le résultat: un attaquant envoie des quantités relativement restreintes de trafic à partir d’un botnet et génère des volumes de trafic proportionnellement supérieurs ou « amplifiés » des serveurs DNS. Le trafic amplifié est dirigé vers une victime, ce qui provoque une panne du système.

Détecter et se défendre

Certains pare-feu peuvent être configurés pour reconnaître et arrêter les attaques DDoS au fur et à mesure qu’elles se produisent en supprimant des paquets artificiels essayant d’inonder les systèmes sur le réseau.

Une autre façon de lutter contre les attaques DDoS consiste à héberger votre architecture sur plusieurs serveurs. De cette façon, si un serveur devient surchargé, un autre serveur sera toujours disponible. Si l’attaque est faible, les adresses IP d’envoi du trafic peuvent être bloquées. En outre, une augmentation de la bande passante du serveur peut lui permettre d’absorber une attaque.

De nombreuses solutions dédiées existent également conçues exclusivement pour lutter contre les attaques DDoS.

 

Attack #3: Attaque DDoS sur le DNS

Les attaques DDoS peuvent être utilisées contre de nombreux types de systèmes. Cela inclut les serveurs DNS. Une attaque DDoS réussie contre un serveur DNS peut provoquer une panne, ce qui rend les utilisateurs incapables de naviguer sur le Web (note: les utilisateurs seront susceptibles de continuer à atteindre les sites Web qu’ils ont visités récemment, en supposant que l’enregistrement DNS soit enregistré dans un cache local).

C’est ce qui est arrivé aux services DNS de Dyn, comme décrit en début d’article. L’attaque DDoS a surchargé les infrastructures DNS, ce qui a empêché des millions de personnes d’accéder aux principaux sites Web dont les noms de domaine étaient hébergés dessus.

Comment se défendre contre ces attaques ? Tout dépend de la configuration de vos DNS.

Par exemple, hébergez-vous un serveur DNS? Dans ce cas, il existe des mesures que vous pouvez prendre pour le protéger, en mettant à jour les derniers patchs et en autorisant uniquement les ordinateurs locaux à y accéder.

Peut-être essayez-vous d’atteindre le serveur DNS attaqué ? Dans ce cas, vous aurez probablement du mal à vous connecter. C’est pourquoi il est judicieux de configurer vos systèmes pour compter sur plus d’un serveur DNS. De cette façon, si le serveur principal venait à ne plus répondre, un serveur de repli sera lui disponible.

Prévoir et atténuer les attaques

Les attaques du serveur DNS constituent un risque majeur pour la sécurité du réseau et doivent être prises au sérieux. Les entreprises, hébergeurs et fournisseurs d’accès doivent mettre en place des mesures de sauvegarde afin de prévenir et de réduire les effets d’une telle attaque lorsqu’ils en sont victimes.

À la suite de ces attaques, l’ICANN a souligné plus fortement que jamais la nécessité d’utiliser le protocole DNSSEC pour signer chaque requête DNS avec une signature certifiée, en garantissant ainsi l’authenticité. L’inconvénient de cette technologie est le fait qu’il doit être mis en œuvre à tous les stades du protocole DNS pour fonctionner correctement – ce qui arrive lentement mais sûrement.

Optez pour des infrastructures hébergées et maintenues par des spécialistes du DNS, et assurez-vous que le réseau soit anycasté (points de présences multiples et répartis sur l’ensemble de la planète, ou au moins sur vos zones d’influence) et bénéficie de filtrage anti-DDoS, et vous propose des solutions de sécurité supplémentaires telles que DNSSEC mais aussi failover pour intégrer le DNS dans vos PCA et PRA.

Nameshield dispose de sa propre infrastructure DNS Premium pour répondre aux besoins de ses clients. Cette infrastructure répond notamment (voire dépasse) à tous les pré-requis ANSSI. La solution DNS Premium est intégrée dans le scope de notre certification ISO 27001.

N’hésitez pas à nous contacter pour toutes questions relatives aux cyberattaques.