Le blog utilise depuis quelques jours HTTPS. J’ai pu mettre en place HTTPS gratuitement grâce à Let’s Encrypt, une initiative supportée par différents acteurs du web visant à sécuriser le web à grande échelle.
Let’s Encrypt
Let’s Encrypt résout les deux plus gros freins à l’adoption de HTTPS :
- Il propose des certificats gratuits reconnus par une autorité de certification et donc considérés comme étant de confiance par la très grande majorité des navigateurs.
- Il propose également un outil open-source qui prend en charge de manière automatique la configuration du serveur web. Il était jusqu’alors difficile de configurer correctement un serveur web en HTTPS quand on ne connaît pas grand chose au fonctionnement du protocole. L’outil met en place la configuration nécessaire pour le certificat, mais aussi la configuration optimale pour avoir le maximum de sécurité tout en excluant le minimum de clients.
Retour d’expérience
J’avais peu de temps devant moi et je comptais sur l’utilitaire de Let’s Encrypt pour tout faire automatiquement. Pour l’instant l’outil ne fonctionne qu’avec Apache sur des serveurs Debian ou dérivant de Debian, mais ça tombe bien pour moi puisque l’environnement qui fait tourner le blog correspond à ces critères.
J’ai donc lancé le script letsencrypt-auto comme nous l’invite à le faire la documentation et il s’est chargé de tout. Il a d’abord installé les quelques dépendances manquantes via apt-get, puis il a lu la configuration Apache, a listé les virtual hosts qu’il a détectés et m’a demandé lesquels je souhaitais passer en HTTPS. J’ai fait ma sélection, il m’a demandé mon adresse mail, m’a proposé de faire une redirection automatique de HTTP vers HTTPS pour forcer l’utilisation en HTTPS et m’a ensuite dit que c’était terminé. Il m’a d’ailleurs invité à aller voir le rapport proposé par SSLLabs pour vérifier la sécurité. Et il se trouve que tous les voyants sont au vert !
Je suis suis alors rendu sur le blog, et, surprise, tout fonctionnait ! Par sécurité j’avais quand même gardé une copie de la configuration Apache au cas où mais tout s’est bien passé.
Les certificats créés par Let’s Encrypt ne sont par contre valables que 3 mois et, bien que ce soit prévu dans les prochaines version, la version actuelle de l’outil ne supporte pas le renouvellement automatique des certificats. Il faudra donc que je pense à les renouveler manuellement avant leur expiration. Avoir des certificats à durée de vie limitée est clairement quelque chose d’intéressant sur le plan de la sécurité, mais l’absence temporaire d’automatisation clairement un manque qui devrait être bientôt comblé.
Le problème du Mixed Content
Le site fonctionnait parfaitement en HTTPS, mais le navigateur n’affichait pourtant pas le fameux cadenas vert parce que certaines ressources de la page étaient chargées en HTTP. Les navigateurs modernes considèrent que la navigation est sûre que si l’ensemble des ressources chargées le sont en HTTPS. Lorsque ce n’est pas le cas, ils indiquent que, bien que la page actuelle soit servie via HTTPS, certaines ressources ne le sont pas.
Après analyse de la situation, il se trouve que WordPress utilise des adresses absolues pour références les images. Dans tout le contenu existant, les images sont chargées en HTTPS. Je ne sais pas trop pourquoi WordPress utilise des adresses absolues dans le contenu, parce que ça pose problème lors de ce genre d’opération, j’imagine qu’ils ont une bonne raison de le faire. Une petite extension WordPress qui modifie le contenu à la volée avant de l’afficher m’a permis de résoudre le problème.
Pourquoi HTTPS ?
Il est légitime de se poser la question de l’intérêt de HTTPS sur un site comme ce blog dans la mesure où les utilisateurs ne font de la lecture et que tout le contenu est de toute façon public. Il y a en effet peu d’informations confidentielles et un enjeu assez mineur par rapport à un site où on s’identifie et on envoie des informations plus critiques. Si c’est moins important pour les lecteurs, ça l’est davantage pour moi quand je m’identifie dans la console d’administration de WordPress pour écrire du contenu. Il est particulièrement important dans ce cas d’avoir une connexion chiffrée.
A noter que la version HTTP du site redirige maintenant automatiquement vers HTTPS. Cela ne pose normalement pas de problèmes pour les navigateurs, en revanche je ne sais pas comment se comportent les agrégateurs RSS lorsqu’ils rencontrent une redirection. Il faudra peut-être simplement rajouter un petit s vers le début de l’URL pour rétablir le fonctionnement.
Merci à Let’s Encrypt pour cette excellente initiative qui vise à mettre la sécurité à portée de tout un chacun afin de créer un web plus sûr. J’espère que l’arrivée de ce projet (qui n’est pour l’instant qu’au stade de béta) permettra une adoption massive de HTTPS sur le web.
C’est simple et ça fonctionne. Testé et approuvé !
L’image d’en-tête provient de Flickr.
Le renouvellement automatique est arrivé un peu plus tard (par rapport à la date de publication de l’article).
On peu aussi l’automatiser avec certbot (https://certbot.eff.org/) qui se charge de l’installation et du renouvellement
Il a coulé pas mal d’eau sous les ponts depuis l’écriture de l’article. Mais en effet le renouvellement automatique est maintenant supporté, même si je n’ai pas pris le temps de regarder comment il fonctionne.
PoM, du recul sur le mécanisme de renouvellement automatique ?
Notons par ailleurs que Let’s Encrypt nous prévient par mail à plusieurs reprises quand l’expiration du certificat approche. Pour le moment je me repose sur ces messages.
De mon côté j’utilise aussi Let’s Encrypt au travail et je me suis débrouillé sans le module Apache. J’utilise du coup la commande suivante pour les créer / renouveler : letsencrypt certonly –standalone -d domaine1.com domaine2.com
Cela fonctionne bien mais je suis obligé de couper le serveur HTTP(S) (en l’occurrence Apache) pour que Let’s Encrypt fasse ses vérifications sur le nom de domaine. Pas cool cette coupure de service, même si ça ne dure pas bien longtemps. Quelqu’un sait comment ne pas couper le service ?
Est-il possible dans le cas d’un développement Java côté serveur d’avoir un serveur Apache en proxy qu’on peut configurer automatiquement avec Certbot ?
Oui, et pour ma part c’est exactement comme cela que je déploie mes applicatifs Java en ce moment.
Le module Apache mod_md (managed domain) est arrivé dans la version 2.4.30 d’Apache. Il apporte la possibilité à Apache de générer automatiquement les certificats des noms de domaine qu’il est amené à gérer.
Je l’utilise depuis la sortie d’Ubuntu 18.04 (il n’était pas disponible dans la version précédente). C’est très pratique et très efficace. Il se débrouille de générer et renouveler automatiquement les certificats.
Automatiquement ou presque… Lorsqu’il génère un certificat, il n’est pas en mesure pour des questions d’autorisation de venir modifier la configuration d’Apache, et donc il faut demander un reload manuellement à Apache pour qu’il soit pris en compte. Il en va de même lorsqu’il le régénère. Du coup il est nécessaire de demander à Apache de recharger la configuration après le premier déploiement et de mettre en place une tâche planifiée de manière quotidienne par exemple qui recharge la configuration. Et avec ça, plus besoin de se soucier du cycle de vie des certificats !
Auparavant j’utilisais l’outil letsencrypt en ligne de commande mais c’était plus compliqué et manuel.
Bon déploiement !
Merci pour la réponse détaillée, c’est vrai que pour installer Let’s encrypt manuellement en ligne de commande sur un serveur Java c’est un peu long et complexe. J’essaierai donc de mettre un serveur Apache configuré pour HTTPS en front d’un serveur Tomcat, car pour l’instant du coup j’ai passé mon serveur en Apache, et mes applications Java ne sont plus en ligne.
Pour pouvoir avoir deux serveurs web différents sur la même machine (un PHP et un Java), je trouve que HTTPS complique la chose. Du coup je m’en tiens à un seul langage pour mes applications personnelles que je souhaite mettre en ligne.
En quoi HTTPS fait que c’est plus compliqué que HTTP ?
Un serveur qui écoute le port HTTP ou HTTPS et qui délègue le nécessaire à via un proxy à d’autres serveurs (Java par exemple), c’est pas très compliqué à mettre en place.
Et après plusieurs mois de recul, je confirme que la solution des certificats gérés automatiquement par Apache fonctionne bien. Il ne faut juste pas oublier de recharger sa configuration une fois par jour par exemple.
J’ai cependant noté des problèmes de segfault dans Apache lors de l’ajout d’un nom de domaine pour lequel il doit gérer le certificat. J’ai galéré plusieurs fois à cause de ça, mais une fois que c’est en place ça fonctionne bien. Je précise que j’utilise Ubuntu 18.04.