Blogue Wikimédia/Brouillons/Heartbleed

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Wikimedia Blog/Drafts/Heartbleed and the translation is 88% complete.
Outdated translations are marked like this.

This post has been published at https://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/ . You are welcome to add translations here.

Other languages:
Bahasa Indonesia • ‎Bahasa Melayu • ‎British English • ‎Deutsch • ‎English • ‎Latina • ‎Nederlands • ‎Tiếng Việt • ‎Türkçe • ‎asturianu • ‎azərbaycanca • ‎dansk • ‎español • ‎français • ‎italiano • ‎magyar • ‎polski • ‎português • ‎português do Brasil • ‎suomi • ‎svenska • ‎Österreichisches Deutsch • ‎čeština • ‎русский • ‎татарча/tatarça • ‎українська • ‎ייִדיש • ‎עברית • ‎العربية • ‎فارسی • ‎مصرى • ‎ଓଡ଼ିଆ • ‎தமிழ் • ‎മലയാളം • ‎ไทย • ‎中文 • ‎日本語 • ‎한국어

Réponse de Wikimédia à la vulnérabilité de sécurité « Heartbleed »

Logo pour l’anomalie Heartbleed (le cœur qui saigne).

Le 7 avril a été révélé un problème très répandu dans un composant central (OpenSSL) pour la sécurité sur Internet. La vulnérabilité a maintenant été corrigée sur tous les wikis de Wikimédia. Si vous ne faites que lire Wikimédia sans créer de compte, vous n'avez rien à faire. Si vous avez un compte utilisateur sur un wiki de Wikimédia, vous devrez vous reconnecter la prochaine fois que vous utiliserez votre compte.

Le problème, appelé « Heartbleed », pourrait permettre à des attaquants d’avoir accès à des informations privilégiées sur tout site exécutant une version vulnérable de ce logiciel. Les wikis hébergés par la Fondation Wikimédia ont été potentiellement affectés par cette vulnérabilité durant quelques heures après sa découverte. Cependant, nous n’avons aucune preuve de compromission effective de nos systèmes ou des informations de nos utilisateurs et, du fait de la façon particulière dont nos serveurs sont configurés, il aurait été très difficile à un attaquant d’exploiter cette vulnérabilité afin de récolter les mots de passe des utilisateurs sur nos wikis.

Dès que nous avons été avisés du problème, nous avons commencé à mettre à jour nos systèmes avec des versions corrigées du logiciel en question. Nous avons commencé à remplacer les certificats SSL critiques exposés à l’utilisateur et à réinitialiser tous les jetons de sessions d’utilisateurs. Consultez le calendrier complet de notre réponse ci-dessous.

Tous les utilisateurs connectés envoient un jeton secret de session avec chacune de leurs requêtes au site. Si une personne malveillante était en mesure d’intercepter ce jeton, elle pourrait se faire passer pour d’autres utilisateurs. La réinitialisation des jetons de tous les utilisateurs a l’avantage de faire se reconnecter tous les utilisateurs à nos serveurs en utilisant la version mise à jour et corrigée du logiciel OpenSSL, ce qui ôte cette attaque potentielle.

Nous recommandons de modifier votre mot de passe en tant que mesure standard de précaution, mais nous ne comptons pas actuellement forcer ce changement pour tous les utilisateurs. À nouveau, il n‘y a pas eu de preuve que les utilisateurs des serveurs de la Fondation Wikimédia ont été la cible de cette attaque, mais nous voulons que nos utilisateurs soient dans une situation aussi sûre que possible.

Merci pour votre compréhension et votre patience.

Greg Grossmeier, au nom des équipes des opérations et plateforme de la Fondation Wikimédia.

Chronologie de la réponse de Wikimédia

(Les heures sont mentionnées dans le fuseau UTC.)

7 avril :

8 avril :

09h08 : Nous commençons à remplacer les certificats SSL.

13h09 : Nous forçons la mise à jour de libssl sur les serveurs des Tool Labs de la Fondation Wikimédia.

16h45 : Tous les serveurs SSL de wikis exposés aux utilisateurs ont de nouveaux certificats en place.

9 avril :

13h54 : Le certificat SSL de ticket.wikimedia.org est remplacé (le dernier)

10 avril :

Foire aux questions

(Cette section sera étendue si nécessaire.)

  • Pourquoi la date « non valide avant » de notre certificat SSL n’a-t-elle pas été changée si vous l’avez déjà remplacée ?
    Notre fournisseur de certificat SSL conserve la date originale « non valide avant » (parfois incorrectement décrite comme la date « publiée le ») dans tout certificat remplacé. Ceci n’est pas une pratique rare. En dehors de la consultation des fichiers .pem liés dans la chronologie ci-dessus, l’autre façon de vérifier que le remplacement a eu lieu est de comparer l’empreinte numérique de notre nouveau certificat avec la précédente.