Lors de l'envoi d'une liste de diffusion, Let's Encrypt a malencontreusement ajouté automatiquement des adresses de ses clients dans son message (jusqu'à 7 617 tout de même). En cause, un « bug » sur un logiciel utilisé pour la première fois.
Depuis le lancement de la bêta en décembre de l'année dernière, Let's Encrypt rencontre un beau succès. Le service propose pour rappel des certificats SSL gratuitement à ceux qui en font la demande (voir notre analyse). Il est notamment disponible chez Infomaniak, Gandi et OVH, sur le DSM 6.0 de Synology, sur les blogs de Blogger, etc. Depuis le mois d'avril, le projet est même sorti de bêta et a trouvé de nouveaux sponsors de taille.
Quand des adresses email sont automatiquement ajoutées
Bref, tout se déroule bien pour Let's Encrypt, mais un rouage s'est récemment grippé dans cette mécanique bien huilée : une fuite de 7 617 emails de ses utilisateurs. Il ne s'agit pas du résultat d'une attaque contre ses serveurs, mais d'un « bug » lors de l'envoi d'une liste de diffusion.
L'équipe s'explique : « Le 11 juin 2016, nous avons commencé à envoyer un email à tous nos abonnés actifs qui nous ont donné une adresse afin de les informer d'une mise à jour sur notre contrat d'abonnement. Cela a été fait par le biais d'un système automatisé qui contenait un bug qui, par erreur, a ajouté entre 0 et 7 617 autres adresses emails dans le corps du message. Conséquence, les destinataires pouvaient voir des adresses email des autres utilisateurs ».
En 68 minutes : problème détecté, envoi stoppé et publication d'un communiqué
Elle ajoute que « le problème a été détecté et le système arrêté après que 7 618 emails sur environ 383 000 (1,9 %) ont été envoyés. Chaque correspondance contenait par erreur les adresses email des destinataires précédents ». Le premier email ne comportait donc aucune fuite, tandis que le deuxième affichait l'email du premier, le troisième celui des deux premiers... et le 7 618e comportait les adresses des 7 617 précédents destinataires. L'hémorragie s'est arrêtée là puisque l'envoi a été stoppé.
Let's Encrpyt explique que la campagne d'information a été lancée le 11 juin à 3h47 et que le premier rapport signalant un problème a été reçu à 4h20. L'envoi des emails a été arrêté 9 minutes plus tard (4h29) et le premier rapport préliminaire a été rendu public à 5h28, soit un peu plus d'une heure après la réception du rapport d'incident.
Des mesures pour éviter que cela ne se reproduise
Let's Encrypt indique que le bug se situe dans un bout de code qui a été utilisé pour la première fois lors de cette campagne. Il avait été testé et examiné, mais visiblement c'était loin d'être suffisant. Le manque de test est d'ailleurs considéré comme étant la cause première du bug par Let's Encrypt. On se demande tout de même comment un « bug » aussi gros a pu passer à travers des mailles du filet, fussent-elles peu resserrées.
Bien évidemment, l'équipe s'excuse pour « cette erreur » et annonce que des mesures ont été prises afin d'éviter que cela ne se reproduise. Ainsi, les logiciels permettant de diffuser en masse des emails seront désormais testés avec autant de rigueur que ceux ayant trait à la gestion des certificats.
Commentaires (49)
#1
Non mais les gars, ils ont pas d’environnement d’intégration et de préprod ???
#2
LOL mais alors la je dis LOL !
ce n’est pas un bug c’est une fonctionnalité.
#3
Ca c’est du first troll; à 1mn après la publication !!!!!
#4
et le 7 618e comportait les adresses des 7 167 précédents destinataires.
" />
Ca fait quand-même 450 adresses email qui n’ont pas été divulguées…
Bon, évidemment le gag de CommitStrip tombe mal : http://www.commitstrip.com/fr/2016/06/13/the-end-of-an-expensive-era/Edit : le lien passe pas :  http://www.commitstrip.com/fr/2016/06/13/the-end-of-an-expensive-era/
#5
Je regrette de ne pas m’y être inscrit du coup, j’aurai eu une base de 7000 emails potentiellement intéressé par l’hebergement, les services saas, sysadmin… Rahhhh
" />
#6
Ouf je croyais à un bug dans leur certificat !
C’est quand même moins grave…
#7
C’est clair que c’est beaucoup moins grave. Perso, je suis bien content de m’y être inscrit quasi dès le début… et de ne pas avoir reçu leur mail ! Sinon, je serais en train de compter le nombre d’adresse dans mon mail pour savoir combien de personnes ont eu la mienne.
#8
Mais non, il faut bien sauver le pauvre dépressif!
#9
#10
#11
Dont la mienne
" />
EDIT: En fait j’avais pas capté que les adresses étaient dans le corps du message, je pensais que tout le monde avait été mis en destinataire du même mail. Donc je viens de compter, j’étais le 2630ème !
#12
2630 : en progrès, continuez les efforts
" />
#13
Ca va, c’est toujours moins d’adresses que celles contenues dans les chaines que tata Kechua vous envoie 8 fois par jour.
#14
Concrètement ça ne coûte pas grand chose de générer des certificats. Le certificat à 300€ n’est pas de meilleure qualité que celui qui est gratuit, tout ce qui compte c’est en gros que les éditeurs de navigateurs aient confiance dans celui qui édite le certificat.
Une fois que c’est le cas, ça peut tourner sur quelques serveurs de rien du tout, et être financé par les dons de différentes entreprises et associations qui voient un intérêt dans le tout-https.
#15
Tout à fait d’accord avec toi. S’il y a bien un domaine ou ça ne devrait pas coûter grand chose, c’est bien les certificats
" />
" />
" />
À quand la même chose pour Authenticode et autres certificats de signature du code ? Qui me suit ?
#16
Euh non.
C’est pas tant le bug en soi que je reproche, mais que ce soit arrivé en prod. Quand on veut aller trop vite ou qu’on ne fait pas le cycle complet de validation, on arrive à ce genre d’erreur.
#17
#18
#19
Perso, j’ai essayé de mettre un certificat sur mon serveur mais pas moyen…. J’utilise les noms de domaine en fr.nf de azote.org et devinez quoi ? Y’a trop de demandes pour ce TLD ! Allez hop refusé
" />
Bref, je reste donc avec mes certifs auto-signé…
#20
Bon, comme c’est jour du bac philo, tu as 4 heures :
Le gratuit de google est-il gratuit ?
#21
#22
#23
Ah non ! Là, c’est un autre devoir de philo. Et sa réponse risque d’être différente.
#24
#25
Un petit caractère de plus, genre un . ou un + suivant le code, et hop, on concatène au lieu d’affecter une nouvelle valeur. Ensuite, on fait une recette à l’arrache avec que des tests unitaires sur une seule adresse au lieu d’une liste, et on se rend compte du problème en prod. 
" />
#26
#27
#28
Si tu crois que toutes les entreprises dépensent chaque euro dans le but de gagner directement de l’argent, alors tu ne comprends pas le principe du mécénat.
De la même façon, tu dois avoir du mal à comprendre l’intérêt pour les grosses boîtes de contribuer à l’open source, puisque ça ne leur rapporte pas directement de l’argent.
Ce projet est notamment poussé par la fondation Mozilla, qui fournit entre autres … Firefox. Qui est gratuit. Et qui ose dire que Firefox est un projet qui n’est pas respectueux de ses utilisateurs ?
Si c’est concevable pour Firefox, pourquoi ça ne le serait pas pour Let’s Encrypt ?
#29
#30
Tout le monde n’a pas besoin de cette assurance.
J’héberge des petits services pour lesquels je veux du HTTPS avec un certificat valide, mais je ne vais pas payer 300€ pour chacun d’entre eux. Let’s encrypt est la solution à ce problème.
Je ne dis pas qu’il faut faire disparaître les certificats payants, je dis juste que personne ne fournit le service de base gratuitement, alors que ça ne coûte absolument rien de le fournir.
#31
On n’a jamais dit que Mozilla ne gagnait pas d’argent, il faut bien payer les développeurs. Mais c’est vraiment mal les connaître que de croire que leur but premier est de se faire de l’argent à tout prix.
#32
Autant il est assez aisé de vérifier par une procédure automatique que tu es bien le propriétaire d’un DNS autant pour la signature de code je ne vois pas bien comment ils pourraient faire
#33
Ça demanderait un minimum d’étapes manuelles, certes, mais pas de quoi justifier 200-300€/an
" />
#34
Après Let’s encrypt diminue le risque de vol en diminuant la durée de son certificat: 3 mois de mémoire. Là où les agences de certificats proposent un an.
Cette faible durée est compenser par l’automatisation de processus d’enregistrement et de renouvellement.
#35
Spyware ? Keylogger ? Mais de quoi tu parles ?
" />
#36
de plugins de Firefox je dirais. Mais pas sûr que ce soit pertinent, j’imagine qu’il y a une vérification de ce qui est envoyé par les plugins avant l’intégration dans la bibliothèque.
#37
Depuis quand un certificat SSL DV coûte 300€ ?
Même un EV SGC SSL pour un seul domaine peut se trouver à moins de 140€. Mais c’est vrai que la gamme peut monter à 800€ facilement (Symantec)
J’ai acheté des DV à moins de 10€ l’année (Comodo). Bref, c’est cool d’avoir du DV gratuit, mais ça ne sert à rien d’exagérer les prix des Comodo, Geotrust and co.
#38
Hé ben !
" />
Si tu as autant de reproches à faire à Mozilla, je ne voudrais pas voir ceux que tu as en réserve pour les autres acteurs du secteur..
#39
notes bien que je ne dis pas qu’ils sont les seuls… Mais faut arrêter l’angélisme et le marketing viral.
#40
De la même façon, tu dois avoir du mal à comprendre l’intérêt pour les grosses boîtes de contribuer à l’open source, puisque ça ne leur rapporte pas directement de l’argent. Ah mais oui, ils gagnent indirectement je ne dis pas le contraire.Par exemple par le profilage et la collecte des usages, que cela serve a titre d’optimisation marketing personnelle ou a la revente.Le business model actuel c’est le big data. c’est pas moi qui l’invente.
#41
#42
#43
En 68 minutes : problème détecté, envoi stoppé et publication d’un communiqué
La méthode agile dans la vie réelle:
commit, push, deliver…. ARRRRRG !!!! fix, fix, fix, apologize.
#44
Ce que tu payes quand tu prends un certificat auprès d’une autorité de certification, c’est une assurance et des garanties.
D’où les prix élevés.
#45
#46
sisi, c’est juste que le dév a testé qu’avec son adresse (donc un envoi correct :p)
#47
voit pas le rapport entre open source et profilage ou collecte de données.
Ma SSII est spécialisée dans l’open source et je ne vois pas à quel moment on ferait du profilage ou de la collecte.
L’objectif est plutôt d’utiliser un produit qui a pu être réalisé et vérifié par un grand nombre de développeurs afin d’en limiter les bugs (ex: Drupal => +3000 contributeurs) et le coût pour notre client final.
#48
En même temps ils font des certificats, c’est pas des list masters
" />
#49
Pas de chance, mon adresse est dans le top 15…