1
In the last few weeks (as I write this in late April 2014) two events have combined to deliver a powerful lesson on the security of Open Source software. But it is important to know exactly what the right lesson is. I have seen reports that Heartbleed was a proof of something fundamentally wrong with the Open Source model, because it denied the accuracy of Eric Raymond’s famous saying “With many eyeballs all bugs are shallow.” The Heartbleed bug was in a significant number of systems (actually about one-sixth of Internet sites, as far as I can tell from an analysis of how many sites use OpenSSL, and what percent of those use the versions of the software that are affected). There was a bit of hyperbole in how bad it was, but it is no doubt still pretty bad. But how did that happen? I will refer everyone to an excellent article that has all of the details. It is called How Did the Heartbleed OpenSSL Bug Happen? (http://www.digitaltrends.com/computing/how-did-the-heartbleed-openssl-bug-happen/#!FLdxR), and I recommend looking at it. It is short and to the point. Basically, there was a request to have an extension to OpenSSL to provide something called a TLS Heartbeat extension. This is a perfectly reasonable thing to do, and is covered in RFC 6520, Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension (https://tools.ietf.org/html/rfc6520). As the RFC makes clear, the purpose is to provide a “keep alive” functionality without requiring a renegotiation. OpenSSL was just trying to be compliant in adding a capability that the Internet Engineering Task Force had decided should be provided. But how does the OpenSSL project handle this?
Au cours des dernières semaines (au moment où j'écris ceci, fin avril 2014) deux événements se sont télescopés pour nous donner une puissante leçon sur la sécurité des logiciels Open Source. Mais il est très important de connaître précisément la bonne leçon. J'ai vu, par les rapports que Heartbleed fournissait, la preuve que le modèle Open Source est fondamentalement erroné, parce qu'il invalidait le dicton bien connu d'Eric Raymond, « Quand il y a de nombreuses paires d'yeux, tous les bugs sont superficiels. » Le bug Heartbleed infestait un nombre significatif de systèmes (en fait, pour autant que je sache, d'après l'analyse du nombre de sites utilisant OpenSSL et le pourcentage de ceux-ci qui utilise les versions du logiciel affectées, environ le sixième des sites Internet). L'importance du problème fut quelque peu exagérée, mais il n'empêche qu'il soit sans aucun doute très sérieux. Comment cela a-t-il pu arriver ?
Je vais vous aiguiller vers un excellent article avec tous les détails. Il s'appelle « How Did the Heartbleed OpenSSL Bug Happen? » (comment le bug Heartbleed OpenSSL a-t-il pu exister ?) (http://www.digitaltrends.com/computing/how-did-the-heartbleed-openssl-bug-happen/#!FLdxR) et il mérite votre attention. C'est court et concis. Essentiellement, une extension à OpenSSL fut demandée, qui fournirait quelque chose qui s'appelle une extension TLS Heartbeat. C'est une chose tout à fait raisonnable à faire, qui est traitée dans RFC 6520, Transport Layer Security (TLS) et Datagram Transport Layer Security (DTLS) Heartbeat Extension (https://tools.ietf.org/html/rfc6520). Comme le RFC l'indique clairement, le but en est de fournir une fonctionnalité « keep alive » (garder actif) sans qu'une renégociation ne soit nécessaire. OpenSSL essayait tout simplement de s'y conformer en ajoutant une capacité qui, d'après la demande de l'Internet Engineering Task Force, devait être fournie. Mais comment le projet OpenSSL le fait-il ?
2
The first thing we notice is that OpenSSL has a core team of just 11 people, most of them volunteers, and only one full-time person devoted to the project. Generally, they get about $2000 a year in donations, and make some money from support contracts. In other words, they are stretched tight. A volunteer in Germany, Dr. Robin Seggelmann, wrote the code to implement RFC and submitted it for review. Dr. Seggelmann is a respected academic and computer science researcher, and there is no possible way to suggest either malice or stupidity here. He did not actually have commit rights to OpenSSL, so he submitted the code to the project members who do have those rights, and they reviewed it. Seeing nothing wrong with the code, and verifying that it did what it said it would do (i.e. implement a Heartbeat) the code was put into production in early 2012. The problem was discovered by Google researchers and by a Finnish company, Codenomicon, at about the same time, and it was made public in April 2014. There is some suggestion that there was talk from one of the Google people that may have pointed the Codenomicon in the right direction, but perhaps it was simply independent discovery. These things happen. But as Steve Marquess of OpenSSL Foundation said “The mystery is not that a few overworked volunteers missed the bug; the mystery is why it hasn’t happened more often.”
La première chose à remarquer est que l'équipe de base d'OpenSSL ne comporte que 11 personnes, la plupart des bénévoles, et seulement une personne à temps complet dédiée au projet. En règle générale, ils reçoivent des dons d'environ 2 000 $ US par an et les contrats d'assistance leur rapportent un peu d'argent. Autrement dit, leur budget est très limité. Un bénévole en Allemagne, le docteur Robin Seggelmann, a écrit le code pour implémenter RFC et l'a soumis pour évaluation. Le docteur Seggelmann est très respecté en tant qu'universitaire et chercheur en informatique ; il est hors de question de suggérer la malveillance ou la bêtise dans son cas. En fait, il n'avait pas les droits de confirmation (Commit) vers OpenSSL et a donc soumis le code aux membres du projet ayant ces droits. Ce sont eux qui l'ont évalué. Ils n'ont rien vu d'incorrect dans le code et, après avoir vérifié qu'il faisait ce qu'il était censé faire (c'est-à-dire implémenter un Heartbeat), ils l'ont mis en production début 2012.
Au même moment ou presque, le problème fut découvert par des chercheurs de Google et par une société finnoise, Codenomicon, et ils l'ont révélé au public en avril 2014. Certains suggèrent que l'une des personnes de Google en a parlé et que cela aurait pu montrer la voie à Codenomicon, mais il se peut qu'il s'agisse tout simplement d'une découverte indépendante. Ce sont des choses qui arrivent. Mais, comme Steve Marquess de la OpenSSL Foundation remarqua, « Le mystère n'est pas que quelques bénévoles débordés n'aient pas vu le bug ; le mystère est pourquoi cela n'est pas arrivé plus souvent ».
3
TrueCrypt The other event I want to talk about is the TrueCrypt audit, which released preliminary results recently. As you may recall, in the wake of the Edward Snowden revelations, there was general anxiety about the security of encryption, and people wanted to know if their encryption had been weakened or a backdoor inserted by the NSA, GCHQ, or other government agencies. In the case of TrueCrypt, you again have an open-source project, with the wrinkle that the developers were deliberately anonymous (and based in Eastern Europe). Pre-Snowden, that might not have aroused too much speculation, but post-Snowden people wanted answers. The TrueCrypt Foundation did the right thing. They raised money (I contributed to the crowd-funded campaign) and enlisted Dr. Matthew Green, a highly-respected cryptography expert who teaches at Johns Hopkins University, to put together a team to perform an audit of the code. This is a lengthy and difficult task, but the first phase has been completed, and while there are criticisms of certain sloppiness errors, there is no sign of any deliberate errors. You can read a good report on this at novainfosec.com, and that article has a link to the actual report if you want to read it.. This first phase looked at the bootloader and the Windows kernel driver implementations. There is a second phase planned, to go into the cryptography itself, which will use a completely different team of researchers. So what were the results? Well, TrueCrypt is not perfect, but to expect that would be unrealistic in any case. The audit team did find a certain amount of sloppiness, which probably derives from the fact that the project was done by volunteers and grew organically. But the audit team found no evidence in Phase 1 that there were any deliberate problems or “back doors” in the code. This is good news since this is one of the major open-source programs to offer serious encryption. If you want to encrypt a directory, a drive, or an entire computer, this will do the job for you, and so far there is no evidence that the encryption is compromised (though there are things they can do to tighten up the code). And of course we should wait for the Phase 2 audit before giving them a clean bill of health.
True Crypt
L'autre événement dont je voudrais parler est l'audit de TrueCrypt, qui a récemment publié des résultats préliminaires. Vous vous rappelez sans doute que, à la suite des révélations d'Edward Snowden, il y avait une anxiété généralisée au sujet de la sécurité du chiffrement et les gens voulaient savoir si leur chiffrement avait été affaibli ou si la NSA, le GCHQ ou autres agences gouvernementales y avait inséré une porte dérobée. Pour ce qui concerne TrueCrypt, vous avez à nouveau un projet Open Source, mais, dans ce cas, les développeurs, basés en Europe de l'Est, ont fait exprès de garder l'anonymat. Avant Snowden, cela n'aurait peut-être pas généré trop de spéculation, mais, après Snowden, les gens voulaient des réponses. La TrueCrypt Foundation a agi comme il le fallait. Ils ont collecté des fonds (j'ai contribué lors d'une campagne de financement participatif) et ont engagé le docteur Matthew Green, un expert en cryptographie très respecté et un enseignant à l'Université Johns Hopkins, pour qu'il rassemble une équipe devant auditer le code. C'est une tâche difficile qui prend beaucoup de temps, mais la première phase est terminée et, alors qu'ils ont critiqué certaines erreurs de négligence, ils n'ont trouvé aucune indication d'erreurs intentionnelles. Vous pouvez en lire un bon compte rendu à novainfosec.com et cet article contient un lien vers le vrai rapport si vous voulez le lire. Cette première phase a examiné les implémentations du bootloader et du pilote du noyau Windows. Une deuxième phase doit avoir lieu, pour évaluer la cryptographie même ; l'équipe de chercheurs sera entièrement nouvelle.
Bon. Quels en étaient les résultats ? TrueCrypt n'est pas parfait, mais s'attendre à sa perfection aurait été de toute façon irréaliste. L'équipe d'audit a bien trouvé des instances assez nombreuses de négligence, dues, sans doute, au fait que le projet soit créé par des bénévoles et ait connu une croissance organique. Mais, lors de la phase 1, l'équipe d'audit n'a trouvé aucun élément suggérant qu'il y ait des problèmes délibérés ou des « portes dérobées » dans le code. C'est une bonne nouvelle, puisque c'est l'un des principaux programmes Open Source à proposer un chiffrement sérieux. Si vous voulez chiffrer un répertoire, un disque ou un ordinateur entier, vous pouvez le faire avec TrueCrypt et, jusqu'à présent, il n'y a pas d'indications d'une compromission du chiffrement (bien qu'il y ait des choses qu'ils peuvent faire pour renforcer le code). Bien entendu, cependant, nous devrions attendre la phase 2 de l'audit avant de les déclarer en « bonne santé ».
4
Lessons Learned These programs are important to the Internet, so where was the support? This gets at a fundamental problem of companies treating Open Source like it is a free lunch. It is not, for, as you should know, There Ain’t No Such Thing As A Free Lunch (TANSTAAFL). Open source is really just a different model for developing and supporting software, one that relies on participation by all of the interested parties. If all of these companies were relying on OpenSSL, for instance, where was their participation? After the fact, it looks like many of them woke up. The Linux Foundation has put together a consortium of major companies. To quote from an Ars Technica article (http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/) on the subject “Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Qualcomm, Rackspace, and VMware have all pledged to commit at least $100,000 a year for at least three years to the “Core Infrastructure Initiative,” Linux Foundation Executive Director Jim Zemlin told Ars.” This initiative will be aimed at more than just OpenSSL, but that is good. It means that these companies are taking seriously their responsibility to support the code they rely on. This is in great contrast to the somewhat ridiculous move by Theo de Raadt to create a fork called LibreSSL. This sounds more like ego than a constructive move. I would stick with OpenSSL and give LibreSSL a pass until such time as they can show a long track record of success. A good general rule in security is that new code is more dangerous than code that has been around for a long time.
Des leçons apprises
Ces programmes sont importants à l'Internet, alors où était le soutien ? Cela démontre un problème fondamental : des entreprises traitent l'Open Source comme si c'était totalement gratuit. Ça ne l'est pas, car, comme vous devriez le savoir, « There Ain't No Such Thing As A Free Lunch (TANSTAAFL) » (Rien n'est jamais gratuit). L'Open Source n'est en fait rien d'autre qu'un autre modèle pour le développement et le soutien de logiciels, qui dépend de la participation de toutes les parties concernées. Si toutes ces entreprises comptaient sur OpenSSL, notamment, où était leur participation ? Il semblerait que pas mal d'entre elles se sont réveillées après coup. La Linux Foundation a créé un consortium de sociétés majeures. Voici une citation tirée d'un article dans Ars Technica ((http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/) à ce propos : « Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel Microsoft, NetApp, Qualcomm, Rackspace et VMware ont tous promis de fournir au moins 100 000 $ par an pendant au moins trois ans, au “Core Infrastructure Initiative” annonça Jim Zemlin, directeur exécutif de la Linux Foundation, à Ars. » Cette initiative ciblera plus que OpenSSL, mais c'est très bien. Cela signifie que ces sociétés prennent au sérieux leur responsabilité de soutenir le code dont ils dépendent. Cela contraste fortement avec l'idée quelque peu ridicule de Theo de Raadt de créer une branche (« a fork ») appelée LibreSSL. Cela sent davantage l'égo qu'une idée constructive. Je resterai avec OpenSSL et oublierai LibreSSL jusqu'à ce qu'ils puissent démontrer de nombreuses années de succès. Une bonne règle générale dans le domaine de la sécurité est que du code nouveau est plus dangereux que du code qui existe depuis un certain temps.
5
Security is hard, and is a different skill set than most development. Dr. Seggelmann is a smart guy who was trying to implement a requirement in an RFC. His code did in fact do that. It was reviewed by someone else on the OpenSSL team, and they did not see any problems with it and put it into production. It sat there for two years before someone noticed a potential problem. The reason a number of smart people missed this is that it takes a different skill set to do security. In hindsight, it is easy to say they should have brought in a specialist, and I think the Core Infrastructure Initiative will help address this. Bugs are not shallow if the eyeballs are not there. Both TrueCrypt and OpenSSL had small groups of developers with limited resources. Everyone else just assumed that the code was fine, and never tried to look at it. And given that Security requires a specialized skill set, just adding eyeballs is not enough, they need to be the right kind of eyeballs. A question this raises in my mind is about the governance of critical open source projects. Perhaps we need a little more structure to the process to avoid these kinds of problems. Fixing this requires money, among other things. One of the key take-aways regarding the OpenSSL project is that they were on what I called a “shoestring” budget, where on average they received $2,000 per year in donations. Contrast this with the cost of the TrueCrypt audit, where they appear to have raised about $60,000 so far, and I doubt that is any too much. They put together a team of professionals who understand the work, and that can go through $60,000 in no time. I always tell people they need to support Free Software, and that includes financial support. If you are only interested in what you can get for free, you will get these kinds of results because the resources will not be there.
La sécurité est ardue et nécessite un autre ensemble de compétences que le développement standard. Dr. Segglemann est un mec intelligent qui essayait d'implémenter une exigence dans un RFC. Le code qu'il a écrit l'a en fait réalisé. C'était évalué par d'autres de l'équipe OpenSSL, ils n'ont pas vu de problèmes et l'ont passé en production. Il y était depuis deux ans avant que quelqu'un décèle un problème potentiel. La raison pour laquelle de nombreuses personnes intelligentes n'ont rien vu, est que faire de la sécurité exige d'autres compétences. Avec le recul, il est facile de dire qu'ils auraient dû faire appel à un spécialiste, et je pense que le Core Infrastructure Initiative aidera dans ce domaine.
Les bugs ne sont pas superficiels, si les paires d'yeux n'existent pas. Les deux, TrueCrypt et OpenSSL, avaient de petits groupes de développeurs avec des ressources limitées. Tous les autres ont simplement supposé que le code était bien et n'ont jamais essayé de le regarder. Étant donné que la Securité nécessite un ensemble de compétences spécialisées, rajouter des paires d'yeux ne suffit pas ; elles doivent être des yeux qui savent voir. Cela m'amène à me poser des questions concernant la gouvernance de projets Open Source critiques. On a peut-être besoin que le processus soit un peu plus structuré pour pouvoir éviter ce genre de problèmes.
Corriger ceci nécessite de l'argent, entre autres choses. Voici un des points essentiels à retenir concernant le projet OpenSSL : ils avaient un maigre budget, où, en moyenne, ils recevaient 2 000 $ par an en dons. Ceci est à comparer avec le coût de l'audit TrueCrypt, où ils semblent avoir recueilli environ 60 000 $ jusqu'à présent et je pense que ce n'est pas assez. Ils ont créé une équipe de professionnels qui comprennent le travail et qui peuvent dépenser 60 000 $ en un rien de temps. Je dis toujours qu'il faudrait soutenir les Logiciels Libres et cela comprend un soutien financier. Si tout ce qui vous intéresse est ce que vous pouvez avoir gratuitement, vous aurez ce genre de résultats, car les ressource nécessaires n'y seront pas.
6
The advantage of Open Source software is not that it is bug-free. No software of any kind is bug-free. We make a grave mistake to think so. And it probably is not even correct to think that Open Source has fewer bugs. As we have seen, the weakness of the “many eyeballs – shallow bugs” theory is that, for many Open Source projects, even critical ones, there simply are not that many eyeballs, and often the ones that are there may not be the ones we need to detect subtle problems such as security issues. That does not imply the opposite, however. The idea that Open Source has issues does not mean that Proprietary Software does any better, as the recent IE bug illustrates (as I write this, people are being advised to stop using IE altogether because of a fundamental security issue. Look up “Operation Clandestine Fox” if you want more details.) The superiority of Open Source is principally that issues generally are addressed quickly. Patches for the Heartbleed bug started to roll out within hours of the disclosure. Patches for the IE bug will at best show up in the next round of Microsoft patches, which could mean waiting a month. Furthermore, with Open Source the whole code is on display, so the quality of our information is much better. With proprietary software the code is never available, the information about the bug tends to be sketchy at best, and in some cases companies will try to keep any information from going out because it could have an adverse effect on their bottom line. In the case of OpenSSL, Simon Phipps has offered a very interesting article (http://podcasts.infoworld.com/d/open-source-software/heartbleed-postmortem-openssls-license-discouraged-scrutiny-241781?source=rss_security), based on work of David Wheeler, that points to the license as a source of problems. OpenSSL used a license all of their own which was copy-left, but incompatible with the GPL. And this creates a disincentive for anyone to get involved. He quoted Eben Moglen as saying that the open source license acts as the “constitution of the community” which governs how everyone participates. By having a license that no one else uses, they had the effect of putting in ground rules for participation that no one else understood. The lesson here is that you should not try to re-invent the wheel. There are plenty of good, well-understood, open source licenses out there, and you should use one of them so that the largest number of contributors will be involved. This is one of the reasons that Phipps, Executive Director of OSI, strongly discourages any new license applications. It just isn’t a good idea, and people need to stop this needless proliferation
L'avantage des logiciels Open Source ce n'est pas qu'ils n'ont pas de bugs. Aucun logiciel d'aucune sorte n'est exempt de bugs. Nous faisons une grave erreur de le croire. Et il n'est sans doute pas correct de penser qu'il y a moins de bugs dans l'Open Source. Comme nous venons de le voir, la faiblesse de la théorie « beaucoup de paires d'yeux - bugs superficiels » est que, pour ce qui concerne beaucoup de projets Open Source, même des projets critiques, il n'y a tout simplement pas autant de paires d'yeux que cela. En outre, celles qui sont présentes peuvent ne pas être celles dont nous avons besoin pour détecter des problèmes subtils tels des problèmes de sécurité. Cela n'implique pas le contraire, cependant. L'idée que l'Open Source a des problèmes ne veut pas dire que les logiciels propriétaires font mieux, regardez notamment le récent bug IE (au moment où j'écris ceci, on conseille aux gens de ne plus utiliser IE du tout par suite d'un problème de sécurité fondamental. Pour plus de détails, cherchez « Operation Clandestine Fox ».) La supériorité de l'Open Source est principalement que, en règle générale, les problèmes sont traités rapidement. Des correctifs pour le bug Heartbleed ont commencé à se déployer dans les heures suivant la divulgation du problème. Des correctifs pour le bug IE commenceront à être disponibles au mieux dans le prochain cycle des correctifs Microsoft, ce qui pourrait vouloir dire une attente d'un mois. Qui plus est, avec l'Open Source, tout le code s'affiche et ainsi la qualité de notre information est meilleure. Pour ce qui concerne les logiciels propriétaires, le code n'est jamais disponible, l'information au sujet du bug est souvent au mieux incomplète et, dans certains cas, des sociétés essaient d'empêcher la dissémination d'information, car cela pourrait avoir une incidence défavorable sur leurs bénéfices.
Dans le cas de OpenSSL, Simon Phipps propose un très intéressant article (http://podcasts.infoworld.com/d/open-source-software/heartbleed-postmortem-openssls-license-discouraged-scrutiny-241781?source=rss_security), basé sur le travail de David Wheeler, qui désigne la licence comme source de problèmes. OpenSSL a utilisé une licence qui leur appartenait, qui était copyleft, mais incompatible avec le GPL. Et cela dissuade quiconque de s'y impliquer. Il a cité Eben Moglen selon lequel, la licence Open Source sert « la constitution de la communauté » qui régit la participation de tous ses membres. L'effet d'une licence que personne d'autre n'utilise était de mettre en place des règles de base que personne d'autre ne comprenait. Ici, la leçon est que vous ne devez pas chercher à réinventer la roue. Il existe des tas de bonnes licences Open Source, qui sont bien comprises, et vous devez en utiliser une afin qu'un très grand nombre de contributeurs s'impliquent. C'est une des raisons pour lesquelles Phipps, le directeur exécutif de l'OSI, décourage fermement des applications pour une nouvelle licence. Ce n'est tout simplement pas une bonne idée et les gens doivent arrêter cette prolifération superflue.
7
Addendum TrueCrypt Status? June 10th, 2014 by Michael Kennedy Ironically, an event at the end of May 2014 delivered a further, and still extremely mysterious, security lesson. The TrueCrypt website was suddenly changed: • It advised users that TrueCrypt (TC) was insecure. • It recommended users to migrate to BitLocker (a Microsoft product, proprietary, runs on some editions of Vista, Win-7, Win-8, and Win-Servers). • All the forum’s messages are gone - which has annoyed many. • And the download links retrieved TC version 7.2 (for Linux, Windows, and Mac OS X platforms), but these builds appear to allow TC users to handle already encrypted TC data – but not to create new TC volumes.
Addendum Etat actuel de TrueCrypt ? le 10 juin 2014, par Michael Kennedy
Il est ironique de constater qu'un événement à la fin de mai 2014, nous a donné une autre, et encore extrêmement mystérieuse, leçon de sécurité.
Le site Web de TruCrypt fut modifié tout d'un coup :
• Les utilisateurs furent avisés de l'insécurité de TruCrypt.
• Les utilisateurs furent conseillés de migrer vers BitLocker (un produit Microsoft, propriétaire, fonctionnant sous certaines versions de Vista, Win-7, Win-8 et Win-Servers).
• Tous les messages du forum avaient disparu, ce qui agaça beaucoup de monde.
• Et les liens vers le téléchargement récupérèrent la version 7.2 de TC (pour Linux, Windows et Mac OS X), mais ces logiciels semblaient permettre aux utilisateurs de TC de gérer des données déjà cryptées par TC, mais pas de créer de nouveaux volumes TC.
8
Speculation There has been massive speculation on this development. A few examples: • Has the website been hijacked - maybe by some other encryption organisation - and the TC authors/owners not bothered to react? • Did that recent Audit (as covered by Kevin), or some similar review, detect some weakness, or some backdoor, and have the developers abandoned TC? • Why is BitLocker, specifically, recommended? • Was TC too secure, and has the/some government, NSA, etc, tried to kill TC? • Did the/some government put pressure on the developers (to insert backdoors, etc) - which they resisted? • Was the/some government or the NSA, etc, behind TC in the first place, and was their cover about to be blown? • Did the developers just abandon TC? Unhappy?, paid off?, backdoors/hacks revealed? • This list goes on…
Spéculation
Il y avait, et il y a encore, énormément de spéculation sur ce développement. Quelques exemples :
• Le site Web a-t-il été piraté - peut-être par une autre organisation de chiffrement - et les auteurs/propriétaires de TC n'ont pas pris la peine de réagir ?
• Est-ce que l'audit récent (traité par Kevin), ou une critique similaire, a détecté une faiblesse, ou quelque porte dérobée et les développeurs ont-ils abandonné TC ?
• Pourquoi le conseil précis d'utiliser BitLocker ?
• TC était-il trop sécurisé et le/un gouvernement, la NSA, etc., ont-ils essayé de tuer TC ?
• Est-ce que le/un gouvernement a essayé d'exercer des pressions sur les développeurs (pour qu'ils insèrent des portes dérobées, etc.) - pressions auxquelles ils ont résisté ?
• Est-ce que le/un gouvernement ou la NSA, etc. était derrière TC à l'origine et est-ce que cela allait être révélé ?
• Les développeurs ont-ils tout simplement abandonné TC ? Insatisfaits ? Ont-ils été payés pour partir ? Des portes dérobées/des hackeurs furent-ils révélés ?
• Cette liste continue…
9
What Now? As of June 10th, I don’t know who/what to believe. I’ve used TrueCrypt for some years, on Linux and Windows platforms, and recommended it to clients. From a usage perspective, TC is a super product, cross-platform, and a pleasure to deploy and use. However, until the current TC status is clarified, I’m recommending: • If you’re an existing TC user, and if you’re using builds prior to 7.2, hopefully, it’s OK to continue to use it? • If you’re on 7.2, or if you’re planning to adopt TC, then seek an older TC build, or an alternative product that suits your needs. Some Comments, References, Alternatives: • TrueCrypt’s own website - http://truecrypt.sourceforge.net/ • TC Version 7.1a (all platforms, executables, some sources) - http://truecrypt.ch/downloads/ • Ars Technica - http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/ • Bruce Schneier (TrueCrypt WTF) - https://www.schneier.com/blog/archives/2014/05/truecrypt_wtf.html • Bruce Schneier (Auditing TC, now somewhat out-of-date) - https://www.schneier.com/blog/archives/2014/04/auditing_truecr.html • Steve Gibson’s take (GRC) - https://www.grc.com/misc/truecrypt/truecrypt.htm • Slashdot - http://it.slashdot.org/story/14/05/28/2126249/truecrypt-website-says-to-switch-to-bitlocker • Alternatives at Wikipedia (See also 7-Zip, and VeraCrypt, DCrypt, etc, on Sourceforge) - http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software • PS: Good summary in WindowsSecrets Newsletter - http://windowssecrets.com/newsletter/the-life-and-untimely-demise-of-truecrypt/
Et maintenant ?
À dater du 10 juin, je ne sais pas qui/quoi croire. J'utilise TrueCrypt depuis quelques années, sous Linux et sous Windows et je l'ai recommandé à des clients. Du point de vue de son utilisation, TC est un produit super, multi-plateforme et très agréable au déploiement et à l'utilisation. Cependant, jusqu'à ce que le statut actuel de TrueCrypt soit clarifié, je recommande :
• Si vous êtes déjà utilisateur de TC et utilisez des versions d'avant la 7.2, alors l'on ne peut qu'espérer que c'est OK de continuer à l'utiliser.
• Si vous utilisez la 7.2, ou si vous envisagez d'adopter TC, alors cherchez une version plus ancienne ou un produit alternatif qui répond à vos besoins.
Quelques commentaires, références et alternatives :
• Le site Web même de TrueCrypt - http://truecrypt.sourceforge.net/
• TC Version 7.1a (toutes plateformes, exécutables, quelques sources) - http://truecrypt.ch/downloads/
• Ars Technica - http://arstechnica.com/security/2014/05/truecrypt-is-not-secure-official-sourceforge-page-abruptly-warns/
• Bruce Schneier (TrueCrypt WTF) - https://www.schneier.com/blog/archives/2014/05/truecrypt_wtf.html
• Bruce Schneier (L'audit de TC, un peu périmé maintenant ?) - https://www.schneier.com/blog/archives/2014/04/auditing_truecr.html
• L'avis de Steve Gibson (GRC) - https://www.grc.com/misc/truecrypt/truecrypt.htm
• Slashdot - http://it.slashdot.org/story/14/05/28/2126249/truecrypt-website-says-to-switch-to-bitlocker
• Des alternatives sur Wikipedia (Voir aussi 7-Zip et VeraCrypt, DCrypt, etc., sur Sourceforge) - http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
• PS. - Bon résumé dans la newsletter de WindowsSecrets - http://windowssecrets.com/newsletter/the-life-and-untimely-demise-of-truecrypt/**