--- comments_url: https://com.richard-dern.fr/post/544 date: '2016-01-31 17:51:50' entreprises: - Crucial - Let's Encrypt - Debian - Facebook links: - lang: fr name: Page d'origine sur LinuxFr url: https://linuxfr.org/users/richarddern/journaux/a-propos-des-certificats tags: - Certificat - Sécurité - Firefox - Certificats - Informatique - Internet - Autorité - Certification - Navigateur - Web - Chiffrement - Prix - Maison - Blog - Serveur - Client - Plus - Réseau - Alternatives - Linux - Philosophie title: À propos des certificats weather: humidity: 97 illuminance: 0.0 precipitations: true pressure: 1011.8 source: - open-meteo temperature: 8.4 wind_direction: 247 wind_speed: 25.0 --- _Un autre article publié initialement sur mon site, sur un sujet qui me tient particulièrement à cœur, et pour lequel j'espère avoir des avis._ > Les certificats font régulièrement la une de l'actualité informatique ces derniers temps. > Ces petits fichiers ne contenant que du texte et valant leur poids (en kilo-octets) en dollars, sont censés être les garants de notre sécurité sur Internet. > Mais en simplifiant leur mise en oeuvre nous avons ouvert une brèche. > Une brèche dans un élément crucial de la chaîne de sécurité. ## Qu'est-ce qu'un certificat ? Un certificat est un "simple" fichier texte. La suite de caractères qu'il contient sert à chiffrer des données. Pour le commun des mortels, cela signifie simplement que le numéro de carte bancaire qu'ils transmettent à un site tiers se fait de façon sécurisée, sans bien sûr comprendre tout ce que cela implique sur le plan technique. Dans la pratique, un certificat doit être signé, validé, par une autorité de certification. Il en existe un certain nombre, et il s'agit simplement d'un organisme habilité à émettre un certificat racine. Ce certificat racine est généralement présent au sein du système d'exploitation ou du navigateur web, dès son installation. C'est la partie publique d'une chaîne de chiffrement, dont la clé privée est - normalement - jalousement gardée par l'autorité de certification. Le but de ce certificat racine est notamment de s'assurer que les sites Internet que l'on visite sont effectivement sécurisés, et que la chaîne de confidentialité ne soit pas brisée, c'est-à-dire, que personne ne se soit intercalé entre le site en question et le visiteur. ## Je ne vois pas le problème Il n'y a pas eu de raison de douter de ce fonctionnement, jusqu'à ce qu'on trouve un [certificat racine vérolé](http://www.nextinpact.com/news/93126-un-adware-livre-avec-machines-lenovo-pose-serieux-risque-securite.htm). Ce n'était qu'une question de temps de toute façon. D'après la [Wikipédia](https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique#Vuln.C3.A9rabilit.C3.A9s): > Le système de certificats ne présente pas de vulnérabilité technique théorique sous réserve que toutes ses étapes soient correctement implémentées. "*[..]sous réserve que[..]*". C'est toujours inquiétant de lire ça. Surtout quand on parle de certificats racines. Concrètement, les certificats racines et les autorités de certification posent plusieurs problèmes, selon moi. ### Les coûts prohibitifs Un certificat coûte au minimum une centaine d'euros. Quelques exemples de premiers prix: - 349 euros chez [Symantec](http://www.symantec.com/fr/fr/ssl-certificates/) - 179 euros chez [GlobalSign](https://www.globalsign.fr/fr/ssl/domain-ssl/) - 99 euros chez [Thawte](https://www.thawte.fr/ssl/index.html) Ces prix sont **par an**. Pour un fichier texte qu'on peut générer à la maison. ### L'insouciance C'est aussi à force d'œuvrer à la simplification de l'informatique qu'on scie la branche sur laquelle on est assis. Ce qui pousse les éditeurs de sites Internet à acheter un certificat, c'est **l'insouciance induite chez les visiteurs**. Avant d'arriver sur ce blog, vous avez fait face à une fenêtre vous informant de l'invalidité de mon certificat. En réalité, mon certificat est tout à fait valide. Il n'est juste pas signé par une autorité de certification racine, dont les certificats racines sont dans votre navigateur. Pour un visiteur non technicien, cette page fait peur. Ce n'est évidemment pas vendeur. Du coup, les éditeurs se tournent vers des autorités de certification pour que la visite de leur site ne soit pas entachée de cet avertissement. ### Le fameux avertissement ![La fenêtre d'avertissement de iceweasel/firefox](images/avertissement-ssl.jpeg "Source : https://www.athaliasoft.com/images/post/1cecd6eec207ca658b785f4ba5497a91/avertissement-ssl.jpeg") Lors d'une session sécurisée, le serveur réclame un certificat que le navigateur est censé trouver dans sa "base de certificats". S'il n'en dispose pas, il demande à l'utilisateur s'il veut réellement accepter le certificat émis pas le serveur. Sauf s'il est signé par une autorité de certification qui dispose d'un certificat racine inclus dans le navigateur ou le système d'exploitation. L'autre cas où le navigateur demande à l'utilisateur s'il veut réellement accepter le certificat, c'est lorsque le certificat attendu diffère de celui déjà dans la base de certificats du client. Le problème, c'est qu'un certificat peut tout à fait être légitime, sans pour autant être signé par une autorité de certification racine. Dès lors, le ton pris par le navigateur pour avertir l'utilisateur que le certificat du serveur est invalide est légèrement hautain, voire dédaigneux, semble-t'il à la botte des autorités de certification racines et de leurs dollars bien mal acquis. ## Quoi faire ? Je tourne sous [Debian](http://www.debian.org/). Les certificats racines sont installés par le paquet [*ca-certificates*](https://packages.debian.org/jessie/ca-certificates). Il est impossible de le supprimer car bon nombre d'autres paquets dépendent de lui, chose que j'ai peine à expliquer. ``` # apt-cache showpkg ca-certificates Package: ca-certificates [...] Reverse Depends: wordpress,ca-certificates openssl,ca-certificates 0install-core,ca-certificates wordpress,ca-certificates wget,ca-certificates w3m,ca-certificates ubuntu-dev-tools,ca-certificates python-txaws,ca-certificates sympa,ca-certificates sylpheed,ca-certificates ssh-import-id,ca-certificates software-properties-common,ca-certificates sendmail-base,ca-certificates rubygems-integration,ca-certificates ruby-webmock,ca-certificates ruby-excon,ca-certificates python3-requests,ca-certificates python-requests-whl,ca-certificates python-requests,ca-certificates libqt4-network,ca-certificates libqca2,ca-certificates python3-urllib3,ca-certificates python-urllib3-whl,ca-certificates python-urllib3,ca-certificates python3-tornado,ca-certificates python-tornado,ca-certificates python3-pip,ca-certificates python-pip,ca-certificates python3-httplib2,ca-certificates python-httplib2,ca-certificates libpurple0,ca-certificates php-guzzlehttp-ringphp,ca-certificates php-guzzle,ca-certificates osc,ca-certificates openssl,ca-certificates libopenconnect3,ca-certificates nodejs-dev,ca-certificates libneon27-gnutls,ca-certificates mutt,ca-certificates msmtp,ca-certificates mew-beta-bin,ca-certificates mew-bin,ca-certificates mercurial-common,ca-certificates libwww-perl,ca-certificates liblwpx-paranoidagent-perl,ca-certificates liblwp-protocol-https-perl,ca-certificates libio-socket-ssl-perl,ca-certificates libhttp-tiny-perl,ca-certificates libgwenhywfar-data,ca-certificates lava-dev,ca-certificates kdelibs5-data,ca-certificates igtf-policy-unaccredited,ca-certificates igtf-policy-slcs,ca-certificates igtf-policy-mics,ca-certificates igtf-policy-iota,ca-certificates igtf-policy-experimental,ca-certificates igtf-policy-classic,ca-certificates php-google-api-php-client,ca-certificates gnustep-base-common,ca-certificates glib-networking-tests,ca-certificates gajim,ca-certificates freeradius,ca-certificates fetchmail,ca-certificates esniper,ca-certificates epiphany-browser,ca-certificates libcurl3-nss,ca-certificates libcurl3-gnutls,ca-certificates libcurl3,ca-certificates ca-certificates-java,ca-certificates 20121114 python-bzrlib,ca-certificates boinc-client,ca-certificates balsa,ca-certificates aria2,ca-certificates ``` Mais c'est l'idée: j'aimerais supprimer tous les certificats racines de ma machine (on peut les supprimer un à un du navigateur ceci-dit). Vous l'aurez compris: cela impliquerait que la première visite sur chaque site sécurisé que je fréquente soit précédée du message d'avertissement sus-cité. Un certificat à vérifier et à valider une fois pour toutes - normalement - et par site. Je pense sincèrement qu'il s'agit là de la solution la plus raisonnable: forcer l'utilisateur à vérifier la chaîne de sécurité lors de sa première connexion à un site sécurisé. Ça prend quelques secondes, et peut éviter de grands problèmes. Par ailleurs, cette page d'avertissement devrait être nettement moins agressive. Par exemple, parler de certificat *inconnu* lors de la première visite, plutôt que de certificat invalide, et opter pour une mise en page évoquant l'*information* plutôt que l'avertissement. Et parler de changement de certificat lorsqu'on visite un site dont le certificat ne correspond plus à celui déjà accepté auparavant, en optant cette fois pour la mise en page traditionnelle, afin d'avertir l'utilisateur que, cette fois, il y a danger. Peut-être même afficher directement le certificat au lieu de devoir l'afficher dans une boîte de dialogue. En tout cas, je recommande plus que chaudement de [générer soi-même ses propres certificats](https://duckduckgo.com/?q=cr%C3%A9er+sa+propre+autorit%C3%A9+de+certification&kaj=m&k5=1&km=m&kac=-1&k1=-1&kw=s&kx=5a8952&kai=1&kz=-1&kal=-1&kp=-1&kak=-1&kk=-1&kd=1&kad=fr_FR&t=ffsb), avec sa propre autorité de certification, et déployer ses propres certificats "racines" dans les navigateurs qu'on utilise. C'est probablement coûteux en temps et en argent en entreprise, et présente sûrement peu d'intérêt pour un petit réseau à la maison (encore que...), mais qu'en serait-il du prix d'un dérapage incontrôlé ? ## Le cas de Let's Encrypt En ce qui concerne le prix des certificats, il y a des solutions alternatives, et notamment [Let's Encrypt](https://letsencrypt.org/) qui déchaîne les passions. Sur le papier, c'est alléchant puisque Let's Encrypt permet de se procurer gratuitement des certificats signés par une autorité de certification racine. Donc pas de message d'avertissement dans le navigateur, et un cadenas vert pour rassurer l'utilisateur. ### Pourquoi ce n'est pas aussi bien que ce qu'on croit En ce qui me concerne, je vais passer pour un paranoïaque comme d'habitude, mais j'ai tendance à ne pas faire confiance à un tiers, au moins pour ce genre de choses. D'autant qu'on peut parfaitement faire ses propres certificats à la maison, tout aussi gratuitement. Ma crainte me parait justifiée, en particulier quand on voit les sponsors de Let's Encrypt. Personnellement, j'ai du mal à admettre que l'[EFF](https://www.eff.org/) puisse être sponsor des mêmes initiatives que facebook (est-il nécessaire de préciser pourquoi ?) ou Cisco (connue pour ses backdoors dans ses routeurs). Et voir ces entreprises s'immiscer dans [un projet de la Linux Foundation](http://collabprojects.linuxfoundation.org/) me laisse tout aussi perplexe, mais c'est un autre débat. ## Au final... Au final, je ne vois qu'un changement de philosophie vis-à-vis des certificats racines pour améliorer les choses. Je considère désormais chaque certificat racine comme une potentielle backdoor, permettant de faire tout et surtout n'importe quoi, sans le moindre contrôle de l'utilisateur. On place notre confiance dans des entreprises financées notamment par ces certificats. C'est contraire aux principes d'un Internet ouvert et décentralisé. Contraire même au principe de sécurité le plus élémentaire: ne jamais céder cette dernière à un tiers. Enfin, c'est une preuve de notre oisiveté qui tend à privilégier le confort à la sécurité.