À propos des certificats

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é. Ce n’était qu’une question de temps de toute façon. D’après la Wikipédia:

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
• 179 euros chez GlobalSign
• 99 euros chez Thawte

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

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. Les certificats racines sont installés par le paquet 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, 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 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 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 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é.