Une faille de sécurité critique dans le logiciel de virtualisation Xen sera annoncée publiquement le mardi 26 juillet. L'équipe de Xen a d'ores et déjà communiqué les correctifs à Gandi.

Suite à cette annonce, nous avons déployé un correctif venant s'ajouter aux mesures de sécurité mises en place au préalable. Une veille a été ménée sur cette faille de sécurité et nous avons pris la décision de procéder au redémarrage des VMs Xen concernées; assurant ainsi une suppression totale des vecteurs d'attaque potentiels. 

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services nous allons les contacter directement par email. Les clients n'ayant pas reçus de communication ne sont pas concernés.

Dans un souci de maîtrise du temps d'interruption de service, mais également de gestion des services hébergés sur ces VMs, nous recommandons grandement à tous les clients concernés de procéder au redémarrage leurs plates-formes par eux-mêmes dès maintenant et avant la date butoir du 26 Juillet 2016. Dans le cas où les VMs des clients notifiés par email n'ont pas été redémarrées, celles-ci seront redémarrées automatiquement par nos équipes entre le mardi 26 juillet 7h00 UTC et le jeudi 28 juillet 16h00 UTC. À noter qu'une indisponibilité d'un maximum de 30 minutes par VM redémarrée est à prévoir lors de cette opération. 

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Les fabuleux progrès des 80 dernières années en matière d'informatique, de réseaux et de chiffrement ont bien souvent été le fruit de la collaboration entre les militaires, le milieu universitaire et occasionnellement des entreprises du secteur privé. Ces technologies, qui ont permis de changer la manière dont l'humanité interagit, ont également créé de nombreux points de friction entre les autorités militaires, souhaitant en limiter l'utilisation à des fins sécuritaires, et les défenseurs des droits de l'homme qui en ont vite compris l'intérêt.

Lorsque Whitfield Diffie et Martin Hellman publient “New Directions in Cryptography” en 1976, ils soulignent en préambule que les communications numériques qui permettront à tous d'échanger, et pas uniquement militaires ou financiers, devront être sécurisées. Ils introduisent la notion de cryptographie à clé publique, qui permet à deux personnes qui ne se sont jamais rencontrées en face à face de communiquer confidentiellement.

Cette solution prévoit la création d'une paire de clés, l'une publique, l'autre privée, en utilisant des fonctions mathématiques. Une clé publique visible permet de chiffrer un message que seule la clé privée peut décoder. Diffie et Hellman résolvent un problème fondamental en cryptographie : la distribution des clés, mais pas leur implémentation dans un usage à sens unique.

Trois chercheurs du MIT, Ron Rivest, Adi Shamir et Leonard Adleman, se penchent alors sur la question. En avril 1977, alors qu'ils sont en vacances ensemble, Ron Rivest est victime d'une insomnie et passe une nuit entière à formaliser ce qui deviendra l'algorithme RSA, pour Rivest, Shamir et Adleman.

Les 3 amis publient leur invention en août 1977 et en déposent le brevet, au travers du MIT, en décembre. En 1982, Rivest, Shamir et Adleman créent l'entreprise RSA Security et se lancent dans la distribution de leur algorithme, au grand dam des autorités militaires.

Les outils de cryptographie ayant été longtemps inscrit à la « U.S. Munitions List », la NSA affirme dès juillet 77 que le développement privé d’outils de cryptographie tels que le chiffrement à clé publique et l’algorithme RSA constitue une menace pour la sécurité nationale.

Tandis que les années 80 voient l’outil informatique sortir des laboratoires de recherche universitaires et des bureaux du gouvernement, pour arriver dans les entreprises et chez les particuliers, un projet de loi est soumis au Parlement américain afin de restreindre l’usage public des outils de cryptographie. Phil Zimmerman, un activiste anti-nucléaire du Colorado, décide de se lancer dans un projet qu’il définira plus tard comme relatif aux droits de l’Homme : appliquer le chiffrement à clé publique aux communications par email.

En juin 1991, il lance la première version de « Pretty Good Privacy », ou PGP, qui utilise la fonction Bass-O-Matic pour chiffrer les emails. Dans la documentation, où il décrit le chiffrement comme une forme de solidarité, il écrit « Si tout le monde prenait l’habitude d’utiliser le chiffrement pour l’ensemble des emails, innocents ou pas, son usage ne serait plus suspicieux ».

Quelques heures seulement après sa mise à disposition en téléchargement, PGP est utilisé par des internautes du monde entier. Malheureusement, cette mise à disposition vaut à Zimmerman les foudres des douanes américaines et de RSA Security. Tandis que les premiers l’accusent de trafic d’armes, puisque PGP est distribué hors des frontières américaines, RSA Security le poursuit pour violation de son brevet.

Zimmerman, pour contrer les attaques gouvernementales, décide de faire imprimer le code source de PGP via les éditions presse du MIT, et peut ainsi le distribuer en bénéficiant de la protection du Premier Amendement. Il rencontre plus de difficultés dans sa défense contre RSA Security et finit par abandonner RSA au profit des algorithmes libres DSA et ElGamal pour la version 3 de PGP.

En 1996, l’entreprise PGP Inc. fusionne avec Viacrypt, titulaire d’une licence RSA, tandis que Netscape poursuit le développement d’une nouvelle technologie basée sur RSA pour sécuriser son navigateur, Secure Socket Layer ou SSL, dont la version 2 est lancée depuis 1995. Les ingénieurs Phil Karlton et Alan Freier travaillent avec le cryptographe Paul Kocher, diplômé en biologie à l’université de Stanford ayant longuement travaillé avec Martin Hellman, pour lancer rapidement la version 3 de SSL.

Zimmerman présente PGP à l’IETF (Internet Engineering Task Force) en 1997 pour y proposer un standard OpenPGP.

Le brevet sur l’algorithme ayant été levé, OpenPGP est aujourd’hui un standard officiel en matière de chiffrement. Le protocole SSL est quant à lui devenu un standard depuis 1999, ainsi que son évolution, le protocole TLS.

Les prédictions de Diffie et Hellman sur l’avenir des communications ont inspiré RSA, dont l’invention a suscité une véritable levée de boucliers des autorités militaires. Pour autant, tandis que TLS/SSL est devenu un protocole universel, l’utilisation de PGP est loin d’avoir été adoptée par tous. C’est pourtant un outil inestimable en matière de liberté d'expression, qui continue à susciter partout dans le monde une bataille acharnée entre gouvernements (totalitaires ou pas) et défenseurs des Droits de l’Homme.


ImageMagick a annoncé une faille de sécurité, CVE-2016-3714 (lien en anglais), qui pourrait permettre à des utilisateurs mal-intentionnés d'éxecuter des commandes à distance à travers des noms de fichiers spécialement conçus pour ce faire.

Nous avons mis à jour les instances Simple Hosting avec la routine officielle pour protégér les sites web de nos clients. Si vous êtes utilisateur d'ImageMagick, assurez-vous de redémarrer vos instances à partir du 4 Mai 2016 à 18h00 pour que la routine soit prise en compte.

Vous pouvez redémarrer vos instances à partir du site web de Gandi ou depuis la ligne de commandes avec Gandi CLI : $ gandi paas restart {nom_de_l'instance}

N'hésitez pas à contacter le Support en cas de souci, ou si vous avez des questions concernant ce sujet.


Suite à cette annonce, nous avons déployé un correctif venu s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer les VMs KVM pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services nous allons les contacter directement par email. Les clients n'ayant pas reçu de communication ne sont pas concernés.

Les VM des clients concernés (sauf si elles l'ont été entre temps) seront redemarrées le jeudi 19 novembre. Une indisponibilité maximum de 30 minutes par VM impactée est à prévoir.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.

Une faille de sécurité critique dans le logiciel de virtualisation Xen sera annoncée publiquement le jeudi 29 octobre. L'équipe de Xen nous a d'ores et déjà communiqué les correctifs.

Suite à cette annonce, nous avons déployé un correctif venu s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer les VMs Xen pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services, nous allons les contacter directement par email. Les clients n'ayant pas reçu de communication ne sont pas concernés.

Nous conseillons vivement aux clients impactés de redémarrer eux-mêmes leurs serveurs afin de s'assurer que tous les services repartiront correctement. Les VM des clients concernés qui n'auront pas été redémarrées, le seront de façon automatique entre le jeudi 22 et le mercredi 28 octobre.
Une indisponibilité maximum de 30 minutes par VM impactée est à prévoir.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Une nouvelle release de WordPress, la version 4.3.1, vient corriger 2 vulnérabilités de XSS (Cross Site Scripting) et une vulnérabilité au niveau de la gestion des privilèges permettant, par exemple, à un utilisateur non-autorisé de créer des articles privés.

Il est temps de vérifier si les mises-à-jour automatiques de votre WordPress sont au point, ou de lancer une mise-à-jour manuellement. Vous avez en effet tout intérêt à boucher les 3 vulnérabilités et les 26 bugs que la version 4.3.1 de WordPress vient corriger.

Deux sont des vulnérabilités de XSS (Cross Site Scripting) et concernent le traitement des balises "shortcode" dans les versions 4.3 et antérieures, ainsi que la page de la liste des utilisateurs. Le dernier est un problème de gestion des privilèges où, dans certains cas, un utilisateur non-autorisé pouvait publier des articles privés et les marquer comme "sticky".

Même si cette version n'apporte pas de nouvelles fonctionnalités, elle vient tout de même corriger 26 autres bugs de la version 4.3. En tout, se sont 64 fichiers qui ont été modifiés pour améliorer différents aspects du CMS le plus populaire au monde, de l'interface à son fonctionnement interne.

À vos consoles d'administration, donc ! Ou rendez-vous sur le changelog officiel pour avoir de détails (en Anglais): https://codex.wordpress.org/Version_4.3.1


Une faille de securité dans le logiciel de virtualisation QEMU a été annoncée en début de semaine dernière.

Baptisée Venom et identifiée par le code CVE-2015-3456, cette faille permettrait à un attaquant d'exploiter les hôtes vulnérables depuis une machine virtuelle.

Suite à cette annonce, nous avons immédiatement déployé un correctif qui venait s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer certaines VM pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Ce redémarrage préventif n'impactera qu'une petite partie de nos clients. Seuls les clients concernés seront contactés directement par email pour leur permettre de réagir ou d'anticiper le redémarrage de leurs services.

Les VM des clients concernés (sauf si elles ont été redemarrées entre temps) seront redémarrées lundi 25 mai à 11:59pm PDT, soit mardi 26 mai à 07:59am UTC.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Suite à l'annonce de la faille de sécurité Ghost, nous vous recommandons vivement de procéder à la mise à jour de vos serveurs en installant les paquets mis à votre disposition par les éditeurs de votre distribution.

Cette faille, qui affecte depuis novembre 2000 la bibliothèque glibc utilisée sur la plupart des distributions Linux et d'autres variantes d'Unix, est très sérieuse, puisqu'elle permet l'exécution de code à distance.

Nous nous assurons de la mise à disposition des paquets correctifs au plus vite sur mirrors.gandi.net

Sont d'ores et déjà disponibles les correctifs suivants :

Nous tâcherons de mettre cette liste à jour au fur et à mesure que les différents éditeurs publieront leurs correctifs.

Si vous êtes client Simple Hosting, nous vous recommandons de redémarrer votre instance.


A partir du mercredi 22 octobre [1], Gandi peut délivrer les certificats SSL en SHA-2 pour les certificats de type Standard, Pro ou Business. Le SHA-1 et SHA-2 sont des familles de fonctions de hachages utilisées pour signer les certificats. Comme bien souvent lorsqu'il s'agit de sécurité, de nouvelles versions sont publiées lorsque des problèmes de sécurité inhérents à l'algorithme sont trouvés dans les précédentes versions. Ce qui est le cas ici pour SHA-2, qui vient progressivement remplacer SHA-1.

Il ne faut cependant pas paniquer, compromettre un certificat émis en SHA-1 reste une tâche ardue.

Notez que si vous utilisez actuellement un certificat en SHA-1 ou que vous souhaitez en acquérir un, vous ne rencontrerez aucun problème. Il s'agit d'une période de transition où les deux algorithmes sont supportés. La fin du support de SHA-1 est prévue au 1er Janvier 2017.

Les autorités de certification, navigateurs internet et les systèmes d'exploitation prennent en charge le SHA-2 pour la majorité. Vous pourrez cependant rencontrer des problèmes d'incompatibilité dans certains cas, par exemple avec Mozilla Firefox car les nouveaux certificats racine n'ont pas encore été ajoutés. Ceci est en cours du côté des différents navigateurs.

Deux possibilités s'offrent à vous :

  • Vous souhaitez proposer uniquement du SHA-2 à vos visiteurs et la question de la compatibilité ne se pose pas : vous pouvez installer uniquement le certificat intermédiaire en SHA-2. Cette solution est optimale en terme de sécurité car toute la chaine de certification sera en SHA-2. Conseillé dans le cas où vous souhaitez mettre en avant la sécurité au détriment de la compatibilité, ou si vous êtes certains que vos visiteurs disposent de navigateurs compatibles, dans le cas d'un intranet par exemple.
  • Vous souhaitez proposer du SHA-2 mais éviter les problèmes d'incompatibilité avec certains navigateurs qui n'ont pas encore mis à jours les certificats racine : Vous pouvez utiliser le certificat intermédiaire en SHA-2 ainsi que le cross-signed. Cependant, le dernier élement de la chaine de vérification sera en SHA-1, ce qui n'est pas optimal en terme de sécurité. Cette solution est utile durant la période de transition, dès lors que les navigateurs auront effectué la mise à jour, vous pourrez enlever le certificat dit 'cross-signed' de votre applicatif. Conseillé dans le cas où vous souhaitez passer en SHA-2 sans perturber les visiteurs dont le navigateur ne dispose pas des dernierts certificats racine.

Attention, de nouveaux certificats intermédiaires, différents de ceux utilisés pour ceux en SHA-1, ont été émis avec les certificats signés en SHA-2. Veillez à utiliser le bon certificat intermédiaire en fonction de votre certificat. Vous pouvez vérifier la signature du certificat avec la commande :

$ openssl x509 -in example.crt -text -noout|grep Issuer

En fonction du résultat retourné, vous saurez quel certificat intermédiaire installer.

  • Pour les certificats issus en SHA-1 : Issuer: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
  • Pour les certificats issus en SHA-2 : Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2

Voici un exemple de chaine de certification valide pour un certificat SHA-2 :

Certificate chain

0 s:/OU=Domain Control Validated/OU=Gandi Standard SSL/CN=example.com

i:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2

1 s:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2

i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

Règles de livraison en SHA-1 et SHA-2 :

Jusqu'au 1er janvier 2016 :

  • Les certificats ayant une date d'expiration se situant après le 1er janvier 2017 seront délivrés en SHA-2 uniquement, même si la CSR a été signé en SHA-1.
  • Les certificats seront délivrés en SHA-1 si la CSR a été généré en SHA-1
  • Les certificats seront délivrés en SHA-2 si la CSR a été généré en SHA-2 

Après le 1er janvier 2016 :

  • Tous les certificats seront délivrés en SHA-2, quelque soit la signature de la CSR

Notez que vous pouvez tout à fait regénérer votre certificat en SHA-2 si vous disposez déjà d'un certificat, en soumettant de nouveau la CSR signé en SHA-2. N'oubliez pas de mettre à jour le certificat intermédiaire en conséquence sur vos applicatifs.

Pour plus d'information, nous vous invitons à vous rendre sur notre documentation disponible à l'adresse suivante :

[1] - Quelques jours avant cette date, notre partenaire Comodo a commencé à émettre des certificats en SHA-2 dans le cas où la date d'expiration du certificat allait au delà de 2017. Nous n'avons pas été en mesure de répercuter ce changement dans notre documentation à ce moment là, nous tenons à nous en excuser. C'est désormais chose faite, vous retrouverez toutes les informations nécessaires à la mise en place de votre certificat émis en SHA-2 en suivant les liens ci-dessus.


Une vulnérabilité majeure a été révélée par les mainteneurs d'OpenSSL, voir la CVE-2014-0160 [2].

Vous devez prendre les mesures nécessaires afin de préserver la sécurité de vos services utilisant des certificats X509/SSL avec cette librairie.

Gandi a pris en compte cette vulnérabilité connue comme le "heartbleed" bug [1], touchant les versions 1.0.1 jusqu'à 1.0.1f d'OpenSSL. La version 1.0.1g ou la version 0.9.8 ne sont pas touchées.

Cette faille de sécurité existe depuis un moment et il y a une probabilité que des certificats X509/SSL aient été compromis, de manière indétectable.

Afin de résoudre ce problème, et uniquement si vous utilisez cette version d'openssl, vous devrez effectuer les opérations suivantes :
  • si vous utilisez un certificat SSL sur notre plateforme PaaS (SimpleHosting) ou via notre accélérateur web, nous avons corrigé cette faille dans la nuit, nous vous donnerons plus de détails sur l'exposition de vos données.
  • si vous utilisez notre plateforme IaaS, aussi appelée Gandi Serveur Cloud, ou un autre fournisseur d'hébergement dédié/virtualisé, en premier lieu, vous devez mettre à jour la version d'OpenSSL sur tout serveur que vous administrez vous-même (voir les mises à jour de sécurité de votre gestionnaire de paquets, par exemple, avec Debian, mettez à jour la liste des paquets avec apt-get update, puis installez la dernière version d'OpenSSL avec apt-get install openssl, ensuite redémarrez tout service utilisant cette librairie, assurez vous bien d'utiliser le dépôt officiel debian-security),
  • si vous utilisez nos certificats SSL sur des services externes, il faudra, après avoir vérifié la version d'OpenSSL utilisée, dans un second temps, regénérer la clé privée et le certificat X509/SSL correspondant, voir le tutoriel suivant pour obtenir de l'aide : http://wiki.gandi.net/fr/ssl/regenerate


Change the news ticker size