Partagez vos données sensibles à plusieurs en toute sécurité avec Trousseau

trousseau

En ces temps d’espionnite aigüe, alors que le monde entier s’inquiète des agissements de la NSA mais court confier ses données sensibles à des entreprises américaines hébergées dans le cloud (donc aux États-Unis), le chiffrement des données est un problème de plus en plus critique, même si vous n’avez strictement rien à vous reprocher (pour l’instant).

Il y a une douzaine d’années, je commençais toutes mes introductions à la sécurité des systèmes d’information par la même phrase :

Ce n’est pas parce que vous n’êtes pas paranoïaque que cela signifie que tout le monde n’est pas contre vous.

Trousseau est un logiciel multi plate-formes développé en Go par mon camarade en subversion informatique Théo (suivez-le sur Twitter et sur Github, c’est un ordre), qui permet de partager des documents chiffrés à plusieurs. Trousseau se base sur GPG, un autre logiciel libre, et un standard en matière de chiffrement.

GPG est très bien, mais il souffre de deux handicaps : non solum il ne permet de chiffrer des documents que vers un seul destinataire, sed etiam il ne permet pas de gérer un ensemble de documents à un seul endroit.

Trousseau apporte une solution à ces deux problèmes problème en utilisant un container unique chiffré, et en le rendant accessible à plusieurs utilisateurs dès lors qu’ils disposent d’une clé GPG. Il est possible de rajouter ou de supprimer simplement des destinataires, et le trousseau peut ensuite être synchronisé via git (même un compte public Github fait l’affaire, jusqu’au jour où une des clés se fait compromettre bien profond).

Techniquement, les données sont stockées dans un fichier plat sous la forme d’un ensemble de paires clés / valeurs, qui, chiffré, aura l’apparence de n’importe quel message GPG, c’est à dire un bloc ASCII (mais rassurez-vous ça marche aussi l’été).

Mais passons à la pratique.

Pour utiliser Trousseau, il vous faut :

  • Une clé GPG, valide, et de préférence publiée sur un serveur de clés. Je vous laisse chercher sur Google pour les tutos.
  • La dernière version de Trousseau.
  • Des amis avec qui partager des trucs (mais c’est pas obligé, les sans amis fixes peuvent aussi partager des trucs avec eux-même).

Installer Trousseau est simple comme bonjour. Il suffit de télécharger la dernière release disponible sous forme de binaire pour Linux et Mac OS X. Pour ce qui est de la configuration, RTFM c’est pas bien dur.

On va ensuite créer un trousseau. Il vous faut d’abord récupérer la clé des destinataires, en l’occurrence Alice et Bob (oui, ceux de Crypto Appliquée).

$ gpg --recv-keys --keyserver pgp.mit.edu bob@mail.com alice@mail.com
$ trousseau create 042D9183,alice@mail.com,bob@mail.com

Vous êtes maintenant prêt à partager tous vos petits secrets honteux avec Alice et Bob. L’utilisation est über simple :

$ trousseau set 123 abc
key-value pair set: 123:abc
$ trousseau set web.browser.shameful.history --file /home/fred/.chrome/history.bin
[lot of useless output]

On peut donc chiffrer aussi bien des chaines de caractères que des fichiers.

Pour récupérer les infos :

$ trousseau get 123 
123 key's value: abc

Et puisque c’est un logiciel libre, rien ne vous empêche de contribuer, ou d’en auditer le code pour vous assurer que Théo n’a pas rajouté sa clé GPG dans les destinataires en mode ninja. Quant à moi, je vous laisse, il faut que j’aille chiffrer la sextape de ma voisine d’en face avant que ma femme ne tombe dessus.


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

4 lessons every startup should learn from the Heartbleed catastrophe

State of the Internet after heartbleed

On a catastrophic scale of 1 to 10, the Heartbleed OpenSSL bug is an 11 says cryptography guru Bruce Schneier. Being the biggest security breach the Internet has ever faced, I hope it’s also the biggest I’ll ever see in my entire life.

The exact financial, technological and human consequences of Heartbleed will probably never be known, but 2 days after the issue was revealed, there are already a few lessons we can learn.

There are at least 4 of them.

1. No last minute feature push. Never.

Quoting Netcraft (via Fabrice Bachella) on Half a million widely trusted websites vulnerable to Heartbleed bug, Support for heartbeats was added to OpenSSL 1.0.1 (released in 2012) by Robin Seggelmann, who also coauthored the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension RFC. The new code was committed to OpenSSL’s git repository just before midnight on new year’s eve 2011.

If you’ve ever wondered what was the worst time to push a new, critical feature on a product, new year’s eve is what you’re looking for. Actually, pushing or releasing a new feature during the whole holiday season is a very bad idea.

No one will care about it. Period. No one else but your peer reviewer (if you have any) will see your code. I don’t think pushing TLS heartbeat extension on another date would have prevented the Heartbleed bug, but more people would have read the code, and hence maybe noticed the problem.

And if you break something, no one will be there to support your users, fix the bug, push a new release etc…

Applied to a startup, it’s simple: if you’re about to release something, and someone has to push last minute code, postpone the release. Either your feature won’t be as good as it should be, or your code will break at some unexpected place, or you’ll have to rollback because it breaks. Trust me, I’ve seen hundreds examples of last minute code push, hopefully none with effects as big as Heartbleed.

2. Monoculture kills

66% of the servers connected to the Internet use OpenSSL to provide https. This, like every kind of monoculture, is a real problem for many reasons.

Monoculture is a danger for security. It means security researchers will all focus on the same target instead of working on many. This was true in the late 80’s and 90’s when MS DOS and Windows were sharing 95% of the desktop market share: viruses coders were only targeting the platforms as they were easy to exploit, and most people were using them. It’s still true today with Wordpress powering 12% of the sites worldwide, and using third party poorly coded if not willingly infected themes and plugins.

Monoculture is a danger for innovation. Innovation comes from diversity and the will to explore new, undiscovered paths. On the contrary, monoculture brings the “everyone does it this way, so we’re doing it too” syndrome. I remember, 10 years ago when we were developing Web sites and applications for Internet Explorer 6 only. It was a real pain as alternate browsers were supporting new feature faster. For the record, Internet Explorer 6 was discontinued only 2 years ago.

Monoculture is not sustainable. OpenSSL is a free software, but imagine what would happen if 66% of the https market share was controlled by a single company? A quasi monopoly, you name it, with all the underlying problems, like some countries not being able to access the basic crypto feature. Imagine what can happen when monoculture comes farming: a whole regions or a whole country starts producing the same crop because the soil is good and the external demand is high. If for some reasons the prices fall or the weather is bad, the whole country can go to bankruptcy and become unable to buy food for its inhabitants.

As a startup, you’re both experimenting and need to move very fast. Moving fast means (but not only) being able to pick up a solution and change if it doesn’t work, doesn’t scale or does not do the job. This is not compatible with monoculture, and it can even kill you faster than you’ll ever imagine.

There are alternatives to openssl

For this very issue, Brad Fitzpatrick was not using OpenSSL but the Go language SSL/TLS library. By choosing to bypass the usual Linux + Apache / Nginx + OpenSSL stack, he was able to avoid being vulnerable to Heartbleed.

Avoiding monoculture is not about reinventing the wheel because the existing sucks, it’s about using the right tool at the right place, eventually deciding to build something from scratch because the existing does not fit the needs.

3. Peer reviews are not enough, but you shouldn’t live without them

Errare humanum est, and peer reviews help makes less mistakes, but they’re not enough. OpenSSL heartbeat support code was reviewed by one of OpenSSL official maintainer, but it did not prevent the bug to be pushed anyway.

Peer review is a very powerful process that should be applied at every level of any company, for everything that should go in production: code, indeed, commercial stuff, marketing, communication… In a peer review, you get someone to review, comment and (in)validate your work, on a peer to peer basis. This means the peer review gets rid of the hierarchical levels to focus on self improvement. While the reviewer does not validate the work, it’s not considered as ready to ship. As many peers can be involved in a single peer reviews if needed.

Peer reviews allow to:

  • avoid mistakes (but not all of them)
  • improve the whole company knowledge of what’s going on (in small companies)
  • have everyone to improve.

4. Automated tests are not an option

What’s been striking me when reading Robin Seggelmann commit is the total lack of automated tests.

One of the first things I’ve ever heard from a startup founder back in 1998 was about how making mistakes was OK as long as you don’t repeat the same mistake twice. Some people still think automated tests are useless and peer reviews a loss of time, so do some companies, because manual testing ahead of a release should be enough.

Automated tests are not made to avoid making mistakes. Automated tests are made to avoid making the same mistake twice. Indeed, every piece of code should be pushed with tests to valide it, but that’s not the most important. For every bug happening in an application life should come an automated test ensuring that issue will never happen again.

If you don’t see the point, see the tests as a knowledge management tool. A knowledge management tool, even an enterprise social network allows you to track every business issue you’ll ever face, evert complicated negotiation you face so you don’t need to face them twice.

When planning a release, every company should include the time to write automated tests. It should allow time to write automated tests for upcoming feature, and for upcoming bugs as well.

There are probably more lessons to be learnt from Heartbleed catastrophe, but these are the most obvious. I hoped you enjoyed reading this article despite my not yet perfect English style. I’m continuously working on improving it, asking American friends to proofreed my texts when they can, and writing down my most frequent mistakes so I won’t repeat them.


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

. @rtaibah You already made the first steps to #indieweb setting up your...

. @rtaibah You already made the first steps to #indieweb setting up your domain and adding a page with you rel="me" links. The next step is finding a tool that suits your needs, for POSSEing, and there’s the wiki Project page for that.

Try, play, and hack if you can to make your tool of choice feel like home. Oh, and indeed Wordpress is not the only option, but I’m a little biased here, as I’m developing my own tool: trying to avoid monoculture.

IndieWeb Projects page: http://indiewebcamp.com/Projects


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

À quel point le Minimal Viable Product doit-il être minimal ?

Keep it simple stupid

A quel point le MVP (Minimal Viable Product, produit minimal pour espérer être viable) doit-il être minimal ?

Un minimum viable product doit être aussi minimal que possible, dès lors que ça ne met pas sa viabilité en danger.

Merci Captain Obvious.

Ce week-end, je me suis retrouvé devant un problème que je ne pouvais pas résoudre simplement en hackant des trucs existants avec des bouts de ficelle pour les faire fonctionner ensemble.

J’ai commencé à réfléchir à une solution, et au bout de quelques minutes, le déclic :

Hé, mais ça pourrait être une bonne idée de business ça !

J’ai pris mon plus joli Moleskine, celui que j’utilise pour noter tous mes merveilleux projets qui ne verront jamais le jour faute de temps, d’argent, de motivation ou de compétences (faute de temps, d’argent ou de motivation pour les acquérir).

Sur la page de gauche, j’ai écrit mon problème en toutes lettres. Sur la page de droite, j’ai commencé à décrire la manière dont je pensais le résoudre.

Pendant le week-end, j’ai appliqué les conseils de Nicolas Boileau, qui n’aurait certainement pas imaginé qu’on puisse appliquer son Art Poétique à la conception d’un MVP.

Vingt fois sur le métier remettez votre ouvrage : Polissez-le sans cesse et le repolissez ; Ajoutez quelquefois, et souvent effacez

Tout à l’heure, quand j’ai rangé mon Moleskine pour une nuit porteuse de conseils, j’avais accouché d’une monstrueuse usine à gaz, aux antipodes de mon problème initial. Vue ma vitesse de développement, sortie prévue dans 10 ans.

Parle-moi de MVP.

C’est toujours pareil : le problème, la prise de conscience qu’on ne doit pas être le seul à l’avoir, l’idée de départ, et les itérations.

Ah les itérations…

J’adore les développements itératifs, parce qu’ils permettent de sortir très rapidement quelque chose, de tester, et de modifier ce qui ne va pas avant d’ajouter d’autres choses. Mais les itérations dans le brainstorming, ça devrait être interdit si on veut aboutir à quelque chose de simple.

À chaque itération, l’idée initiale se développe, on trouve de nouveaux positionnements, de nouvelles fonctionnalités, on explore de nouvelles pistes.

À chaque itération on s’éloigne du problème de départ, mais pire encore, on finit par ne plus le résoudre, alors qu’on apporte des solutions à des problèmes qu’on n’a pas encore. Juste au cas où.

Dans ce cas, la meilleure chose à faire, c’est d’arracher la page de droite du carnet, pour ne garder que la formulation initiale du problème.

Pour chaque ligne sur la page de droite, il n’y a qu’une seule question à poser :

Est-ce que ça résout mon problème initial et seulement mon problème initial ? Vraiment ?

Si c’est le cas, on garde. Si ce n’est pas le cas, on oublie. Pour l’instant.

À la fin de la journée, on doit avoir couché sur le papier les spécifications d’un produit qui apporte une réponse au besoin initial, et rien d’autre.

Il est là le MVP.


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

Your idea is nothing if someone does not make it live. Every Sunday, a thread...

Your idea is nothing if someone does not make it live. Every Sunday, a thread will be posted on Hackers News to share product ideas so people who have no time / skills to make them can see their problems solved by people who’re looking for a new project to start but have no exciting idea yet.

Definitely worth following as you’ll probably find some gems in the yet another social network for XXX crap.

https://news.ycombinator.com/item?id=7541601


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

. @pefavre Sales driven development is critical to a company growth, but is...

. @pefavre Sales driven development is critical to a company growth, but is often misunderstood both by product team and sales people.

Sales driven development should mean driving your company according to the sales metrics, what works and what does not, with a long term perspective. Unfortunately it’s very often confused with personal opportunism and short term sight.

When this happens (and it unfortunately happens a lot), it creates a very dangerous unbalance in the company, which may screw everything up in the end.


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

. @fredhermelin Chaque fois que j’entends “le XXX français”...

. @fredhermelin Chaque fois que j’entends “le XXX français” ou “l’alternative à YYY” j’ai envie d’éventrer des bébés loutres avec les dents.

Le Snapshat français ? Ça sert à quoi de le mentionner ? À nous rassurer et nous dire qu’on est un pays encore capable d’innover ? Rien que dire “le XXX français” montre qu’on est déjà derrière ceux qui ont vraiment innové. La vérité c’est qu’on se focalise encore sur un marché de 65 millions de consommateurs potentiels alors qu’on a un marché de 6 milliards à portée de nos frontières.

Quant à “l’alternative à YYY” (qui vaut aussi pour “le XXX français d’ailleurs”), c’est pitoyable : ça montre juste un clone bête et méchant. Où est la valeur ajoutée ? Quel est le facteur différenciant ? On n’arrivera à rien à toujours comparer les alternatives à l’original ou à la success story. J’en ai fait l’expérience à plusieurs reprises, et c’est la meilleure manière de ne pas avancer et ne jamais se démarquer, et au final de toujours rester derrière.

Est-ce qu’on ne pourrait pas un peu arrêter de se mettre des oeillères et arrêter de crier cocorico chaque fois qu’une boite française copie un truc qui a marché aux États-Unis ?


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

If you plan to start a new project, make it something really new. If...

If you plan to start a new project, make it something really new. If it’s tech related, start with a technology that is completely new to you (maybe a new programming language). If it’s mostly a human one (they all have a human side), start with a brand new team. If you’re used to working alone, start working with someone else.

Starting a new project should not be doing yet another thing you already master. A new project should disrupt you, push you out of your comfort zone, or it’s not really new. That’s the only way to learn quickly a lot of things.


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

Getting rid of the Twitter::Error SSL_connect certificate verify failed message on FreeBSD 10

Securité, je passe le premier

If you’re running FreeBSD 10 with Ruby 2.0 or 2.1, and use the Twitter gem or any other gem trying to establish a secure connection using OpenSSL, you probably already encountered the following message:

Twitter::Error: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/rest/client.rb:96:in `rescue in request'
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/rest/client.rb:92:in `request'
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/rest/client.rb:63:in `get'
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/request.rb:22:in `perform'
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/request.rb:29:in `perform_with_object'
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/rest/utils.rb:39:in `perform_with_object'
        from /usr/local/lib/ruby/gems/2.1/gems/twitter-5.8.0/lib/twitter/rest/users.rb:257:in `user'
        from (irb):3
        from /usr/local/bin/irb:11:in `<main>'

This probably means you’re running the ports based OpenSSL. Contrary to the base OpenSSL version, the port one does not read the cert.pem file from /etc/ssl but from /usr/local/etc/openssl.

You now have 2 ways to fix that.

If /etc/ssl/cert.pem exists, just create a symlink to /usr/local/etc/openssl/cert.pem.

If /etc/ssl/cert.pem does not exist, get the Curl cacert file:

wget -O /usr/local/etc/openssl/cert.pem http://curl.haxx.se/ca/cacert.pem

This will fix your OpenSSL issue.


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.

Fermeture du Rayon UX suite à une décision judiciaire

A t37 tank

J’ai 10 jours pour fermer ce blog et en transférer contenu et nom de domaine à l’armée soviétique sous peine d’une astreinte quotidienne de 100.000 Roubles. Ce sont 11 ans passés à écrire ici, dont 8 pour ce seul blog qui vont donc partir en fumée.

Fin janvier, j’ai reçu une mise en demeure d’un grand cabinet d’avocats parisien mandaté par la Рабоче-крестьянская Красная Армия m’ordonnant de céder à son client le nom de domaines t37.net et l’intégralité des contenus publiés au 31 janvier 2014 pour violation de copyright.

Le T-37 était en effet un char amphibie léger conçu et produit par l’Armée Rouge à partir de 1932 et utilisé durant la seconde guerre mondiale jusqu’en 1944. Le bureau des plans en a déposé le nom hors d’URSS, et même si cela peut paraître absurde, les lois successives sur l’extension de la durée de vie de la propriété intellectuelle rendent la demande de l’armée rouge parfaitement légale.

Les raisons invoquées pour la mise en demeure sont l’utilisation d’un symbole de la lutte pour la dictature de prolétariat à des fins de propagande pour les startups et la libre entreprise, toutes les deux des éléments glorifiant le capitalisme galopant. Il semble donc que le Политическоe бюро ait décidé de faire un exemple avec cette histoire et que d’autres actions puissent être en cours. Si je n’étais pas personnellement visé, cette utilisation des lois sur la propriété intellectuelle mises en place pour éviter que Mickey ne tombe dans le domaine public aurait presque de quoi me faire rire.

Après avoir vérifié l’authenticité et la validité de la mise en demeure, j’ai appelé mon avocat avec la ferme décision d’aller au tribunal, et la certitude que le ridicule de l’affaire la ferait classer sans suite. C’est malheureusement là que les choses se sont emballées.

3 jours après avoir déposé plainte, j’ai reçu un coup de téléphone de mon avocat, visiblement paniqué. Nous nous sommes donnés rendez-vous dans un lieu public, et il m’a expliqué qu’il se dessaisissait de l’affaire, que je n’avais absolument aucune chance de gagner, et que personne n’accepterait de me défendre. Il a fini par m’expliquer qu’il avait reçu la visite de deux chargés de mission de l’Élysée, et que la Présidence, échaudée par ce qui s’était passé ces dernières semaines en Crimée avait décidé de ne pas risquer de voir des chars soviétiques plus modernes que le T-37 entrer dans Paris. Il a même admit du bout des lèvres que la volonté du premier ministre de ne pas céder pourrait avoir été la cause du remaniement ministériel qui a eu lieu aujourd’hui, et non les élections municipales comme les média tentent de nous faire croire.

Je sais bien qu’il ne s’agit que d’un blog, et que la valeur de t37.net est plus affective qu’autre chose, mais cette histoire m’a fait perdre le sommeil. Depuis que j’ai commencé à publier mes articles ici, j’ai passé des milliers d’heures à écrire, développer mon thème, répondre aux commentaires ou aux emails… et j’ai du mal à imaginer tout cela disparaitre du jour au lendemain.

Tout cela pourrait pourtant avoir des conséquences positives à tous points de vue.

Ces dernières semaines, j’ai énormément réfléchi à l’écriture en général, et au blogging en particulier. Le Web est rempli d’écrivaillons, de journalistes autoproclamés, et de blogueurs soi-disant intellectuels. Cette fermeture, peut-être la première d’une longue série devrait permettre de nettoyer tout ça, et d’améliorer la qualité des contenus publiés sur Internet. Ces 12 dernières années, j’ai écrit beaucoup trop d’articles de fond que 99% des gens cessaient de lire avant la fin de l’introduction. Il est temps pour moi de pivoter vers la publication de photos de chats mignons et de memes amusants.

Asta la vista, baby!


Cet article a été publié par Frédéric de Villamil sur Le Rayon UX | Si vous l'avez lu ailleurs sans qu'un lien ait été fait vers l'article original, c'est qu'il a été reproduit illégalement.