mirror of
https://github.com/almet/notmyidea.git
synced 2025-04-28 19:42:37 +02:00
809 lines
No EOL
62 KiB
XML
809 lines
No EOL
62 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<feed xmlns="http://www.w3.org/2005/Atom"><title>Carnets Web - crypto</title><link href="https://blog.notmyidea.org/" rel="alternate"></link><link href="https://blog.notmyidea.org/feeds/crypto.atom.xml" rel="self"></link><id>https://blog.notmyidea.org/</id><updated>2016-03-25T00:00:00+01:00</updated><entry><title>Avez vous confiance en SSL?</title><link href="https://blog.notmyidea.org/avez-vous-confiance-en-ssl.html" rel="alternate"></link><published>2016-03-25T00:00:00+01:00</published><updated>2016-03-25T00:00:00+01:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2016-03-25:/avez-vous-confiance-en-ssl.html</id><summary type="html"><p>Dans le cadre <a href="http://autodefense-numerique.readthedocs.org/en/latest/">des ateliers d'autodéfense numérique</a>,
|
||
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
|
||
<strong>absolument</strong> pas suffisant.</p>
|
||
<p>Allez hop …</p></summary><content type="html"><p>Dans le cadre <a href="http://autodefense-numerique.readthedocs.org/en/latest/">des ateliers d'autodéfense numérique</a>,
|
||
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
|
||
<strong>absolument</strong> pas suffisant.</p>
|
||
<p>Allez hop, c'est parti pour:</p>
|
||
<ul>
|
||
<li>un tour d'horizon du fonctionnement de SSl</li>
|
||
<li>quelques moyens contourner cette "protection" en faisant une attaque en pratique</li>
|
||
<li>un tour des solutions existantes actuellement et de pourquoi je ne les trouve
|
||
pas vraiment satisfaisantes.</li>
|
||
</ul>
|
||
<h2>Comment fonctionne SSL?</h2>
|
||
<p>Pour expliquer les problèmes de SSL, j'ai d'abord besoin d'expliquer comment
|
||
tout ça fonctionne.</p>
|
||
<p>SSL repose sur l'utilisation de certificats, qui sont générés par des autorités
|
||
de certification (<em>Certificate Authority</em> que je nomme <em>CA</em> dans la suite de
|
||
l'article).</p>
|
||
<p>Les certificats SSL permettent deux choses:</p>
|
||
<ul>
|
||
<li>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.</li>
|
||
<li>De garantir que le site sur lequel vous vous connectez est bien celui que
|
||
vous imaginez.</li>
|
||
</ul>
|
||
<p>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 <em>CA</em> en qui il a confiance.</p>
|
||
<p>Imaginons maintenant qu'une des <em>CA</em> 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 ?</p>
|
||
<p>N'importe quel <em>CA</em> 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
|
||
<em>CA</em>.</p>
|
||
<p>Tout cela ne poserait pas de soucis si les <em>CA</em> étaient gérés de manière fiable,
|
||
mais il s'agit d'un travail compliqué, et certains <em>CA</em> ont par le passé montré
|
||
des faiblesses.</p>
|
||
<p>Par exemple, <a href="https://en.wikipedia.org/wiki/DigiNotar">DigiNotar</a> (un <em>CA</em> 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.</p>
|
||
<p>Vous pouvez retrouver une liste des risques et menaces autour des <em>CA</em> <a href="http://wiki.cacert.org/Risk/History">sur le
|
||
wiki de CACert</a>.</p>
|
||
<h2>Attaque de l'homme du milieu avec SSL</h2>
|
||
<p>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.</p>
|
||
<p>En l'espace de quelques minutes, il est possible de faire une <em>attaque de
|
||
l'homme du milieu</em> en utilisant par exemple un outil nommé <a href="http://docs.mitmproxy.org/en/stable">mitm-proxy</a>.</p>
|
||
<p>Pour déchiffrer l'ensemble du trafic SSL, j'ai simplement eu à lancer quelques
|
||
commandes et avoir un <em>CA</em> 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).</p>
|
||
<p>Je les colle ici si ça vous intéresse:</p>
|
||
<div class="highlight"><pre><span></span>$ sudo aptitude install mitmproxy
|
||
$ mitm-proxy -T --host
|
||
</pre></div>
|
||
|
||
|
||
<p>Il faut faire croire à votre victime que vous êtes la passerelle vers
|
||
l'extérieur et à la passerelle que vous êtes la victime:</p>
|
||
<div class="highlight"><pre><span></span>arpspoof -i wlan0 -t victime gateway
|
||
arpspoof -i wlan0 -t gateway victime
|
||
</pre></div>
|
||
|
||
|
||
<p>Puis dire à notre fausse passerelle de rediriger le trafic des ports 80 et 443
|
||
vers notre proxy:</p>
|
||
<div class="highlight"><pre><span></span>sudo sysctl -w net.ipv4.ip_forward<span class="o">=</span><span class="m">1</span>
|
||
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport <span class="m">443</span> -j REDIRECT --to-port <span class="m">4443</span>
|
||
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport <span class="m">80</span> -j REDIRECT --to-port <span class="m">4443</span>
|
||
</pre></div>
|
||
|
||
|
||
<p>Et paf, <strong>on voit tout ce qui passe entre la machine et le serveur SSL</strong>. On peut
|
||
d'ailleurs même imaginer faire tourner ces quelques commandes sur un
|
||
raspberry pi, pour aller encore plus vite…</p>
|
||
<h3>Key-pinning dans les navigateurs</h3>
|
||
<p>Actuellement, n'importe quel <em>CA</em> 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.</p>
|
||
<p>Cette approche a le mérite de fonctionner très bien <a href="https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h?from=StaticHPKPins.h">pour un petit nombre de
|
||
sites critiques (Google, Facebook, etc)</a>.</p>
|
||
<h3>HTTP Public Key Pinning (HPKP)</h3>
|
||
<p><a href="https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning"><em>HTTP Public Key Pinning</em></a>
|
||
est également une solution de <em>pinning</em> qui permet d'établir une confiance lors
|
||
de la première connexion avec le site. C'est ce qu'on appelle du <em>Trust on First
|
||
Use</em> ou <em>TOFU</em>.</p>
|
||
<p>Le navigateur va alors mettre ces informations dans un cache et vérifiera que
|
||
les certificats correspondent bien lors des prochaines visites.</p>
|
||
<p><em>HPKP</em> est disponible dans Firefox depuis Janvier 2015 et dans Chrome
|
||
depuis Octobre 2015.</p>
|
||
<h3>Certificate transparency: des journaux auditables</h3>
|
||
<p>Une autre approche est celle proposée par <em>certificate transparency</em>:</p>
|
||
<blockquote>
|
||
<p>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.</p>
|
||
<p>-- <a href="https://www.certificate-transparency.org/what-is-ct">Certificate Transparency</a></p>
|
||
</blockquote>
|
||
<p>Autrement dit, avec ce système les <em>CA</em> 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.</p>
|
||
<p>Les navigateurs vont alors vérifier que les certificats utilisés sont bien des
|
||
certificats qui ont été ajoutés au journal.</p>
|
||
<p>Ici, toute l'intelligence est dans la vérification de ces journaux, qui
|
||
permettent donc de valider/invalider des certificats racines ou intermédiaires.</p>
|
||
<p>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).</p>
|
||
<p><em>Certificate-Transparency</em> n'est donc pas une solution contre une écoute
|
||
globale mise en place par les gouvernements par exemple.</p>
|
||
<p>Si vous lisez bien l'anglais, je vous invite à aller lire
|
||
<a href="http://security.stackexchange.com/a/52838">cette description du problème et de la solution</a>
|
||
que je trouve très bien écrite.</p>
|
||
<h3>DANE + DNSSEC</h3>
|
||
<blockquote>
|
||
<p>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.</p>
|
||
<p>-- <a href="https://datatracker.ietf.org/wg/dane/charter/">Dane WG</a></p>
|
||
</blockquote>
|
||
<p>Une autre solution est appelée "DANE" et repose par dessus le protocole
|
||
<em>DNSSEC</em>.</p>
|
||
<p>Je connais assez mal <em>DNSSEC</em> 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.</p>
|
||
<blockquote>
|
||
<p>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</p>
|
||
</blockquote>
|
||
<p>Et aussi:</p>
|
||
<blockquote>
|
||
<p>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:</p>
|
||
<ul>
|
||
<li>The need to design a backward-compatible standard that can scale to the
|
||
size of the Internet</li>
|
||
<li>Prevention of "zone enumeration" (see below) where desired</li>
|
||
<li>Deployment of DNSSEC implementations across a wide variety of DNS servers
|
||
and resolvers (clients)</li>
|
||
<li>Disagreement among implementers over who should own the top-level domain
|
||
root keys Overcoming the perceived complexity of DNSSEC and DNSSEC
|
||
deployment</li>
|
||
</ul>
|
||
</blockquote>
|
||
<h2>Solutions basées sur la blockchain</h2>
|
||
<p>Une dernière piste semble être l'utilisation de la <em>blockchain</em> pour distribuer
|
||
des clés par site.</p>
|
||
<p>La solution <em>DNSChain</em> me paraissait tout d'abord un bon point de départ mais
|
||
la lecture de <a href="https://www.indolering.com/okturtles-dnschain-unblock-us">quelques critiques</a>
|
||
et interventions du développeur du projet m'ont fait changer d'avis.</p>
|
||
<p>Reste encore la piste de <em>Namecoin Control</em> 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!</p></content></entry><entry><title>Retours sur un atelier ZeroNet</title><link href="https://blog.notmyidea.org/retours-sur-un-atelier-zeronet.html" rel="alternate"></link><published>2016-03-17T00:00:00+01:00</published><updated>2016-03-17T00:00:00+01:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2016-03-17:/retours-sur-un-atelier-zeronet.html</id><summary type="html"><p>Mardi dernier se tenait <a href="http://biblio.insa-rennes.fr/crypto">une <em>cryptoparty</em></a>
|
||
dans les locaux de l'INSA de Rennes.</p>
|
||
<p>L'évènement s'étant rempli au delà de toutes les espérances, on m'a proposé de
|
||
venir y tenir un atelier, que j'ai proposé sur <a href="https://zeronet.io">ZeroNet</a>, un
|
||
petit projet fort sympathique qui pourrait devenir une nouvelle manière de
|
||
distribuer le …</p></summary><content type="html"><p>Mardi dernier se tenait <a href="http://biblio.insa-rennes.fr/crypto">une <em>cryptoparty</em></a>
|
||
dans les locaux de l'INSA de Rennes.</p>
|
||
<p>L'évènement s'étant rempli au delà de toutes les espérances, on m'a proposé de
|
||
venir y tenir un atelier, que j'ai proposé sur <a href="https://zeronet.io">ZeroNet</a>, un
|
||
petit projet fort sympathique qui pourrait devenir une nouvelle manière de
|
||
distribuer le Web, permettant notamment d'éviter la censure.</p>
|
||
<p>Avant toute autre chose, merci énormément à l'équipe de la bibliothèque de
|
||
l'INSA pour l'organisation de cet évènement qui à une réelle portée politique.</p>
|
||
<h2>Un peu d'histoire</h2>
|
||
<p>Il me semble que Tim Bernes Lee (l'inventeur du Web) avait prévu le Web comme un
|
||
protocole décentralisé. Chacun hébergerait ses données et les servirait aux
|
||
autres, qui pourraient alors y accéder.</p>
|
||
<p>Avec ce fonctionnement, impossible alors d'accéder à des sites si leur auteur
|
||
n'est pas en ligne. Qu'à cela ne tienne, on s'est mis à avoir des machines qui
|
||
restent connectées au réseau 24 heures par jour. Et puis une machine ne
|
||
suffisant plus, on a eu des fermes de machines dans des <em>data centers</em> etc afin
|
||
de supporter les milliers d'utilisateurs des sites.</p>
|
||
<h2>Un Web décentralisé</h2>
|
||
<p>ZeroNet permet (entre autres) de répondre à ce problème en proposant une manière
|
||
alternative de <strong>distribuer le Web</strong>, en pair à pair. Lors d'une visite d'un
|
||
site:</p>
|
||
<ol>
|
||
<li>Vous contactez un <em>tracker</em> BitTorrent pour connaitre la liste des autres
|
||
visiteurs du site (les <em>pairs</em>).</li>
|
||
<li>Vous demandez aux <em>pairs</em> de vous donner les fichiers du site.</li>
|
||
<li>Vous validez que les fichiers servis sont bien les bons (en vérifiant la
|
||
signature attachée).</li>
|
||
</ol>
|
||
<p>N'importe quel visiteur devient alors un <em>pair</em>, qui sert le site aux autres
|
||
visiteurs.</p>
|
||
<p>Parmi les nombreux avantages de cette approche, je note particulièrement que:</p>
|
||
<ul>
|
||
<li>Il est très difficile de censurer un site — Il est sur l'ensemble des machines
|
||
des visiteurs.</li>
|
||
<li>Les attaques par <em>fingerprinting</em> sont impossibles: le navigateur Web se
|
||
connecte à un serveur <em>proxy</em> local.</li>
|
||
<li>Vous détenez directement vos données et (par design) ne les donnez pas à des
|
||
silos (Facebook, Google, etc.)</li>
|
||
</ul>
|
||
<p>Si vous êtes interessés par une démonstration rapide, j'ai enregistré une vidéo
|
||
de 10 minutes où je parle en anglais avec une voix très grave.</p>
|
||
<video controls="" src="http://alexis.notmyidea.org/zeronet.webm" width=800></video>
|
||
|
||
<h2>Atelier</h2>
|
||
<p>Pour l'atelier, j'ai choisi de faire une présentation rapide du projet (<a href="{filename}/static/zeronet-presentation-fr.pdf">j'ai
|
||
traduit les slides</a> anglais
|
||
pour l'occasion — <a href="https://docs.google.com/presentation/d/158C_-V1ueNaaKHMBMBgGOVhunb9xrXzB3hC_g1N53c0/edit?usp=sharing">accès aux sources</a>)
|
||
avant d'installer ZeroNet sur les machines et de l'utiliser pour publier un
|
||
site.</p>
|
||
<h3>Partager sur le réseau local</h3>
|
||
<p>Nous avons eu des soucis à cause du réseau (un peu congestionné) sur lequel
|
||
les ports utilisés pour la discussion entre <em>pairs</em> étaient fermés. Il est bien
|
||
sur possible de faire tourner le tout de manière indépendante du reste du réseau,
|
||
mais je n'avais pas prévu le coup.</p>
|
||
<p>Voici donc comment faire pour contourner le souci:</p>
|
||
<ol>
|
||
<li>Installer et lancer un <em>tracker</em> BitTorrent (De manière surprenante,
|
||
<a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685575">rien n'est packagé pour debian pour l'instant</a>)
|
||
J'ai choisi d'installer <a href="http://erdgeist.org/arts/software/opentracker/#build-instructions">OpenTracker</a></li>
|
||
<li>Ensuite lancer ZeroNet avec des options spécifiques.</li>
|
||
</ol>
|
||
<div class="highlight"><pre><span></span>$ python zeronet.py --trackers udp://localhost:6969 --ip_external <span class="m">192</span>.168.43.207
|
||
$ python zeronet.py --trackers udp://192.168.43.207:6969 --ip_external <span class="m">192</span>.168.43.172
|
||
</pre></div>
|
||
|
||
|
||
<p>Il est nécessaire de spécifier l'adresse IP externe que chaque nœud expose pour
|
||
éviter qu'elle n'essaye d'aller la trouver par elle même: nous voulons l'adresse
|
||
du réseau local, et non pas l'adresse internet.</p>
|
||
<p>La prochaine fois je tenterais de venir avec un HotSpot Wifi et un tracker
|
||
BitTorrent dans la poche!</p>
|
||
<h2>Questions / Réponses</h2>
|
||
<p>Il y avait quelques questions intéressantes auxquelles je n'ai pas toujours su
|
||
répondre sur le moment. Après quelques recherches, je rajoute des détails ici.</p>
|
||
<h3>Torrent + Tor = brèche de sécu ?</h3>
|
||
<p>Il me semblait avoir entendu parler de problèmes de <em>dé-anonymisation</em>
|
||
<a href="https://hal.inria.fr/file/index/docid/471556/filename/TorBT.pdf">lors de l'utilisation de BitTorrent par dessus Tor</a>.</p>
|
||
<blockquote>
|
||
<p>Dans certains cas, certains clients torrents (uTorrent, BitSpirit, etc)
|
||
écrivent directement votre adresse IP dans l'information qui est envoyée
|
||
au tracker et/ou aux autres pairs.
|
||
— https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea</p>
|
||
</blockquote>
|
||
<p><a href="https://github.com/HelloZeroNet/ZeroNet/issues/274">Ce n'est pas le cas de ZeroNet</a>, ce qui évacue le souci.</p>
|
||
<h3>ZeroMail, c'est lent non ?</h3>
|
||
<p>Une des applications de démo, <em>ZeroMail</em>, propose un mécanisme qui permet de
|
||
s'envoyer des messages chiffrés sur un réseau pair à pair. L'approche choisie
|
||
est de chiffrer les messages avec la clé du destinataire et de le mettre dans
|
||
un <em>pot commun</em>. Tout le monde essaye de déchiffrer tous les messages, mais ne
|
||
peut déchiffrer que les siens.</p>
|
||
<p>Cela permet de ne <strong>pas</strong> fuiter de méta-données, <a href="{filename}../crypto/2015.05.pgp-problemes.rst">à l'inverse de PGP</a>.</p>
|
||
<p>Je n'ai en fait pas de réponse claire à donner à cette question: l'auteur de
|
||
ZeroNet me disait que 10MB (la limite de taille d'un site, par défaut)
|
||
correspondait à beaucoup de place pour stocker des messages, et qu'il était
|
||
possible de supprimer les anciens messages une fois qu'ils sont lus par exemple.</p>
|
||
<p>Une autre solution à laquelle je pensait était de créer un <em>ZeroSite</em> pour
|
||
chaque récipient, mais on connait à ce moment là le nombre de messages qu'un
|
||
utilisateur peut recevoir.</p>
|
||
<p>Je vois plusieurs problèmes avec le design actuel de ZeroMail (il me semble
|
||
assez facile d'y faire un déni de service par exemple). A creuser.</p>
|
||
<h3>Comment héberger des très gros sites ?</h3>
|
||
<p>Par exemple, comment faire pour héberger Wikipedia ?</p>
|
||
<p>Il semble que la meilleure manière de faire serait de séparer Wikipedia en
|
||
un tas de petites ressources (par catégorie par ex.). Les gros médias pourraient
|
||
être considérés optionnels (et donc téléchargés uniquement à la demande)</p>
|
||
<h3>Est-ce qu'on à vraiment besoin d'un tracker ?</h3>
|
||
<p>Le support d'une DHT <a href="https://github.com/HelloZeroNet/ZeroNet/issues/57">est souhaité</a>,
|
||
mais pour l'instant pas encore implémenté. L'utilisation de la DHT BitTorrent
|
||
n'est pas une option puisque <a href="https://github.com/HelloZeroNet/ZeroNet/issues/57">Tor ne supporte pas UDP</a>.</p></content></entry><entry><title>Let's Encrypt + HAProxy</title><link href="https://blog.notmyidea.org/lets-encrypt-haproxy.html" rel="alternate"></link><published>2016-02-11T00:00:00+01:00</published><updated>2016-02-11T00:00:00+01:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2016-02-11:/lets-encrypt-haproxy.html</id><summary type="html"><blockquote class="epigraph">
|
||
<p>It’s time for the Web to take a big step forward in terms of security and
|
||
privacy. We want to see HTTPS become the default. Let’s Encrypt was built
|
||
to enable that by making it as easy as possible to get and manage
|
||
certificates.</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="https://letsencrypt.org/">Let's Encrypt</a></p>
|
||
</blockquote>
|
||
<p>Depuis début …</p></summary><content type="html"><blockquote class="epigraph">
|
||
<p>It’s time for the Web to take a big step forward in terms of security and
|
||
privacy. We want to see HTTPS become the default. Let’s Encrypt was built
|
||
to enable that by making it as easy as possible to get and manage
|
||
certificates.</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="https://letsencrypt.org/">Let's Encrypt</a></p>
|
||
</blockquote>
|
||
<p>Depuis début Décembre, la nouvelle <em>autorité de certification</em> Let's Encrypt
|
||
est passée en version <em>Beta</em>. Les certificats SSL sont un moyen de 1. chiffrer la
|
||
communication entre votre navigateur et le serveur et 2. un moyen d'être sur
|
||
que le site Web auquel vous accédez est celui auquel vous pensez vous connecter
|
||
(pour éviter des <a class="reference external" href="https://fr.wikipedia.org/wiki/Attaque_de_l'homme_du_milieu">attaques de l'homme du milieu</a>).</p>
|
||
<p>Jusqu'à maintenant, il était nécessaire de payer une entreprise pour faire en
|
||
sorte d'avoir des certificats qui évitent d'avoir ce genre d'erreurs dans vos
|
||
navigateurs:</p>
|
||
<img alt="Message de firefox lorsque une connexion n'est pas sécurisée." src="{filename}/static/unsecure-connection.png" />
|
||
<p>Maintenant, grâce à Let's Encrypt il est possible d'avoir des certificats SSL
|
||
<strong>gratuits</strong>, ce qui représente un grand pas en avant pour la sécurité de nos
|
||
communications.</p>
|
||
<p>Je viens de mettre en place un procédé (assez simple) qui permet de configurer
|
||
votre serveur pour générer des certificats SSL valides avec Let's Encrypt et
|
||
le répartiteur de charge <a class="reference external" href="http://www.haproxy.org/">HAProxy</a>.</p>
|
||
<p>Je me suis basé pour cet article sur d'<a class="reference external" href="https://blog.infomee.fr/p/letsencrypt-haproxy">autres</a> <a class="reference external" href="http://blog.victor-hery.com/article22/utiliser-let-s-encrypt-avec-haproxy">articles</a>, dont je
|
||
vous recommande la lecture pour un complément d'information.</p>
|
||
<div class="section" id="validation-des-domaines-par-let-s-encrypt">
|
||
<h2>Validation des domaines par Let's Encrypt</h2>
|
||
<p>Je vous passe les détails d'installation du client de Let's Encrypt, qui sont
|
||
<a class="reference external" href="https://github.com/letsencrypt/letsencrypt#installation">très bien expliqués sur leur documentation</a>.</p>
|
||
<p>Une fois installé, vous allez taper une commande qui va ressembler à:</p>
|
||
<pre class="literal-block">
|
||
letsencrypt-auto certonly --renew-by-default
|
||
--webroot -w /home/www/letsencrypt-requests/ \
|
||
-d hurl.kinto-storage.org \
|
||
-d forums.kinto-storage.org
|
||
</pre>
|
||
<p>Le <em>webroot</em> est l'endroit ou les preuves de détention du domaine vont être
|
||
déposées.</p>
|
||
<p>Lorsque les serveurs de Let's Encrypt vont vouloir vérifier que vous êtes bien
|
||
à l'origine des demandes de certificats, ils vont envoyer une requête HTTP sur
|
||
<tt class="docutils literal"><span class="pre">http://domaine.org/.well-known/acme-challenge</span></tt>, ou il voudra trouver des
|
||
informations qu'il aura généré via la commande <tt class="docutils literal"><span class="pre">letsencrypt-auto</span></tt>.</p>
|
||
<p>J'ai choisi de faire une règle dans haproxy pour diriger toutes les requêtes
|
||
avec le chemin <tt class="docutils literal"><span class="pre">.well-known/acme-challenge</span></tt> vers un <em>backend</em> nginx qui sert
|
||
des fichiers statiques (ceux contenus dans
|
||
<tt class="docutils literal"><span class="pre">/home/www/letsencrypt-requests/</span></tt>).</p>
|
||
<p>Voici la section de la configuration de HAProxy (et <a class="reference external" href="https://github.com/almet/infra/blob/master/haproxy/haproxy.cfg#L63-L72">la configuration
|
||
complete</a>
|
||
si ça peut être utile):</p>
|
||
<pre class="literal-block">
|
||
frontend http
|
||
bind 0.0.0.0:80
|
||
mode http
|
||
default_backend nginx_server
|
||
|
||
acl letsencrypt_check path_beg /.well-known/acme-challenge
|
||
use_backend letsencrypt_backend if letsencrypt_check
|
||
|
||
redirect scheme https code 301 if !{ ssl_fc } !letsencrypt_check
|
||
|
||
backend letsencrypt_backend
|
||
http-request set-header Host letsencrypt.requests
|
||
dispatch 127.0.0.1:8000
|
||
</pre>
|
||
<p>Et celle de NGINX:</p>
|
||
<pre class="literal-block">
|
||
server {
|
||
listen 8000;
|
||
server_name letsencrypt.requests;
|
||
root /home/www/letsencrypt-requests;
|
||
}
|
||
</pre>
|
||
</div>
|
||
<div class="section" id="installation-des-certificats-dans-haproxy">
|
||
<h2>Installation des certificats dans HAProxy</h2>
|
||
<p>Vos certificats SSL devraient être générés dans <tt class="docutils literal">/etc/letsencrypt/live</tt>, mais
|
||
ils ne sont pas au format attendu par haproxy. Rien de grave, la commande
|
||
suivant convertit l'ensemble des certificats en une version compatible avec
|
||
HAProxy:</p>
|
||
<pre class="literal-block">
|
||
cat /etc/letsencrypt/live/domaine.org/privkey.pem /etc/letsencrypt/live/domaine.org/fullchain.pem &gt; /etc/ssl/letsencrypt/domaine.org.pem
|
||
</pre>
|
||
<p>Et ensuite dans la configuration de haproxy, pour le (nouveau) <em>frontend</em> https:</p>
|
||
<pre class="literal-block">
|
||
bind 0.0.0.0:443 ssl no-sslv3 crt /etc/ssl/letsencrypt
|
||
</pre>
|
||
<p>Faites bien attention à avoir un <em>frontend</em> <cite>https</cite> pour tous vos sites en HTTPS.
|
||
<a class="reference external" href="https://github.com/almet/infra/blob/master/haproxy/haproxy.cfg#L38-L60">Pour moi cela ressemble à ça</a>.</p>
|
||
<p>Une fois tout ceci fait, redémarrez votre service haproxy et zou !</p>
|
||
</div>
|
||
<div class="section" id="automatisation">
|
||
<h2>Automatisation</h2>
|
||
<p>Pour automatiser un peu tout ça, j'ai choisi de faire ça comme suit:</p>
|
||
<ul class="simple">
|
||
<li>Un fichier domaine dans <tt class="docutils literal">letsencrypt/domains/domain.org</tt> qui contient le script <tt class="docutils literal">letsencrypt</tt>.</li>
|
||
<li>Un fichier d'installation de certificats dans
|
||
<tt class="docutils literal"><span class="pre">letsencrypt/install-certs.sh</span></tt> qui s'occupe d'installer les certificats
|
||
déjà générés.</li>
|
||
</ul>
|
||
<p>Et voila ! <a class="reference external" href="https://github.com/almet/infra/">Le tout est dans un dépot github</a>, si jamais ça peut vous servir, tant mieux !</p>
|
||
</div>
|
||
</content></entry><entry><title>Ateliers d'autodéfense numérique</title><link href="https://blog.notmyidea.org/ateliers-dautodefense-numerique.html" rel="alternate"></link><published>2016-01-14T00:00:00+01:00</published><updated>2016-01-14T00:00:00+01:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2016-01-14:/ateliers-dautodefense-numerique.html</id><summary type="html"><p>Il y a huit mois, je me rendais compte de l'importance du choix des outils pour
|
||
faire face à la surveillance généralisée, et notamment en rapport au
|
||
chiffrement des données. Une de mes envies de l'époque était l'animation
|
||
d'ateliers.</p>
|
||
<blockquote class="epigraph">
|
||
<p>Je compte donc:</p>
|
||
<ul class="simple">
|
||
<li>Organiser des ateliers de sensibilisation aux outils de …</li></ul></blockquote></summary><content type="html"><p>Il y a huit mois, je me rendais compte de l'importance du choix des outils pour
|
||
faire face à la surveillance généralisée, et notamment en rapport au
|
||
chiffrement des données. Une de mes envies de l'époque était l'animation
|
||
d'ateliers.</p>
|
||
<blockquote class="epigraph">
|
||
<p>Je compte donc:</p>
|
||
<ul class="simple">
|
||
<li>Organiser des ateliers de sensibilisation aux outils de communication,
|
||
envers mes proches;</li>
|
||
<li>Utiliser la communication chiffrée le plus souvent possible, au moins
|
||
pour rendre le déchiffrement des messages plus longue, &quot;noyer le
|
||
poisson&quot;.</li>
|
||
</ul>
|
||
<p class="attribution">&mdash;<a class="reference external" href="http://blog.notmyidea.org/chiffrement.html">Chiffrement</a></p>
|
||
</blockquote>
|
||
<p>J'ai mis un peu de temps à mettre le pied à l'étrier, mais je ressors
|
||
finalement du premier atelier que j'ai co-animé avec geb, auprès d'un public de
|
||
journalistes.</p>
|
||
<p>Pour cette première édition l'idée était à la fois d'aller à la rencontre d'un
|
||
public que je connais mal, de leur donner des outils pour solutionner les
|
||
problèmes auxquels ils font parfois face, et de me faire une idée de ce que
|
||
pouvait être un atelier sur l'autodéfense numérique.</p>
|
||
<p>L'objectif pour ce premier atelier était de:</p>
|
||
<ol class="arabic simple">
|
||
<li>Échanger autour des besoins et <strong>faire ressortir des histoires</strong> ou le manque
|
||
d'outillage / connaissances à posé problème, dans des situations concrètes;</li>
|
||
<li>Se rendre compte des &quot;conduites à risque&quot;, <strong>faire peur</strong> aux personnes formées
|
||
pour qu'elles se rendent compte de l'état actuel des choses;</li>
|
||
<li><strong>Proposer des solutions concrètes</strong> aux problèmes soulevés, ainsi que le
|
||
minimum de connaissance théorique pour les appréhender.</li>
|
||
</ol>
|
||
<div class="section" id="faire-ressortir-les-problemes">
|
||
<h2>1. Faire ressortir les problèmes</h2>
|
||
<p>Afin de faire ressortir les problèmes, nous avons choisi de constituer des
|
||
petits groupes de discussion, afin de faire des &quot;Groupes d'Interview Mutuels&quot;,
|
||
ou &quot;GIM&quot;:</p>
|
||
<blockquote class="epigraph">
|
||
<p>l’animateur invite les participants à se regrouper par trois, avec des
|
||
personnes qu’on connaît moins puis invite chacun à livrer une expérience vécue
|
||
en lien avec le thème de la réunion et les deux autres à poser des questions
|
||
leur permettant de bien saisir ce qui a été vécu.</p>
|
||
<p class="attribution">&mdash;«<a class="reference external" href="http://www.scoplepave.org/pour-s-ecouter">Pour s'écouter</a>», SCOP Le Pavé.</p>
|
||
</blockquote>
|
||
<p>De ces <em>GIMs</em> nous avons pu ressortir quelques histoires, gravitant autour de:</p>
|
||
<ul class="simple">
|
||
<li><strong>La protection des sources (d'information)</strong>: Comment faire pour aider
|
||
quelqu'un à faire &quot;fuiter&quot; des données depuis l'intérieur d'une entreprise ?</li>
|
||
<li><strong>Le chiffrement de ses données</strong>: Comment éviter de faire &quot;fuiter&quot; des données
|
||
importantes lors d'une perquisition de matériel ?</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="faire-peur">
|
||
<h2>2. Faire peur</h2>
|
||
<p>Un des premiers objectifs est de faire peur, afin que tout le monde se rende
|
||
compte à quel point il est facile d'accéder à certaines données. <a class="reference external" href="http://blog.barbayellow.com/">Grégoire</a> m'avait conseillé quelques petites accroches
|
||
qui ont ma foi bien marché:</p>
|
||
<p>J'ai demandé aux présent.e.s de:</p>
|
||
<ul class="simple">
|
||
<li>donner leur mot de passe à voix haute devant les autres: a priori personne ne
|
||
le fera;</li>
|
||
<li>venir se connecter à leur compte email depuis mon ordinateur. J'ai piégé une
|
||
personne, qui est venu pour taper son mot de passe.</li>
|
||
</ul>
|
||
<p>Cela à été un bon moyen de parler de l'importance des traces que l'on peut
|
||
laisser sur un ordinateur, et de la confiance qu'il faut avoir dans le matériel
|
||
que l'on utilise, à fortiori si ce ne sont pas les vôtres.</p>
|
||
<p>Pour continuer à leur faire peur, après une brève explication de ce qu'est SSL
|
||
nous avons montré comment il était facile de scruter le réseau à la recherche
|
||
de mots de passe en clair.</p>
|
||
</div>
|
||
<div class="section" id="proposer-des-solutions-concretes">
|
||
<h2>3. Proposer des solutions concrêtes</h2>
|
||
<p>Une fois que tout le monde avait pleinement pris sonscience des problématiques
|
||
et n'osait plus utiliser son ordinateur ou son téléphone, on à commencé
|
||
à parler de quelques solutions.
|
||
Plusieurs approches étaient possibles ici, nous avons choisi de présenter
|
||
quelques outils qui nous semblaient répondre aux attentes:</p>
|
||
<ul class="simple">
|
||
<li>On a expliqué ce qu'était <a class="reference external" href="https://tails.boum.org">Tails</a>, et comment
|
||
l'utiliser et le dupliquer.</li>
|
||
<li>On a pu faire un tour des outils existants sur Tails, notamment autour de
|
||
l'<em>anonymisation</em> de fichiers et la suppression effective de contenus.</li>
|
||
<li>Certaines personnes ont pu créer une clé tails avec la persistance de
|
||
configurée.</li>
|
||
<li>Nous nous sommes connectés au réseau <a class="reference external" href="https://www.torproject.org">Tor</a> et testé
|
||
que nos adresses IP changeaient bien à la demande.</li>
|
||
<li>Nous avons utilisé <a class="reference external" href="https://crypto.cat">CryptoCat</a> par dessus Tor, afin de
|
||
voir comment avoir une conversation confidentielle dans laquelle il est
|
||
possible d'échanger des fichiers.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="retours">
|
||
<h2>Retours</h2>
|
||
<p>D'une manière générale, pour une formation de trois heures et demi, je suis
|
||
assez content de l'exercice, et de l'ensemble des sujets que nous avons pu
|
||
couvrir. Il y a beaucoup de place pour l'amélioration, notamment en amont (j'avais
|
||
par exemple oublié d'amener avec moi suffisamment de clés USB pour utiliser
|
||
Tails).</p>
|
||
<p>La plupart des retours qu'on a pu avoir jusqu'à maintenant sont positifs, et il
|
||
y a l'envie d'aller plus loin sur l'ensemble de ces sujets.</p>
|
||
</div>
|
||
<div class="section" id="la-suite">
|
||
<h2>La suite</h2>
|
||
<p>Il y a beaucoup de sujets que nous n'avons pas abordés, ou uniquement survolés,
|
||
à cause du manque de temps disponible. Idéalement, il faudrait au moins une
|
||
journée entière pour couvrir quelques sujets plus en détail (on peut imaginer
|
||
avoir une partie théorique le matin et une partie pratique l'après-midi par
|
||
exemple).</p>
|
||
<p>J'ai choisi volontairement de ne pas aborder le chiffrement des messages via
|
||
PGP parce que <a class="reference external" href="https://blog.notmyidea.org/les-problemes-de-pgp.html">je pense que la protection que ce média propose n'est pas
|
||
suffisante</a>, mais je suis en train de
|
||
revenir sur ma décision: il pourrait être utile de présenter l'outil, à minima,
|
||
en insistant sur certaines de ses faiblesses.</p>
|
||
<p>Un compte twitter à été créé recemment autour des crypto-party à Rennes, si
|
||
vous êtes interessés, <a class="reference external" href="https://twitter.com/CryptoPartyRNS">allez jeter un coup d'œil</a>!</p>
|
||
<p>Je n'ai pas trouvé de ressources disponibles par rapport à des plans de
|
||
formation sur le sujet, j'ai donc décidé de publier les nôtres, afin de
|
||
co-construire avec d'autres des plans de formation.</p>
|
||
<p>Ils sont pour l'instant disponibles <a class="reference external" href="http://autodefense-numerique.readthedocs.org/en/latest/">sur Read The Docs</a>. Tous les retours
|
||
sont évidemment les bienvenus !</p>
|
||
</div>
|
||
</content></entry><entry><title>Web distribution signing</title><link href="https://blog.notmyidea.org/web-distribution-signing.html" rel="alternate"></link><published>2015-10-12T00:00:00+02:00</published><updated>2015-10-12T00:00:00+02:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2015-10-12:/web-distribution-signing.html</id><summary type="html"><div class="admonition note">
|
||
<p class="first admonition-title">Note</p>
|
||
<p class="last">I'm not a crypto expert, nor pretend to be one. These are thoughts
|
||
I want to share with the crypto community to actually see if any
|
||
solution exists to solve this particular problem.</p>
|
||
</div>
|
||
<p>One <a class="reference external" href="http://www.tonyarcieri.com/whats-wrong-with-webcrypto">often pointed</a>
|
||
flaw in web-based cryptographic applications is the fact that there is no way …</p></summary><content type="html"><div class="admonition note">
|
||
<p class="first admonition-title">Note</p>
|
||
<p class="last">I'm not a crypto expert, nor pretend to be one. These are thoughts
|
||
I want to share with the crypto community to actually see if any
|
||
solution exists to solve this particular problem.</p>
|
||
</div>
|
||
<p>One <a class="reference external" href="http://www.tonyarcieri.com/whats-wrong-with-webcrypto">often pointed</a>
|
||
flaw in web-based cryptographic applications is the fact that there is no way
|
||
to trust online software distributions. Put differently, you don't actually
|
||
trust the software authors but are rather trusting the software distributors
|
||
and certificate authorities (CAs).</p>
|
||
<p>I've been talking with a few folks in the past months about that and they
|
||
suggested me to publish something to discuss the matter. So here I come!</p>
|
||
<div class="section" id="the-problem-attack-vectors">
|
||
<h2>The problem (Attack vectors)</h2>
|
||
<p>Let's try to describe a few potential attacks:</p>
|
||
<p><em>Application Authors</em> just released a new version of their open source web
|
||
crypto messaging application. An <em>Indie Hoster</em> installs it on their servers so
|
||
a wide audience can actually use it.</p>
|
||
<p>Someone alters the files on <em>Indie Hoster</em> servers, effectively replacing them with
|
||
other <em>altered files</em> with less security properties / a backdoor. This someone could either be
|
||
an <em>Evil Attacker</em> which found its way trough, the <em>Indie Hoster</em> or a CDN
|
||
which delivers the files,</p>
|
||
<p>Trusted <em>Certificate Authorities</em> (&quot;governments&quot; or &quot;hacking team&quot;) can also
|
||
trick the User Agents (i.e. Firefox) into thinking they're talking to <em>Indie
|
||
Hoster</em> even though they're actually talking to a different server.</p>
|
||
<p><strong>Altered files</strong> are then being served to the User Agents, and <em>Evil Attacker</em>
|
||
now has a way to actually attack the end users.</p>
|
||
</div>
|
||
<div class="section" id="problem-mitigation">
|
||
<h2>Problem Mitigation</h2>
|
||
<p>Part of the problem is solved by the recently introduced <a class="reference external" href="https://w3c.github.io/webappsec/specs/subresourceintegrity/">Sub Resource
|
||
Integrity</a>
|
||
(SRI). To quote them: &quot;[it] defines a mechanism by which user agents may verify
|
||
that a fetched resource has been delivered without unexpected manipulation.&quot;.</p>
|
||
<p>SRI is a good start, but isn't enough: it ensures the assets (JavaScript files,
|
||
mainly) loaded from a specific HTML page are the ones the author of the HTML
|
||
page intends. However, SRI doesn't allow the User Agent to ensure the HTML page
|
||
is the one he wants.</p>
|
||
<p>In other words, we miss a way to create trust between <em>Application Authors</em> and
|
||
<em>User Agents</em>. The User-Agent currently has to trust the <em>Certificate
|
||
Authorities</em> and the delivery (<em>Indie Hoster</em>).</p>
|
||
<p>For desktop software distribution: <em>Crypto Experts</em> audit the software, sign it
|
||
somehow and then this signature can be checked locally during installation or
|
||
runtime. It's not automated, but at least it's possible.</p>
|
||
<p>For web applications, we don't have such a mechanism, but it should be
|
||
possible. Consider the following:</p>
|
||
<ul class="simple">
|
||
<li><em>App Authors</em> publish a new version of their software; They provide a hash of
|
||
each of their distributed files (including the HTML files);</li>
|
||
<li><em>Crypto Experts</em> audit these files and sign the hashes somehow;</li>
|
||
<li><em>User Agents</em> can chose to trust some specific <em>Crypto Experts</em>;</li>
|
||
<li>When a <em>User Agent</em> downloads files, it checks if they're signed by a trusted
|
||
party.</li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="chosing-who-you-trust">
|
||
<h2>Chosing who you trust</h2>
|
||
<p>In terms of user experience, handling certificates is hard, and that's where
|
||
the community matters. Distributions such as <a class="reference external" href="https://tails.boom.org">Tails</a>
|
||
could chose who they trust to verify the files, and issue warnings / refuse to
|
||
run the application in case files aren't verified.</p>
|
||
<p>But, as highligted earlier, CAs are hard to trust. A new instance of the same
|
||
CA system wouldn't make that much differences, expect the fact that
|
||
distributions could ship with a set of trusted authorities (for which
|
||
revocation would still need to be taken care of).</p>
|
||
<blockquote class="epigraph">
|
||
<p>[...] users are vulnerable to MitM attacks by the authority, which can vouch
|
||
for, or be coerced to vouch for, false keys. This weakness has been
|
||
highlighted by recent CA scandals. Both schemes can also be attacked if the
|
||
authority does not verify keys before vouching for them.</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf">SoK : Secure Messaging</a>;</p>
|
||
</blockquote>
|
||
<p>It seems that some other systems could allow for something more reliable:</p>
|
||
<blockquote class="epigraph">
|
||
<p>Melara et al proposed CONIKS, using a series of chained commitments to Merkle
|
||
prefix trees to build a key directory [...] for which individual users can
|
||
efficiently verify the consistency of their own entry in the directory
|
||
without relying on a third party.</p>
|
||
<p>This “self- auditing log” approach makes the system partially have no
|
||
auditing required (as general auditing of non-equivocation is still required)
|
||
and also enables the system to be privacy preserving as the entries in the
|
||
directory need not be made public. This comes at a mild bandwidth cost not
|
||
reflected in our table, estimated to be about 10 kilobytes per client per day
|
||
for self-auditing.</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf">SoK : Secure Messaging</a>;</p>
|
||
</blockquote>
|
||
<p>Now, I honestly have no idea if this thing solves the whole problem, and I'm pretty sure
|
||
this design has many security problems attached to it.</p>
|
||
<p>However, that's a problem I would really like to see solved one day, so here
|
||
the start of the discussion, don't hesitate to <a class="reference external" href="/pages/about.html">get in touch</a>!</p>
|
||
</div>
|
||
<div class="section" id="addendum">
|
||
<h2>Addendum</h2>
|
||
<p>It seems possible to increase the level a user has in a Web Application by
|
||
adding indicators in the User-Agent. For instance, when using an application
|
||
that's actually signed by someone considered trustful by the User-Agent (or the
|
||
distributor of the User-Agent), a little green icon could be presented to the
|
||
User, so they know that they can be confident about this.</p>
|
||
<p>A bit like User-Agents do for SSL, but for the actual signature of the files
|
||
being viewed.</p>
|
||
</div>
|
||
</content></entry><entry><title>Les problèmes de PGP</title><link href="https://blog.notmyidea.org/les-problemes-de-pgp.html" rel="alternate"></link><published>2015-05-25T00:00:00+02:00</published><updated>2015-05-25T00:00:00+02:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2015-05-25:/les-problemes-de-pgp.html</id><summary type="html"><blockquote class="epigraph">
|
||
<p>Flip a bit in the communication between sender and recipient and they will
|
||
experience decryption or verification errors. How high are the chances they
|
||
will start to exchange the data in the clear rather than trying to hunt down
|
||
the man in the middle?</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="http://secushare.org/PGP">http://secushare.org/PGP</a></p>
|
||
</blockquote>
|
||
<p>Une fois …</p></summary><content type="html"><blockquote class="epigraph">
|
||
<p>Flip a bit in the communication between sender and recipient and they will
|
||
experience decryption or verification errors. How high are the chances they
|
||
will start to exchange the data in the clear rather than trying to hunt down
|
||
the man in the middle?</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="http://secushare.org/PGP">http://secushare.org/PGP</a></p>
|
||
</blockquote>
|
||
<p>Une fois passé l'euphorie du &quot;il faut utiliser PGP pour l'ensemble de nos
|
||
communications&quot;, j'ai réalisé lors de discussions que PGP avait plusieurs
|
||
problèmes, parmi ceux-ci:</p>
|
||
<ul class="simple">
|
||
<li>Les <em>meta données</em> (y compris le champ &quot;sujet&quot; de la conversation) sont quand
|
||
même échangées en clair (il est possible de savoir qu'un message à été échangé
|
||
entre telle et telle personne, a telle date);</li>
|
||
<li>PGP se base sur un protocole de communication qui est lui non chiffré, et il
|
||
est donc facile de soit se tromper, soit dégrader le mode de conversation vers
|
||
une méthode non chiffrée;</li>
|
||
<li>Il est facile de connaître votre réseau social avec PGP, puisque tout le
|
||
principe est de signer les clés des personnes dont vous validez l'identité;</li>
|
||
<li>En cas de fuite de votre clé privée, tous les messages que vous avez chiffrés
|
||
avec elle sont compromis. On dit que PGP ne fournit pas de <em>forward secrecy</em>;</li>
|
||
<li>La découverte de la clé de pairs se passe souvent <em>en clair</em>, sans utiliser une
|
||
connexion &quot;sécurisée&quot; (HTTPS). Tout le monde peut donc voir ces échanges et
|
||
savoir de qui vous cherchez la clé;</li>
|
||
<li>Les discussions de groupes sont très difficiles: il faut chiffrer pour chacun
|
||
des destinataires (ou que ceux-ci partagent une paire de clés).</li>
|
||
</ul>
|
||
<p>Je suis en train de creuser à propos les alternatives à PGP, par exemple <a class="reference external" href="https://pond.imperialviolet.org/">Pond</a>, qui lui ne construit pas par dessus un
|
||
standard déjà établi, et donc n'hérite pas de ses défauts (mais pas non plus de
|
||
son réseau déjà établi).</p>
|
||
<p>En attendant, quelques bonnes pratiques sur PGP ;)</p>
|
||
<div class="section" id="bonnes-pratiques">
|
||
<h2>Bonnes pratiques</h2>
|
||
<p>Il est en fait assez facile d'utiliser PGP de travers. Riseup à fait <a class="reference external" href="https://help.riseup.net/en/security/message-security/openpgp/best-practices">un
|
||
excellent guide</a>
|
||
qui explique comment configurer son installation correctement.</p>
|
||
<ul class="simple">
|
||
<li>J'en ai déjà parlé, mais il faut absolument choisir des phrases de passes
|
||
suffisamment longues. Pas facile de les retenir, mais indispensable. Vous
|
||
pouvez aussi avoir un document chiffré avec une clé que vous ne mettez jamais
|
||
en ligne, qui contiens ces phrases de passe, au cas ou vous les oubliez.</li>
|
||
<li>Générez des clés RSA de 4096 bits, en utilisant sha512;</li>
|
||
<li>Il faut utiliser une date d'expiration de nos clés suffisamment proche (2
|
||
ans). Il est possible de repousser cette date si nécessaire, par la suite.</li>
|
||
</ul>
|
||
<p>Parmi les choses les plus frappantes que j'ai rencontrées:</p>
|
||
<ul class="simple">
|
||
<li>Utiliser le <em>flag</em> <cite>–hidden-recipient</cite> avec PGP pour ne pas dévoiler qui est
|
||
le destinataire du message;</li>
|
||
<li>Ne pas envoyer les messages de brouillons sur votre serveur, ils le seraient
|
||
en clair !;</li>
|
||
<li>Utilisez HPKS pour communiquer avec les serveurs de clés, sinon tout le
|
||
trafic est en clair.</li>
|
||
</ul>
|
||
<p>Le <a class="reference external" href="https://bitmask.net/">projet Bitmask</a> vise lui à rendre les outils de
|
||
chiffrement d'échanges de messages et de VPN simples à utiliser, encore quelque
|
||
chose à regarder.</p>
|
||
<p>Enfin bref, y'a du taf.</p>
|
||
</div>
|
||
</content></entry><entry><title>Simplifier les preuves d'identités</title><link href="https://blog.notmyidea.org/simplifier-les-preuves-didentites.html" rel="alternate"></link><published>2015-05-11T00:00:00+02:00</published><updated>2015-05-11T00:00:00+02:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2015-05-11:/simplifier-les-preuves-didentites.html</id><summary type="html"><p>L'un des problèmes non réellement résolu actuellement quant au chiffrement des
|
||
échanges est lié à l'authenticité des clés. Si quelqu'un décide de publier une
|
||
clé en mon nom, et en utilisant mon adresse email, cela lui est assez facile.</p>
|
||
<p>Il est donc nécessaire d'avoir des moyens de prouver que la …</p></summary><content type="html"><p>L'un des problèmes non réellement résolu actuellement quant au chiffrement des
|
||
échanges est lié à l'authenticité des clés. Si quelqu'un décide de publier une
|
||
clé en mon nom, et en utilisant mon adresse email, cela lui est assez facile.</p>
|
||
<p>Il est donc nécessaire d'avoir des moyens de prouver que la clé publique que
|
||
j'utilise est réellement la mienne.</p>
|
||
<p>Traditionnellement, il est nécessaire de faire signer ma clé publique par
|
||
d'autres personnes, via une rencontre en personne ou des échanges hors du
|
||
réseau. C'est par exemple ce qui est réalisé lors des <a class="reference external" href="https://fr.wikipedia.org/wiki/Key_signing_party">Key Signing parties</a>.</p>
|
||
<p>Une manière simple d'effectuer ces vérifications serait, en plus de donner son
|
||
adresse email, sa signature de clé, ou a minima de donner un mot clé pour
|
||
valider que les échanges proviennent bien de la bonne personne.</p>
|
||
<p>PGP propose un mécanisme de signature des clés d'autrui, une fois celles ci
|
||
validées, ce qui permet de placer sa confiance dans les signataires de la clé.</p>
|
||
<p><a class="reference external" href="https://keybase.io">Keybase.io</a> est un service qui vise à rendre la création
|
||
de ces preuves plus facile, en partant du principe qu'il est possible
|
||
d'utiliser différents moyens afin de prouver l'identité des personnes. Par
|
||
exemple, leurs comptes Twitter, GitHub ou leurs noms de domaines. De la même
|
||
manière qu'il est possible de signer (valider) les clés de nos amis, il est
|
||
possible de les &quot;tracker&quot; selon le jargon de keybase.</p>
|
||
<p>Donc, en somme, <em>Keybase.io</em> est un annuaire, qui tente de rendre plus facile la
|
||
création de preuves. Bien.</p>
|
||
<div class="section" id="quelques-points-d-ombre">
|
||
<h2>Quelques points d'ombre</h2>
|
||
<p>Il s'agit d'une <em>startup</em> américaine, domiciliée dans le Delaware, qui se trouve être
|
||
un des paradis fiscaux qui <a class="reference external" href="https://fr.wikipedia.org/wiki/Delaware">est connu pour être un paradis fiscal au coeur
|
||
même des États-Unis</a>. Je ne veux pas
|
||
faire de raccourcis trop rapides, bien évidemment, alors <a class="reference external" href="https://github.com/keybase/keybase-issues/issues/1569">j'ai ouvert un ticket
|
||
sur GitHub pour en savoir plus</a> (après tout, le fait
|
||
d'être un paradis fiscal permet peut-être d'échapper à certaines lois sur la
|
||
requêtes de données). D'autant plus étonnant, la startup n'a pour l'instant <a class="reference external" href="https://github.com/keybase/keybase-issues/issues/788">pas
|
||
de *business model*</a>
|
||
(ce qui en un sens est assez rassurant, même si on peut se poser la question de
|
||
pourquoi faire une startup dans ces cas là).</p>
|
||
<p>Le service (bien qu'en Alpha), n'est pas mis à disposition sous licence libre,
|
||
ce qui pour l'instant empêche quiconque de créer son propre serveur Keybase.
|
||
<a class="reference external" href="https://github.com/keybase/">Une partie des composants, cependant, le sont (open source)</a>.</p>
|
||
<p>J'ai du mal à croire en des initiatives qui veulent sauver le monde, mais dans
|
||
leur coin, je ne comprends pas pourquoi il n'y à pas de documentation sur
|
||
comment monter son propre serveur, ou comment les aider à travailler sur la
|
||
fédération. Mais bon, c'est pour l'instant une initiative encore fraîche, et je
|
||
lui laisse le bénéfice du doute.</p>
|
||
<p>Sur le long terme, une infrastructure comme <em>Keybase.io</em>, devra évidemment être
|
||
<a class="reference external" href="https://github.com/keybase/keybase-issues/issues/162">distribuée</a>.</p>
|
||
<blockquote class="epigraph">
|
||
<p>We've been talking about a total decentralization, but we have to solve
|
||
a couple things, synchronization in particular. Right now someone can
|
||
mirror us and a client can trust a mirror just as easily as the server at
|
||
keybase.io, but there needs to be a way of announcing proofs to any server
|
||
and having them cooperate with each other. We'd be so happy to get this
|
||
right.</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="http://chris.beams.io/posts/keybase/">Chris Coyne, co-founder of Keybase</a></p>
|
||
</blockquote>
|
||
<p>Afin de se &quot;passer&quot; de leur service centralisé, les preuves générées (qui sont
|
||
la force du système qu'ils mettent en place) pourraient être exportées sur des
|
||
serveurs de clés existants. C'est quelque chose <a class="reference external" href="https://github.com/keybase/keybase-issues/issues/890">qu'ils souhaitent réaliser .</a>.</p>
|
||
<p>Bref, une initiative quand même importante et utile, même si elle soulève des
|
||
questions qui méritent qu'on s'y attarde un brin.</p>
|
||
<p>Par ailleurs, <a class="reference external" href="https://leap.se/nicknym">d'autres projets qui visent des objectifs similaires</a> existent, via le projet LEAP, mais je n'ai pas
|
||
encore creusé.</p>
|
||
</div>
|
||
</content></entry><entry><title>Phrases de passe et bonnes pratiques</title><link href="https://blog.notmyidea.org/phrases-de-passe-et-bonnes-pratiques.html" rel="alternate"></link><published>2015-05-09T00:00:00+02:00</published><updated>2015-05-09T00:00:00+02:00</updated><author><name>Alexis Métaireau</name></author><id>tag:blog.notmyidea.org,2015-05-09:/phrases-de-passe-et-bonnes-pratiques.html</id><summary type="html"><blockquote class="epigraph">
|
||
<p>Au contraire des autres mots de passe, les mots de passe cryptographiques
|
||
ont specifiquement besoin d'être longs et extremement difficiles à deviner.
|
||
La raison est qu'un ordinateur (ou un cluster de plusieurs ordinateurs)
|
||
peut être programmé pour faire des trillions d'essais de manière
|
||
automatique. Si le mot de passe choisi …</p></blockquote></summary><content type="html"><blockquote class="epigraph">
|
||
<p>Au contraire des autres mots de passe, les mots de passe cryptographiques
|
||
ont specifiquement besoin d'être longs et extremement difficiles à deviner.
|
||
La raison est qu'un ordinateur (ou un cluster de plusieurs ordinateurs)
|
||
peut être programmé pour faire des trillions d'essais de manière
|
||
automatique. Si le mot de passe choisi est trop faible ou construit d'une
|
||
manière trop prédictible, cette attaque par la force pourrait se revéler
|
||
fructueuse en essayant toutes les possibilités.</p>
|
||
<p class="attribution">&mdash;<a class="reference external" href="https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices">The Electronic Frontier Foundation</a> (traduction de mon fait)</p>
|
||
</blockquote>
|
||
<p>Comprendre les concepts et l'écosystème qui permettent d'avoir une vie
|
||
numérique chiffrée n'est pas quelque chose d'aisé. <a class="reference external" href="https://emailselfdefense.fsf.org/fr/">Plusieurs</a> <a class="reference external" href="http://www.controle-tes-donnees.net/outils/GnuPG.html">guides</a> ont été écrits à ce
|
||
propos, et pour autant je me rends compte que naïvement il est possible de
|
||
mal utiliser les outils existants.</p>
|
||
<blockquote class="epigraph">
|
||
<p>Utilisez un <em>bon</em> mot de passe pour votre session utilisateur et une
|
||
<em>bonne</em> phrase de passe pour proteger votre clé privée. Cette phrase de
|
||
passe est la partie la plus fragile de tout le système.</p>
|
||
<p class="attribution">&mdash;La page de manuel de GPG.</p>
|
||
</blockquote>
|
||
<p>Une phrase de passe devrait:</p>
|
||
<ul class="simple">
|
||
<li>Être suffisamment longue pour être difficile à deviner;</li>
|
||
<li>Ne pas être une citation connue (littérature, livres sacrés etc);</li>
|
||
<li>Difficile à deviner même pour vos proches;</li>
|
||
<li>Facile à se souvenir et à taper;</li>
|
||
<li>être unique et non partagée entre différents sites / applications etc.</li>
|
||
</ul>
|
||
<p>Une des techniques consiste à utiliser des mots du dictionnaire, sélectionnés de
|
||
manière aléatoire, puis modifiés.</p>
|
||
<div class="figure">
|
||
<img alt="XKCD sur la force des mots de passe." src="https://imgs.xkcd.com/comics/password_strength.png" />
|
||
</div>
|
||
<p>Micah Lee <a class="reference external" href="https://github.com/micahflee/passphrases">travaille également sur un outil</a> qui vise à rendre la mémorisation
|
||
des phrases de passe plus aisée, de par leur répétition avec des pauses de plus
|
||
en plus longues.</p>
|
||
<div class="figure">
|
||
<img alt="Capture d'écran du logiciel de génération et de mémorisation des phrases de passe." src="{filename}/static/passphrases.png" />
|
||
</div>
|
||
<p>Oui, ce n'est pas aussi simple que ce qu'il y parait. Pour ma part, j'ai une
|
||
copie en local de mes clés, dans un fichier chiffré avec une autre clé que j'ai
|
||
généré pour l'occasion et que je ne partagerait pas. J'ai par ailleurs
|
||
<a class="reference external" href="https://github.com/jamessan/vim-gnupg">configuré</a> mon éditeur de texte pour
|
||
pouvoir chiffrer les documents textes par défaut.</p>
|
||
<p>J'ai donc regénéré une nouvelle fois mes clés de travail et personnelles, en
|
||
utilisant des phrases de passe plus complexes.</p>
|
||
<p>Reste encore la question de la sauvegarde de ces clés privées de manière
|
||
chiffrée, que je n'ai pas encore résolue. Bref, tout cela me semble bien
|
||
compliqué pour réussir à l'expliquer à des novices, qui pour certains ne sont
|
||
même pas sur de l'intérêt de la chose.</p>
|
||
</content></entry></feed> |