Je teste Let’s Encrypt, c’est pas mauvais sur le papier, mais…

Cet article a été publié il y a 8 ans 4 mois 19 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

En effet, vu qu’en ce Samedi matin où j’écris, je suis debout depuis 6h, je me suis dit que c’était le moment d’essayer. Et pour les retardataires, je vais rappeler ce qu’est Let’s Encrypt, et aussi, tout simplement pour les moins aguerris, le HTTPS. Et aussi pourquoi je suis moyennement content, mais là, c’est du perso. En gros, un article « triple effet Kiss Kool ».

Rappel sur le HTTPS

Hyper Text Transfer Protocol est le langage qu’utilisent nos navigateurs (Firefox, Chrome, Opera, IE, Safari, et j’en passe) pour récupérer les contenus sur le Web. C’est d’ailleurs grâce à lui que le Web est ce qu’il est. Par défaut, ce protocole fait passer toutes les informations en clair. Ce qui veut dire qu’une personne malintentionnée peut regarder ce qui se passe sur une connexion et voir quelles pages vous visitez, ce qu’elle contient, et parce qu’on peut remplir des formulaires, lire, au hasard, un nom d’utilisateur et un mot de passe.

HTTPS est donc la version chiffrée de ce protocole. Basiquement, et parce que ce n’est pas non plus un cours sur SSL/TLS et le protocole HTTPS, vous demandez une page avec https://blablabla. Votre navigateur va demander en fait l’identité du serveur derrière blablabla, sous la forme d’un certificat. Ce certificat est signé par une autorité de certification, dite de confiance, en gros, une tierce personne (parmi les plus connues : GlobalSign, Symantec, CACert – récemment rejetée par Mozilla). Le serveur répond donc avec son certificat, s’il en a un évidemment, et votre navigateur va comparer la signature avec sa propre base d’autorités de certification. Si c’est bon, les deux se mettent d’accord sur un algorithme de chiffrement, sur la base de ceux que propose le serveur, et roule ma poule, chaque paquet composant les pages Web que vous demandez au serveur est chiffré, et l’espion ne voit que de la bouillie.

Twitter par exemple n’est accessible qu’en HTTPS. Les sites d’e-commerce, de banques, de messageries en ligne, tous proposent du HTTPS (plus ou moins bien implémenté, mais c’est pas le débat aujourd’hui). Et on comprend que protéger l’accès à de telles plateformes, du moins la phase d’authentification, est important. Plus important encore, tout ce qui est chiffré empêche toute écoute abusive, comme celles que pratiquent maintenant ouvertement l’état français, sous couvert d’état d’urgence. Plus fort que la NSA les gars.

Let’s Encrypt

Sur le papier, et si on a bien configuré le truc, un certificat « auto-signé » (donc pas par une autorité de certification), permet une bonne sécurité de l’échange. Le souci, c’est que forcément il n’est pas reconnu par le navigateur, et celui-ci affiche une alerte. Il faut alors une bonne dose de confiance dans le destinataire ou le réseau sur lequel on navigue pour accepter d’utiliser un tel certificat.

L’autre souci, c’est que les autorités de certifications se sucrent allègrement sur les certificats, et notamment les « wildcard », ceux qui permettent d’utiliser la même identité sur plusieurs variantes d’un domaine (blog.seboss666.info, test.seboss666.info, bref, *.seboss666.info, d’où le wildcard). Donc le chiffrement acceptable par tous coûte cher, et beaucoup soit font l’impasse dessus, soit se payent quelques cheveux blancs, à l’image d’un Cyrille Borne qui a lutté pour que son téléphone accepte le certificat auto-signé de son serveur Owncloud.

Let’s Encrypt est une initiative de l’Internet Security Research Group, entité montée par Mozilla, l’Electronic Frontier Foundation, La Linux Foundation, mais pas seulement, puisque des gros industriels comme Cisco (qui fournit du matériel pour la moitié des datacenters de la planète), Akamaï (l’un des plus gros fournisseurs de CDN et de réseau au monde, si ce n’est le plus gros) ainsi que l’université du Michigan sont de la partie. Bref, une initiative globale, visant à proposer, gratuitement, des certificats SSL reconnus par tous les navigateurs, et également, installable le plus possible de manière automatique. Le chiffrement et donc la sécurité à priori à la portée de toutes les bourses.

Limitations techniques

Pour des raisons évidentes, sachant qu’il n’y a pas besoin d’un compte pour obtenir un certificat, ils ne sont valables que 90 jours, là où un certificat « classique » peut être valable plusieurs années. Pourquoi ? Si jamais quelqu’un utilise un certificat comme celui-là pour tenter d’usurper le site d’une banque par exemple, il faut pouvoir l’exclure rapidement des certificats valables.

Let’s Encrypt a pour but, du coup, de proposer un outil qui permet d’automatiser le plus possible la création, le renouvellement et l’installation des certificats. Pour l’instant, cet outil ne fonctionne correctement qu’avec Apache, le support d’Nginx n’étant pas encore prêt. On comprend mieux dès lors la notion de « beta », qui signifie toujours en phase de développement.

Mon expérience de l’installation

A partir de maintenant, si vous n’êtes pas technicien et que mon récit de l’installation ne vous intéresse pas plus que ça, vous pouvez sauter à la conclusion, personne ne vous en voudra (en tout cas pas moi).

Déjà, ISPConfig a récemment réussi le tour de force de me « casser » apt, en utilisant des backports sid qui entrent en conflit avec certains paquets stables, moralité, j’ai pas pu installer l’outil sur la machine qui héberge le blog. J’ai donc du me rabattre sur la méthode manuelle, bien plus lourde, mais qui fonctionne bien au final. Juste on perd la totalité de l’intérêt de l’automatisation, vu que j’ai tout fait moi-même.

Donc j’ai installé l’outil (écrit en Python 🙂 ) sur la vm du VPN, et lancé la création en utilisant la méthode manuelle :

Oui comme Cascador je me connecte en root directement sur ce serveur. Bref, à un moment donné, il vous demande de créer un fichier dans un dossier spécial de votre vhost, j’ai donc dû me connecter à la vm ISPConfig pour aller ajouter manuellement ce fichier. Et là, paf :

Une erreur 403 donc. Petit essai manuel, en effet, ça coince. Direction les logs, la configuration du vhost interdit l’accès. OK, allons donc voir la configuration du vhost, et là, paf :

Ah ben oui, forcément. Alors là je gueule déjà un bon coup. Autant bloquer les .htmachin, je veux bien (il peut y avoir quelques infos importantes dedans à cacher), autant tout ce qui commence par « . », et donc un dossier caché comme dans le cas présent, c’est moyen. Pas le temps de me farcir l’interface lente, je modifie fissa, je restart Nginx, et je recommence la procédure, qui évidemment demande de stocker une nouvelle clé. Et là, ça passe, et ça stocke les éléments du certificat dans /etc/letsencrypt/archive/blog.seboss666.info .

Une fois de plus, ISPConfig se met entre moi et la configuration d’Nginx. Je passe d’abord par l’interface, pour activer le SSL. Ensuite, dans l’onglet SSL, je rentre des infos bidons, et j’enregistre. Il lui faut un moment pour percuter et modifier les configurations. Au passage, il a fait sauter ma modification concernant les fichiers commençant par un « . », magnifique, mais maintenant que j’ai le certificat, pas grave. Je vais donc dans le dossier ssl fraîchement créé par cette daubasse pour écraser les certificats bidons créés par ceux que j’ai généré sur la vm VPN. Les utilisateurs d’Nginx pourront de se contenter directement du « bundle », alias fullchain1.pem. Et j’ai bien dit écraser, autrement dit, il faut conserver les noms générés par ISPConfig (oui sinon il écrasera votre fichier de configuration, souvenez-vous…). Un dernier restart d’Nginx et roulez jeunesse, ça fonctionne.

Un WordPress à adapter

En effet, si vous essayez, vous verrez que Firefox vous alertera que certains contenus ont été désactivés parce qu’ils ne sont pas chiffrés. Honnêtement, il n’y a rien de plus ni rien de moins pour l’instant qui se charge, le blog est strictement le même, juste certains liens sont en HTTP parce qu’ils sont écrits en dur quelque part.

Et WordPress est assez chiant pour ça : chaque lien ajouté dans un article est écrit de manière complète, même quand il vient du blog, donc vous n’avez pas le choix, il faut les modifier. C’est pareil pour certains morceaux de thème parfois, qui va partir du principe que l’image doit être « en clair ». Là, ce sont les fichiers qui sont à modifier.

Et puis il y a le pire : les options des thèmes et plugins. Là, certains font la fête, et stockent tout avec du lien en clair. Il faut alors tenter de modifier aussi tout ça pour que ça passe en HTTPS. Et enfin, le comble, il y a les éléments qui sont externes, uniquement en clair, et là, vous n’avez pas le choix, puisque ce ne sont pas vos éléments et que vous n’avez aucun contrôle dessus.

Pour la plupart des choses qui sont en base de données, on pourra se baser sur l’article de Korben à propos du transfert d’un blog sur un autre domaine. Pour avoir à en migrer plusieurs en ce moment pour un client, je peux vous dire que c’est un travail de longue haleine, et qui peut vite tourner au désastre, certains thèmes et/ou plugins n’aimant pas qu’on modifie leurs configurations à la main.

Conclusion

Si tant est que je puisse à un moment donné tester l’automatisation réelle de l’outil, le certificat est de bonne qualité, et parfaitement reconnu par les navigateurs que j’ai pu tester, c’est donc malgré tout un très bon début. Mes griefs contre ISPConfig ne concernent que moi à priori, parce que je déteste quand un outil vient péter du travail fait à la main.

Bref, on avance donc vers un bon moyen de chiffrer un peu plus nos communications privées (et pas crypter, nom de dieu), et à l’heure où je réfléchis à installer mon propre « cloud » quelque part, il n’est pas question que quelque chose passe en clair. Un vrai certificat SSL qui permet de couvrir tous mes besoins n’est donc pas de trop. Et ça vaut aussi pour ceux qui s’intéressent à la campagne Dégooglisons Internet de Framasoft. Surveillez donc vos barres d’adresses, que le cadenas soit idéalement vert (tiens c’est le cas pour Framasoft justement). Cela permet, dans une certaine mesure, de confirmer que le site en face respecte la confidentialité de l’échange, et on l’espère, respecte un peu vos données.