Ça y est, je suis full HTTPS (et autres conseils relatifs)

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

Oui parce qu’en bon feignant que je suis, je n’avais activé le SSL que pour le blog, je n’avais pas fait le travail sur la base de données, et très important, j’avais zappé Piwik qui était appelé en HTTP et donc bloqué par les navigateurs modernes. Normalement, devrait plus y avoir de problème.

Faut vraiment faire attention à tout

Enfin presque, j’ai pas regardé dans tous les coins, j’ai corrigé les liens que je savais être mauvais, et j’ai fait un premier test pour voir le résultat :

C'est pas beau

C’est pas beau

Ah bon, pourquoi pas, je m’attendais à mieux de la part d’une Debian Jessie, je me renseigne un peu (les lignes en dessous, qu’on ne voit pas sur l’image, donnent de très bonnes indications). Je génère un Diffie Hellman 2048 bits, et là, panique à bord, faut modifier la conf’ Nginx (j’ai suivi l’incontournable HowToForge pour ça), mais remember, je suis sur ISPConfig, je serre donc les fesses en espérant que ça ne pètera pas dans le temps. Deuxième test (rappel, ça prend un peu de temps) :

ssl_final_test

Inutile de m’attarder plus longtemps sur le sujet, n’est-ce pas ? Surtout que c’est dimanche, et que j’ai la flemme de creuser encore plus le sujet.

Conseils pour une bonne utilisation de WordPress

En fait, WordPress a de chiant qu’il colle tous ses liens « internes » en absolus, contrairement à d’autres CMS qui sont bien plus neutres quant au domaine utilisé. C’est une façon de faire qui a ses forces et ses faiblesses, mais dans le cas d’un passage à tout HTTPS, c’est un peu pète-couilles.

Ce que je recommande du coup, c’est de faire en sorte qu’il utilise au maximum des liens relatifs. Je m’explique : lors de l’activation initiale, je rencontrais un problème avec certaines images. En cause, le fait que lorsqu’on les enregistre, il enregistre le lien complet absolu, avec http://blablabla, et pas seulement le chemin depuis la racine du site, ce qui permet de facilement basculer à la fois le domaine et le protocole.

Mais en fait, c’est simplement une feignantise, vous pouvez très bien, notamment dans les options de vos thèmes, vous amuser à modifier les chemins vers les images pour faire en sorte que toute trace du protocole et du domaine disparaissent. Pas de panique, le lien fonctionnera toujours, le navigateur partant du principe qu’il doit utiliser le même protocole et domaine que la page qui les appelle.

Quand ce n’est pas le cas (de plus en plus, les liens sont masqués dans les paramètres des thèmes), pensez à modifier la base de données (en suivant pourquoi pas les conseils de Korben, si vous ne savez pas le faire de tête :P). N’oubliez pas également tout ce que vous avez pu écrire à la main, et qui pourrait avoir été oublié, comme c’était le cas ici des boutons sociaux. J’ai aussi du modifier le bouton « Accueil », qui était fait « à la main », et qui pointait sur la version « en clair ». Et la remarque vaut aussi pour les liens vers d’autres articles du site, par défaut l’applet d’ajout de lien colle le lien complet.

Et donc oui, si vous utilisez Piwik, assurez-vous qu’il est aussi accessible en HTTPS, et faites en sorte que ce soit utilisé justement. Il vous posera bien moins de problèmes que WordPress, puisqu’il suffit juste de paramétrer le serveur Web, et si vous utilisez WP-Piwik comme moi, juste lui indiquer dans les paramètres d’utiliser strictement HTTPS :

La dernière ligne, regardez bien :)

La dernière ligne, regardez bien 🙂

Autre point à considérer : suite à une alerte sur Twitter de Tom23 qui m’annonçait que les nouveaux articles n’étaient pas publiés (alors que les anciens oui), j’ai investigué un peu, et j’ai fini par trouver : Microblog Poster, comme toute application devant avoir accès à votre compte Twitter, passe par une autorisation définie sur Twitter Apps. Et évidemment, le site renseigné était là encore « en clair ». C’est la raison pour laquelle les vieux articles continuaient d’être publiés et que les nouveaux étaient « rejetés », quand ils étaient créés depuis le back-office en HTTPS.

Et enfin, le cadeau bonux : dans Piwik, il ne faut pas oublier de déclarer la version HTTPS dans la configuration du site, sinon il n’enregistrera que les liens HTTP. Très con aussi à trouver ça…

Prochaine étape : l’automatisation

En effet, le but à terme de Let’s Encrypt est de proposer une automatisation poussée du renouvellement de ces certificats (pour rappel, ils ne sont valables que 90 jours). Ce n’est pas gagné, notamment dans le cadre d’ISPConfig, mais ça devrait malgré tout pouvoir se faire. Faut juste que je potasse la doc de l’outil justement, et voir comment je pourrait faire en sorte qu’il puisse facilement faire le travail sans couper Nginx, et aussi faire en sorte que le dossier .well-known ne soit pas interdit comme c’est le cas actuellement. Et dire que certains pensent qu’on peut se passer d’administrateurs système 😀

PS : si vous voyez encore des soucis, parce que j’ai pas revu tous les articles non plus, n’hésitez pas à me le dire, commentaires, mail, Twitter, vous savez où me joindre.

8 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
Tetsumaki
11/01/2016 23:08

Salut, à ce que je vois, 2016 est l’année du HTTPS.

Je te conseille l’outil d’Aeris qui permet d’aller un peu loin justement afin d’avoir quelque chose d’un peu plus strict en termes de sécurité :

https://tls.imirhil.fr/https/blog.seboss666.info
https://tls.imirhil.fr/https/analytics.seboss666.info

Tu peux au moins te passer de TLSv1, de 3DES, utiliser un certificat en 4096 bits et du DH 4096.

Si ça peut te faire gagner du temps voici ce que j’utilise :
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;

Pour ma part, j’utilise aussi nginx et malgré mes recherches, je n’ai pas réussi à mettre en place du ECDHE 571 bits.

Julien Doclot
Julien Doclot
15/01/2016 22:53
Répondre à  Seboss666

Rien de tel que de faire toute sa conf à la main et de ne pas devoir mettre un ISPConfig et compagnie 😉

Julien Doclot
Julien Doclot
16/01/2016 08:32
Répondre à  Seboss666

Il est très bien aussi dans le cas où tu as plein de sites à gérer. Après moi je ne l’ai pas mis sur mon serveur car pour 2,3 sites je ne trouve pas que ça vaut la peine 😉

fred
13/01/2016 08:54

Salut Seb,
tu pourrais en profiter pour être compatible http2 ?

iooner
iooner
16/01/2016 12:18

Un outil juste parfait pour faire les modifs en DB facilement et avoir une simulation avant. https://github.com/interconnectit/Search-Replace-DB