diff --git a/content/crypto/2016.03.ssl-trust.md b/content/crypto/2016.03.ssl-trust.md
new file mode 100644
index 0000000..065e820
--- /dev/null
+++ b/content/crypto/2016.03.ssl-trust.md
@@ -0,0 +1,205 @@
+Title: Avez vous confiance en SSL?
+Headline: Tour d'horizon du fonctionnement de SSL et des solutions pour le sécuriser.
+Date: 2016-03-25
+
+Dans le cadre [des ateliers d'autodéfense numérique](http://autodefense-numerique.readthedocs.org/en/latest/),
+j'ai passé un peu de temps à creuser sur l'utilisation de SSL puisque
+contrairement à ce que la plupart des personnes ont encore tendance à croire,
+le petit cadenas (qui prouve qu'une connexion SSL est en cours) n'est
+**absolument** pas suffisant.
+
+Allez hop, c'est parti pour:
+
+- un tour d'horizon du fonctionnement de SSl
+- quelques moyens contourner cette "protection" en faisant une attaque en pratique
+- un tour des solutions existantes actuellement et de pourquoi je ne les trouve
+  pas vraiment satisfaisantes.
+
+## Comment fonctionne SSL?
+
+Pour expliquer les problèmes de SSL, j'ai d'abord besoin d'expliquer comment
+tout ça fonctionne.
+
+SSL repose sur l'utilisation de certificats, qui sont générés par des autorités
+de certification (*Certificate Authority* que je nomme *CA* dans la suite de
+l'article).
+
+Les certificats SSL permettent deux choses:
+
+- De garantir que les communications entre les navigateurs (vous) et les sites
+  Web ne sont connues que du détenteur du certificat du site et de vous même.
+- De garantir que le site sur lequel vous vous connectez est bien celui que
+  vous imaginez.
+
+Le navigateur, lors d'une visite d'un site, va télécharger le certificat
+associé puis vérifier que le certificat en question a bien été généré par un
+des *CA* en qui il a confiance.
+
+Imaginons maintenant qu'une des *CA* essaye de savoir ce qui s'échange entre
+mon navigateur et le site de ma banque (protégé par SSL). Comment cela se
+passerait il ?
+
+N'importe quel *CA* peut donc générer des certificats pour n'importe quel site,
+et le navigateur vérifierait, lui, que le certificat a bien été généré par une
+*CA*.
+
+Tout cela ne poserait pas de soucis si les *CA* étaient gérés de manière fiable,
+mais il s'agit d'un travail compliqué, et certains *CA* ont par le passé montré
+des faiblesses.
+
+Par exemple, [DigiNotar](https://en.wikipedia.org/wiki/DigiNotar) (un *CA* des Pays-Bas)
+a été compromise et les attaquant.e.s ont pu générer des certificats SSL
+frauduleux, ce qui leur a permis d'attaquer des sites tels que Facebook ou GMail.
+
+Vous pouvez retrouver une liste des risques et menaces autour des *CA* [sur le
+wiki de CACert](http://wiki.cacert.org/Risk/History).
+
+## Attaque de l'homme du milieu avec SSL
+
+A force de dire que c'était très facile à faire, j'ai eu envie d'essayer
+d'espionner des connections protégées par SSL, et effectivement c'est
+carrément flippant tellement c'est simple.
+
+En l'espace de quelques minutes, il est possible de faire une *attaque de
+l'homme du milieu* en utilisant par exemple un outil nommé [mitm-proxy](http://docs.mitmproxy.org/en/stable).
+
+Pour déchiffrer l'ensemble du trafic SSL, j'ai simplement eu à lancer quelques
+commandes et avoir un *CA* dans lequel le navigateur de la victime a confiance.
+Je l'ai ajouté dans le navigateur cible pour simuler que je l'avais déjà
+(c'est le cas si un des 1200 CA se fait pirater, ce qui me semble une surface
+d'attaque assez large).
+
+Je les colle ici si ça vous intéresse:
+
+```bash
+$ sudo aptitude install mitmproxy
+$ mitm-proxy -T --host
+```
+
+Il faut faire croire à votre victime que vous êtes la passerelle vers
+l'extérieur et à la passerelle que vous êtes la victime:
+
+```bash
+arpspoof -i wlan0 -t victime gateway
+arpspoof -i wlan0 -t gateway victime
+```
+
+Puis dire à notre fausse passerelle de rediriger le trafic des ports 80 et 443
+vers notre proxy:
+
+```bash
+
+sudo sysctl -w net.ipv4.ip_forward=1
+sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 4443
+sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 4443
+```
+
+Et paf, **on voit tout ce qui passe entre la machine et le serveur SSL**. On peut
+d'ailleurs même imaginer faire tourner ces quelques commandes sur un
+raspberry pi, pour aller encore plus vite…
+
+### Key-pinning dans les navigateurs
+
+Actuellement, n'importe quel *CA* peut générer des certificats pour
+n'importe quel site, et c'est en grande partie ce qui pose souci. Une des
+manières de faire évoluer la situation est d'épingler les certificats de
+certains sites directement dans les navigateurs.
+
+Cette approche a le mérite de fonctionner très bien [pour un petit nombre de
+sites critiques (Google, Facebook, etc)](https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h?from=StaticHPKPins.h).
+
+
+### HTTP Public Key Pinning (HPKP)
+
+[*HTTP Public Key Pinning*](https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning)
+est également une solution de *pinning* qui permet d'établir une confiance lors
+de la première connexion avec le site. C'est ce qu'on appelle du *Trust on First
+Use* ou *TOFU*.
+
+Le navigateur va alors mettre ces informations dans un cache et vérifiera que
+les certificats correspondent bien lors des prochaines visites.
+
+*HPKP* est disponible dans Firefox depuis Janvier 2015 et dans Chrome
+depuis Octobre 2015.
+
+### Certificate transparency: des journaux auditables
+
+Une autre approche est celle proposée par *certificate transparency*:
+
+> Certificate Transparency aims to remedy these certificate-based threats by
+> making the issuance and existence of SSL certificates open to scrutiny by
+> domain owners, CAs, and domain users.
+>
+> -- [Certificate Transparency](https://www.certificate-transparency.org/what-is-ct)
+
+Autrement dit, avec ce système les *CA* doivent rendre public le fait qu'ils
+aient signé de nouveaux certificats intermédiaires. La signature est ajoutée à
+un journal sur lequel il n'est possible que d'écrire.
+
+Les navigateurs vont alors vérifier que les certificats utilisés sont bien des
+certificats qui ont été ajoutés au journal.
+
+Ici, toute l'intelligence est dans la vérification de ces journaux, qui
+permettent donc de valider/invalider des certificats racines ou intermédiaires.
+
+Il me semble donc qu'il serait possible d'ajouter un certificat frauduleux le
+temps d'une attaque (et celui ci serait détecté et supprimé ensuite).
+
+*Certificate-Transparency* n'est donc pas une solution contre une écoute
+globale mise en place par les gouvernements par exemple.
+
+Si vous lisez bien l'anglais, je vous invite à aller lire
+[cette description du problème et de la solution](http://security.stackexchange.com/a/52838)
+que je trouve très bien écrite.
+
+### DANE + DNSSEC
+
+> The DANE working group has developed a framework for securely
+retrieving keying information from the DNS [RFC6698]. This
+framework allows secure storing and looking up server public key
+information in the DNS. This provides a binding between a domain
+name providing a particular service and the key that can be used
+to establish encrypted connection to that service.
+>
+> -- [Dane WG](https://datatracker.ietf.org/wg/dane/charter/)
+
+Une autre solution est appelée "DANE" et repose par dessus le protocole
+*DNSSEC*.
+
+Je connais assez mal *DNSSEC* donc j'ai passé un peu de temps à lire des
+documents. L'impression finale que ça me laisse est que le problème est
+exactement le même que pour SSL: un certain nombre de personnes détiennent les
+clés et toute la sécurité repose sur cette confiance. Or il est possible que
+ces clés soient détenues par des personnes non dignes de confiance.
+
+> Secure DNS (DNSSEC) uses cryptographic digital signatures signed with a
+> trusted public key certificate to determine the authenticity of data.
+> -- https://en.wikipedia.org/wiki/DNS_spoofing
+
+Et aussi:
+
+> It is widely believed[1] that securing the DNS is critically important for
+securing the Internet as a whole, but deployment of DNSSEC specifically has
+been hampered (As of 22 January 2010) by several difficulties:
+>
+> - The need to design a backward-compatible standard that can scale to the
+>   size of the Internet
+> - Prevention of "zone enumeration" (see below) where desired
+> - Deployment of DNSSEC implementations across a wide variety of DNS servers
+>   and resolvers (clients)
+> - Disagreement among implementers over who should own the top-level domain
+>   root keys Overcoming the perceived complexity of DNSSEC and DNSSEC
+>   deployment
+
+## Solutions basées sur la blockchain
+
+Une dernière piste semble être l'utilisation de la *blockchain* pour distribuer
+des clés par site.
+
+La solution *DNSChain* me paraissait tout d'abord un bon point de départ mais
+la lecture de [quelques critiques](https://www.indolering.com/okturtles-dnschain-unblock-us)
+et interventions du développeur du projet m'ont fait changer d'avis.
+
+Reste encore la piste de *Namecoin Control* que je n'ai pas encore creusée.
+Peut-être pour un prochain billet. Toute piste de réflexion est bien sur la
+bienvenue sur ces sujets!
diff --git a/content/thoughts/2016.05.sudweb.md b/content/thoughts/2016.05.sudweb.md
new file mode 100644
index 0000000..48b0ea5
--- /dev/null
+++ b/content/thoughts/2016.05.sudweb.md
@@ -0,0 +1,43 @@
+Title: Cloisonnement des activités ?
+Headline: En revenant de SudWeb
+Date: 2016-05-29
+
+Je vous écris depuis un train, en rentrant de Bordeaux où j'ai passé quelques
+jours à l'occasion de [SudWeb](http://sudweb.fr/). Si vous ne connaissez pas
+cette conférence, il s'agit d'un moment avec des gens chouettes qui se posent
+des questions sur leur metier, comment le vivre et comment continuer à en faire
+un plaisir. Oh, et des fois on parle un peu de technique aussi.
+
+# Alors, brasserie ou code ?
+
+Ces quelques jours ont été fort inspirants. Alors que je suis en train de
+changer de métier (vers celui de brasseur) c'était un moyen de me rendre compte
+que bien que je ne souhaite plus faire du Web mon métier *la, tout de suite,
+maintenant*, je reste un passionné par la chose.
+
+En partant de Rennes, je ne savais pas trop quoi penser de cette situation.
+Prendre un week-end pour échanger avec les gens sur quelque chose dont je
+m'éloigne ? C'est pas une perte de temps ?
+
+Si je passe du temps à écrire des bouts de code, des logiciels, à reflechir
+à comment solutionner certains problemes, ce n'est pas parce que je suis payé
+pour le faire, mais bel et bien parce que je me sens bien lorsque je le fais,
+parce que j'y trouve un équilibre et une utilité.
+
+Alors que je ne trouvais plus cet équilibre dans mon travail, j'ai choisi d'en
+changer, mais il n'empèche que je continue à avoir des rèves d'un
+monde meilleur, dans lequel l'informatique a sa place. Juste à voir les
+discussions (ux, sécurité informatique, décentralisation, architecture
+logicielle) que j'ai pu avoir ce weekend, il n'y a pas l'ombre d'un doute !
+
+Jusqu'ici je me suis dit que je devais choisir. J'ai pensé naivement
+que je ne pouvais pas être *et* un brasseur *et* un developpeur, mais la
+réalité c'est que c'est exactement ce que je suis: les deux.
+
+Je ne suis pas pour autant dupe sur le temps necessaire à lancer une activité
+brassicole, il va falloir fournir de l'énergie et avancer sur le projet, mais
+il n'empèche que même si je décide de faire de la bière mon metier, mes
+passions pour le reste sont bien vivantes.
+
+Bref, merci sudweb pour m'avoir accompagné dans ces reflexions, à l'année
+prochaine, je ramène des futs ?