Cédrix
1 line
26 KiB
JSON
1 line
26 KiB
JSON
[{"uuid":"093711bf-4e60-4ea8-ba73-928d2d67776c","slug":"certificats-let-s-encrypt-a-6-jours-faut-il-sauter-le-pas","title":"Certificats Let's Encrypt à 6 jours : faut-il sauter le pas ?","category":"actualité","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-07 22:46","created_at":"2026-05-12 08:47:27","updated_at":"2026-05-12 08:59:58","tags":[],"plain":"Guide DevOps / WebOps pour comprendre les certificats à durée de vie courte () et décider si vous devez migrer.\r\n--\r\n\r\nTL;DR\r\n\r\nLet's Encrypt propose désormais au grand public des certificats valides 6 jours (profil ), en plus du classique 90 jours. Pour les certificats sur adresse IP, c'est même obligatoire. La question n'est pas \"est-ce que c'est bien ?\" — techniquement oui — mais \"est-ce que mon infra est prête ?\". Si votre renouvellement automatique fonctionne sans accroc depuis 6 mois, foncez. Sinon, fiabilisez d'abord, migrez ensuite.\r\n--\r\n\r\n1. De quoi on parle\r\n\r\nDepuis janvier 2026, Let's Encrypt émet en disponibilité générale deux nouveautés couplées : les certificats pour adresses IP, et les certificats à durée de vie de 6 jours via un nouveau profil ACME nommé . Certbot 4.0 a introduit le flag pour les sélectionner, et Certbot 5.3 a ajouté pour demander un cert sur IP.\r\n\r\nConcrètement, un certificat a une validité de 6 jours au lieu de 90. Tout le reste — chaîne de confiance, algorithmes, format — est identique. Pour le navigateur, c'est un certificat Let's Encrypt standard.\r\n\r\nLes profils disponibles\r\nProfil | Durée | Usage |\r\n---|---|---|\r\n(défaut) | 90 jours | Tout le monde, par défaut |\r\n| 6 jours | Adopters précoces, certs sur IP (obligatoire) |\r\n| 90 jours | Variante optimisée serveur web (sans clientAuth) |\r\n--\r\n\r\n2. Pourquoi Let's Encrypt pousse vers le court\r\n\r\nQuatre raisons techniques, par ordre d'importance.\r\n\r\n2.1 La révocation TLS est cassée — autant l'éviter\r\n\r\nC'est le vrai sujet. Le mécanisme de révocation des certificats (CRL, OCSP) n'a jamais fonctionné correctement à grande échelle :\r\nOCSP soft-fail : si le serveur OCSP est injoignable, la plupart des navigateurs acceptent quand même le certificat. Un attaquant qui contrôle le réseau bloque l'OCSP et le cert révoqué passe.\r\nOCSP stapling mal configuré sur beaucoup de serveurs.\r\nCRLite, OneCRL : couvertures partielles, déploiement client incohérent.\r\nOCSP retiré : Let's Encrypt a arrêté OCSP en 2025, justement parce que ça ne servait quasiment à rien tout en posant des problèmes de vie privée.\r\n\r\nAvec un cert à 6 jours, la révocation devient cosmétique : on attend l'expiration. La fenêtre d'exploitation d'une clé compromise passe de plusieurs semaines (cert 90 jours, OCSP douteux) à quelques jours maximum.\r\n\r\n2.2 Réduire la fenêtre de compromission\r\n\r\nSi votre clé privée fuite (backup mal protégé, faille serveur, employé qui part avec une copie, vulnérabilité type Heartbleed), l'attaquant peut usurper votre site tant que le cert est valide. À 90 jours, c'est trois mois d'exposition dans le pire cas. À 6 jours, c'est une semaine.\r\n\r\nC'est encore plus critique pour les certs sur IP : une IP peut changer de propriétaire (cloud, VPS recyclé, réattribution FAI). Un cert long pour une IP qui ne vous appartient plus, c'est un risque que LE refuse de prendre — d'où l'obligation du profil court pour cet usage.\r\n\r\n2.3 Forcer une automatisation propre\r\n\r\nPersonne ne renouvelle un cert à la main tous les 6 jours. C'est mécaniquement infaisable. Le profil est donc un filtre qualité : si votre renouvellement n'est pas blindé, vous le saurez vite.\r\n\r\nL'effet de bord positif : ça élimine les pannes classiques type \"le cert a expiré parce que le cron était cassé depuis trois mois et personne ne s'en est rendu compte\". À 6 jours, un cron cassé devient visible immédiatement.\r\n\r\n2.4 Agilité cryptographique\r\n\r\nSi une vulnérabilité majeure impose de déprécier un algorithme en urgence (RSA, transition post-quantique, faille découverte sur SHA-256), un parc avec des certs à 6 jours bascule en une semaine. Un parc 90 jours met trois mois. C'est la raison qui motive aussi le CA/Browser Forum à pousser globalement vers des durées plus courtes (45 jours d'ici 2029 dans la baseline).\r\n--\r\n\r\n3. Pourquoi vous pourriez ne pas migrer\r\n\r\nSoyons honnêtes : pour la plupart des infras web classiques, le 90 jours suffit largement. Le 6 jours a des coûts réels.\r\n\r\n3.1 Pression sur le rate limiting\r\n\r\nLet's Encrypt limite à 300 nouveaux certificats par compte par 3 heures et 5 duplicatas de cert par semaine. Avec des certs 90 jours, vous renouvelez 4 fois par an. Avec des 6 jours, c'est 60 fois par an et par cert. Si vous avez 50 services derrière 50 certs distincts, vous explosez votre budget de requêtes ACME.\r\n\r\nMitigation : regrouper les domaines dans des certs SAN (un seul cert pour , , plutôt que trois certs).\r\n\r\n3.2 Dépendance critique au CA et au réseau\r\n\r\nÀ 90 jours, si Let's Encrypt est down 48h, vous ne le remarquez même pas. À 6 jours, une panne de 48h sur LE et votre fenêtre de renouvellement (typiquement à 1/3 de la durée restante, soit 2 jours), et votre cert expire. Vos services tombent.\r\n\r\nConséquences concrètes :\r\nIl faut un monitoring sérieux de l'expiration des certs (Prometheus blackbox exporter, , etc.).\r\nIl faut un fallback : second client ACME, second account, ou cert de secours d'une autre CA.\r\nIl faut absolument que la résolution DNS et le port 80/443 sortants depuis votre serveur soient fiables.\r\n\r\n3.3 Charge sur les systèmes de déploiement\r\n\r\nChaque renouvellement déclenche : appel ACME, validation HTTP-01 ou DNS-01, écriture des fichiers, rechargement du serveur web (Nginx, Apache, HAProxy, etc.). À 60 fois par an au lieu de 4, ça multiplie par 15 le nombre de reloads.\r\n\r\nSur un serveur web basique, un est gratuit. Sur des architectures plus complexes (load balancers stateful, terminations TLS distribuées, certs poussés vers un CDN, configs multi-nœuds avec Ansible/Salt), chaque renouvellement déclenche une cascade. À évaluer.\r\n\r\n3.4 Logs, audit, conformité\r\n\r\nCertains contextes réglementaires demandent une traçabilité des certificats (PCI-DSS, ISO 27001, HDS). Multiplier par 15 le volume d'événements de renouvellement à archiver et auditer, ça représente du stockage et du tooling à adapter.\r\n\r\n3.5 Le cas \"monitoring TLS externe\"\r\n\r\nSi vous avez des outils tiers (uptime monitors, scanners de conformité) qui vérifient l'expiration de vos certs, ils risquent de hurler en permanence : un cert qui montre toujours \"expire dans 6 jours\" déclenche les alertes \"cert expirant bientôt\" sur la plupart des outils mal configurés. Il faut soit ajuster les seuils, soit changer d'outil.\r\n--\r\n\r\n4. Décision : grille de lecture\r\nSituation | Recommandation |\r\n---|---|\r\nServeurs web classiques, renouvellement Certbot qui marche, < 20 certs | Restez en 90 jours. Le bénéfice marginal ne justifie pas le risque. |\r\nVous gérez des certs sur IP | Pas le choix : est obligatoire. |\r\nArchitecture critique avec rotation de clés agressive (banque, santé, infra publique) | Migrez. Le 6 jours est aligné avec vos exigences de sécurité. |\r\nInfra dev/staging interne | Excellent terrain de test. Migrez d'abord ici pour valider votre pipeline. |\r\nVous avez déjà eu une expiration cert non détectée en prod | Ne migrez pas tout de suite. Fiabilisez d'abord le monitoring et le renouvellement, puis migrez. Sinon vous transformez un incident annuel en incident hebdomadaire. |\r\nVous publiez via reverse proxy unique (un seul cert SAN pour plusieurs services) | Bon candidat. Un seul renouvellement à fiabiliser. |\r\nVous avez un parc hétérogène (Apache + Nginx + HAProxy + Traefik...) avec hooks custom | Auditez chaque hook avant de migrer. C'est là que ça casse. |\r\n--\r\n\r\n5. Comment migrer concrètement (Certbot)\r\n\r\n5.1 Pré-requis\r\n\r\nAvant tout :\r\n\r\n1. Certbot 4.0+ pour , 5.3+ pour , 5.4+ pour avec IP.\r\n2. Un renouvellement automatique opérationnel et vérifié (timer systemd ou cron actif, testé avec ).\r\n3. Un monitoring d'expiration des certs en place. Si vous n'en avez pas, installez-le avant de migrer.\r\n4. Un hook de reload du serveur web qui fonctionne ().\r\n\r\n5.2 Test sur le staging Let's Encrypt\r\n\r\n\r\n\r\nVérifier que le cert obtenu a bien une durée de 6 jours :\r\n\r\n\r\n\r\n5.3 Renouvellement plus fréquent\r\n\r\nPar défaut, Certbot renouvelle quand il reste 1/3 de la durée. Pour un cert 6 jours, ça veut dire renouveler à 2 jours restants. Ça laisse peu de marge en cas de panne. Vous pouvez forcer un renouvellement plus tôt :\r\n\r\n\r\n\r\nLe timer Certbot tourne deux fois par jour par défaut, ce qui est suffisant. Pas besoin de l'accélérer.\r\n\r\n5.4 Cas d'un certificat sur IP\r\n\r\n\r\n\r\nNote importante : Certbot ne sait pas encore installer automatiquement les certs IP dans Nginx ou Apache. Il faut éditer la config manuellement pour pointer vers et , et configurer un pour le reload.\r\n\r\n5.5 Plan de bascule recommandé\r\n\r\n1. Semaine 1-2 : un domaine non critique (un sous-domaine de test, un service interne) en . Surveillez les renouvellements.\r\n2. Semaine 3-4 : étendez à la moitié de votre dev/staging.\r\n3. Semaine 5-6 : migration progressive en prod, en commençant par les services les moins critiques.\r\n4. À tout moment : possibilité de retour arrière en supprimant du fichier de config Certbot dans .\r\n--\r\n\r\n6. Pièges à éviter\r\nNe migrez pas tout en même temps. Si votre hook de reload a un bug, vous le découvrez sur un seul service, pas sur 50.\r\nNe désactivez pas le monitoring d'expiration sous prétexte que c'est automatisé. L'automatisation peut casser silencieusement. Un check externe qui hurle à J-2 reste indispensable.\r\nAttention aux secrets stockés dans des configs autres que Certbot. Si vous avez des certs poussés manuellement vers un CDN, un load balancer cloud ou un firewall TLS-inspectant, le passage à 6 jours impose d'automatiser cette propagation aussi.\r\nPas de cert IP pour un service exposé publiquement à long terme. Si l'IP change, le cert devient inutilisable instantanément. Préférez le DNS quand c'est possible.\r\nVérifiez votre client ACME. Tous les clients ACME ne supportent pas encore les profils. acme.sh, Caddy, lego, Traefik : checkez la version. Certbot 4.0 minimum.\r\n--\r\n\r\n7. Verdict\r\n\r\nLe profil est techniquement supérieur au 90 jours sur le plan sécuritaire. Mais il déplace le coût : moins de risques liés aux clés compromises et à la révocation cassée, plus de risques liés à la chaîne de renouvellement.\r\n\r\nLa règle simple : si votre renouvellement automatique est fiable, migrez. Sinon, fiabilisez-le d'abord — la migration n'en sera que la conséquence naturelle.\r\n\r\nPour la majorité des infras web auto-hébergées (typiquement, un Proxmox + reverse proxy + une dizaine de services derrière), le 90 jours reste un excellent compromis. Le devient pertinent quand :\r\nVous avez besoin de certs sur IP (obligatoire).\r\nVous exploitez des services à forte exigence de sécurité (clés très sensibles).\r\nVous voulez tester votre résilience opérationnelle (le 6 jours est un excellent test de fiabilité de votre stack).\r\n\r\nLe reste du temps, gardez le 90 jours, dormez tranquille, et ressortez ce document quand le CA/Browser Forum imposera 45 jours par défaut (vers 2027-2028).\r\n--\r\n\r\nSources\r\nLet's Encrypt — Six-Day and IP Address Certificates Available in Certbot (mars 2026)\r\nLet's Encrypt — 6-day and IP address certs in general availability (janvier 2026)\r\nDocumentation Certbot — Hooks\r\nCA/Browser Forum Baseline Requirements"},{"uuid":"f884e336-2a4b-4197-b80f-d0bdad770e2c","slug":"20230104-la-balise-rel-me-en-html","title":"20230104 La Balise Rel Me En Html","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-01-06 00:42:30","created_at":"2023-01-06 00:42:30","updated_at":"2023-01-06 00:42:30","tags":[],"plain":"REDIRECT>20230102-la-balise-rel-me-en-html"},{"uuid":"cbfbc502-df32-42eb-a99f-3a75cfcc22e0","slug":"creer-un-point-d-acces","title":"Créer un Point d'Accès Wifi (AP)","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-06 18:46:23","created_at":"2020-12-06 18:46:23","updated_at":"2020-12-06 18:46:23","tags":[],"plain":"Un point d'accès Wifi (AP) consiste à créer un réseau Wifi avec nom (appelé SSID). Ci-dessous, un code pour créer rapidement un point d'accès Wifi avec l'ESP 8266. Le nom de réseau s’appellera ESP1 - AP, stockée dans la variable ssid."},{"uuid":"9710aeae-eadf-4f2e-b776-c6e1c2f10d33","slug":"l-assurance-maladie-me-doit-l-argent","title":"L'Assurance Maladie me doit de l'argent » : anatomie d'une arnaque par hameçonnage","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:05","created_at":"2020-04-17 18:05:20","updated_at":"2026-05-12 20:26:45","tags":[],"plain":"Un beau matin, un courriel atterrit dans la boîte de réception. L'expéditeur affiche fièrement « Assurance Maladie », l'objet annonce un remboursement à percevoir, et un lien promet d'expliquer la marche à suivre pour récupérer la somme due. Tout semble en ordre. Et pourtant, à peine la souris approchée du lien, plusieurs garde-fous se déclenchent les uns après les autres : Thunderbird signale une tentative de fraude, Firefox refuse de charger la page, et le site cible n'a rien à voir avec . Bienvenue dans le monde du phishing, ou hameçonnage en français.\r\n\r\n\r\n\r\nCe billet revient sur l'anecdote en détail, mais surtout l'utilise pour décortiquer le mécanisme général de ce type d'arnaque, comprendre pourquoi elle fonctionne sur tant de personnes, et adopter quelques réflexes simples qui suffisent à s'en prémunir dans la quasi-totalité des cas.\r\n\r\n1. Qu'est-ce que le phishing ?\r\n\r\nLe terme phishing est un mot-valise construit sur l'anglais fishing (la pêche) et phreaking (piratage téléphonique). L'image est exacte : l'escroc lance un appât — un message crédible — et attend qu'une victime morde. Sa cible n'est pas un ordinateur ni une faille technique, c'est un humain. Plus précisément, c'est la confiance, l'inattention ou l'envie de cette personne.\r\n\r\nConcrètement, une attaque par hameçonnage consiste à se faire passer pour un organisme légitime (banque, impôts, Assurance Maladie, opérateur télécom, service de livraison, etc.) afin d'obtenir de la victime qu'elle livre d'elle-même des informations sensibles : identifiants de connexion, numéro de carte bancaire, copie de pièce d'identité, parfois même un virement direct.\r\n\r\nTrois ingrédients reviennent à chaque fois :\r\nUne marque connue dont l'identité visuelle est imitée (logo, couleurs, ton du message).\r\nUn prétexte émotionnel qui pousse à agir vite : remboursement à percevoir, colis bloqué, compte suspendu, amende impayée.\r\nUn lien qui paraît légitime mais redirige en réalité vers un site contrôlé par l'attaquant.\r\n\r\nL'arnaque ameli.fr coche les trois cases.\r\n\r\n2. Décorticage du courriel reçu\r\n\r\nLe message annonce un versement de l'Assurance Maladie. Le scénario est habilement choisi : recevoir de l'argent flatte, intrigue, et désarme la vigilance. Personne ne se méfie d'un cadeau. Pourtant, en regardant de plus près le lien embarqué dans le message, on découvre une adresse pour le moins surprenante :\r\n\r\n\r\n\r\nTrois éléments doivent immédiatement alerter :\r\n\r\n1. Le domaine n'est pas . Le vrai domaine, lu de droite à gauche en partant du dernier point, est — un hébergeur sud-coréen. Le reste () est un sous-domaine, et le mot n'est qu'un nom de fichier choisi pour tromper. Aucun service public français n'héberge ses pages chez un hébergeur étranger commercial.\r\n2. Le protocole est , pas . Toute page officielle traitant de données personnelles ou bancaires utilise aujourd'hui une connexion chiffrée. Un site qui demande des informations sensibles en clair signe son illégitimité.\r\n3. Les segments sont des marqueurs typiques de campagnes de phishing automatisées : chaque destinataire reçoit un identifiant unique, ce qui permet à l'attaquant de suivre qui a cliqué et d'affiner ses prochaines vagues.\r\n\r\nLire l'adresse d'un lien avant de cliquer dessus est donc la première compétence à acquérir. Sur un ordinateur, il suffit de survoler le lien sans cliquer : l'adresse réelle apparaît en bas de la fenêtre du navigateur ou du client de messagerie.\r\n\r\n3. Les garde-fous techniques font (parfois) leur travail\r\n\r\nDans le cas raconté ici, les outils ont parfaitement joué leur rôle. Thunderbird, le client de messagerie, a détecté que le texte affiché du lien ne correspondait pas à sa destination réelle et a affiché un avertissement clair.\r\n\r\n\r\n\r\nCette détection repose sur une règle simple mais efficace : si le texte visible du lien ressemble à une URL (par exemple ) mais que la destination effective pointe ailleurs, c'est un signal extrêmement fort de tentative de tromperie. Aucun site légitime ne fait cela.\r\n\r\nLe second rempart est intervenu côté navigateur. Firefox, en suivant malgré tout le lien, a interrogé une base de sites malveillants connus (le service Google Safe Browsing, partagé entre les principaux navigateurs) et a bloqué l'accès.\r\n\r\n\r\n\r\nCes protections sont précieuses, mais il faut bien comprendre leurs limites :\r\nElles arrivent toujours en retard. Une nouvelle campagne de phishing fonctionne pendant plusieurs heures, parfois plusieurs jours, avant d'être signalée et ajoutée aux listes noires. Les premières victimes ne sont jamais protégées par ces filtres.\r\nElles peuvent être contournées. L'utilisateur a la possibilité d'ignorer l'avertissement, comme dans l'exemple où la curiosité l'a emporté.\r\nElles ne couvrent pas tous les canaux. Un SMS, un appel téléphonique, un message sur les réseaux sociaux ne déclenchent pas ces alertes.\r\n\r\nLa vigilance humaine reste donc l'ultime ligne de défense, et c'est précisément sur elle que mise l'escroc.\r\n\r\n4. Pourquoi ça marche aussi bien\r\n\r\nComprendre pourquoi tant de personnes se font piéger malgré les avertissements aide à mieux résister. Plusieurs ressorts psychologiques sont systématiquement exploités.\r\n\r\nL'argument d'autorité\r\n\r\nLe message émane d'un organisme officiel, dont la légitimité ne se discute pas. L'Assurance Maladie, les impôts, la banque, La Poste : la marque seule impose le respect et désamorce le doute. L'escroc le sait et choisit toujours une institution familière de sa cible.\r\n\r\nL'urgence ou l'opportunité\r\n\r\nLe cerveau humain traite mal les décisions rapides. Soit le message annonce une catastrophe imminente (« votre compte sera suspendu sous 24 h »), soit il fait miroiter un gain immédiat (« un remboursement de 38,47 € vous attend »). Dans les deux cas, la fenêtre de réflexion se réduit, et c'est exactement l'effet recherché.\r\n\r\nLe mimétisme visuel\r\n\r\nLogos, couleurs, polices, pieds de page : tout est copié à l'identique depuis le vrai site. Pour un œil non entraîné, rien ne distingue le faux du vrai. Et pour cause, le faux a souvent été fabriqué en quelques minutes à partir du code source du vrai.\r\n\r\nLe coût de la vérification\r\n\r\nVérifier prend du temps : ouvrir un onglet, taper l'adresse, se connecter, retrouver son mot de passe. Cliquer ne coûte rien. À court terme, le cerveau choisit toujours la voie la moins coûteuse — et c'est par là que l'escroc s'invite.\r\n\r\n5. La règle d'or : ne jamais cliquer sur un lien d'argent\r\n\r\nDe cette anecdote se dégage un principe qui mérite d'être affiché en grand au-dessus de chaque boîte de réception :\r\nLorsqu'un organisme annonce un versement, un remboursement, un trop-perçu ou tout autre mouvement d'argent en sa faveur, on ne clique jamais sur le lien du courriel. On accède au site par ses propres moyens.\r\n\r\nConcrètement, cela signifie :\r\nOuvrir un nouvel onglet du navigateur.\r\nTaper l'adresse à la main dans la barre d'adresse, ou la sélectionner dans ses favoris.\r\nSe connecter à son espace personnel comme on le fait d'habitude.\r\nVérifier si l'information annoncée par le courriel s'y retrouve réellement.\r\n\r\nDans neuf cas sur dix, l'espace personnel ne mentionne aucun remboursement, et l'origine frauduleuse du message est confirmée. Dans le dixième cas, le remboursement est bien réel, et il sera traité depuis la source officielle sans avoir suivi le moindre lien suspect.\r\n\r\n\r\n\r\nCette règle vaut pour tous les organismes : Assurance Maladie, banques, impôts, CAF, opérateurs, plateformes de commerce. Elle ne demande aucune compétence technique et bloque l'écrasante majorité des tentatives.\r\n\r\n6. Les autres signaux qui doivent éveiller le doute\r\n\r\nAu-delà du lien lui-même, plusieurs détails trahissent souvent un courriel d'hameçonnage. Aucun n'est rédhibitoire à lui seul, mais leur cumul ne trompe pas.\r\n\r\nL'adresse de l'expéditeur. Le nom affiché peut être falsifié à volonté, mais l'adresse email réelle est plus difficile à maquiller. Une adresse en n'a rien d'officiel : seules les adresses se terminant par ou le sont. La règle se généralise : le domaine légitime de chaque organisme est un et un seul, et il s'apprend une fois pour toutes.\r\n\r\nLes fautes d'orthographe et de syntaxe. Une administration française dispose de relecteurs. Un escroc traduit souvent depuis une autre langue, parfois à l'aide d'outils automatiques. Tournures bancales, accents oubliés, fautes d'accord doivent mettre la puce à l'oreille. À noter cependant : avec la généralisation des modèles de langue, ces erreurs disparaissent et ce critère perd progressivement de sa fiabilité.\r\n\r\nUne formule de politesse impersonnelle. « Cher client », « Madame, Monsieur », « Cher utilisateur » : une administration qui dispose de l'état civil de ses assurés s'en sert. Un escroc qui a acheté une liste d'adresses email ne dispose, lui, que de l'adresse.\r\n\r\nUne demande d'informations qu'on ne devrait jamais avoir à fournir. Aucun service public ne demande par courriel un numéro de carte bancaire complet, un mot de passe, un code reçu par SMS, ou la photo d'une pièce d'identité. Si la page d'arrivée réclame ce genre de données, c'est le moment de fermer l'onglet.\r\n\r\nUne pièce jointe inattendue. Une « facture » au format ou envoyée par un organisme public est presque toujours malveillante. Les administrations mettent leurs documents à disposition dans l'espace personnel, pas en pièce jointe.\r\n\r\n7. Que faire en cas de doute, ou en cas d'erreur\r\n\r\nRecevoir un courriel suspect n'est ni grave ni rare. Cliquer dessus par mégarde l'est davantage, mais reste rattrapable. Quelques gestes simples permettent de limiter la casse et de protéger les autres.\r\n\r\nSignaler le message. Le dispositif officiel français s'appelle Signal Spam et permet, via une extension de navigateur ou de client mail, de transmettre les courriels frauduleux aux autorités compétentes et aux fournisseurs d'accès. Pour les SMS, le numéro 33700 joue le même rôle. Pour les tentatives plus sophistiquées, la plateforme Pharos recueille les signalements.\r\n\r\nPrévenir l'organisme usurpé. L'Assurance Maladie dispose d'une adresse dédiée pour transférer les courriels suspects : . La plupart des grandes administrations et entreprises ont une adresse équivalente.\r\n\r\nEn cas de clic accidentel, ne rien saisir et fermer la page. Tant qu'aucune donnée n'a été tapée, le risque est limité au chargement du site, qui peut éventuellement tenter d'exploiter une faille du navigateur. Maintenir son navigateur à jour suffit à neutraliser l'essentiel.\r\n\r\nEn cas de saisie de données, agir vite. Si un mot de passe a été tapé sur le faux site, le changer immédiatement sur le vrai site, et partout ailleurs s'il était réutilisé. Si des données bancaires ont été communiquées, appeler sa banque pour faire opposition. Si une pièce d'identité a été transmise, déposer plainte et demander un signalement auprès de FranceConnect pour surveiller toute usurpation.\r\n\r\n8. Le réflexe à long terme\r\n\r\nAu fil des années, un principe simple et robuste s'impose : considérer par défaut qu'un courriel non sollicité demandant une action en ligne est suspect, et le vérifier par un canal indépendant. Cette posture coûte quelques secondes par message. Elle a évité, chez la plupart de ceux qui l'adoptent, l'écrasante majorité des arnaques en circulation.\r\n\r\nL'anecdote racontée ici se termine bien : les outils ont alerté, la curiosité s'est arrêtée à temps, et l'absence de la moindre saisie sur le faux site a évité tout dégât. Mais elle illustre parfaitement combien le scénario est crédible et combien il est facile, dans un moment de distraction, de baisser la garde.\r\n\r\nLa meilleure protection contre le phishing n'est ni un antivirus, ni un filtre anti-spam, ni un navigateur particulièrement vigilant : c'est l'habitude, lentement acquise, de séparer le messager du message. Un courriel n'est qu'une invitation à vérifier. La vérification, elle, se fait toujours à la source."},{"uuid":"f919a77a-7419-41dc-b680-59cc6cd5b947","slug":"20230102-la-balise-rel-me-en-html","title":"La balise rel me en HTML","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-01-09 22:50:10","created_at":"2023-01-09 22:50:10","updated_at":"2023-01-09 22:50:10","tags":[],"plain":"Édition du 2 janvier 2023 La balise en HTML est utilisée pour indiquer un lien vers une page Web appartenant à la même personne ou à la même organisation qui a créé la page actuelle. Cette balise est souvent utilisée pour relier un profil en ligne, comme un profil sur un réseau social ou un blog personnel, à un site Web principal ou à un site Web professionnel. Voici un exemple de l'utilisation de la balise : Dans cet exemple, la balise indique que le lien vers le compte Twitter de John Doe appartient à la même personne ou à la même organisation qui a créé la page Web actuelle. La balise peut être utilisée en combinaison avec d'autres balises de lien, telles que ou , pour indiquer la relation entre différentes pages Web. Elle peut également être utilisée avec la balise pour indiquer la version préférée d'une page Web parmi plusieurs versions similaires."}] |