Ça y est, je suis full HTTPS (et autres conseils relatifs)
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 :
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) :
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 :
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.
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.
Merci, j’y jetterais un oeil. Comme j’ai dit, je reste prudent pour l’instant sur les modifications d’nginx hors ISPConfig, donc je reste en phase d’observation. Quand j’aurai une meilleure assurance que ça pète pas au premier clic venu, je vais améliorer les choses (y’a aucun cipher de prédéfini, et j’ai bien vu par contre explicitement les trois versions de TLS).
Ceci dit, à moyen terme, le blog sera plus autonome, sur une plateforme plus « joueuse », donc là, ça sera la fête 🙂
Rien de tel que de faire toute sa conf à la main et de ne pas devoir mettre un ISPConfig et compagnie 😉
Attention : ISPConfig peut être vraiment utile si on veut pas passer son temps justement à mettre les mains dans le cambouis. Il faut par contre s’assurer justement qu’on n’aura pas à le faire. Ceci dit, la configuration SSL dans ISPConfig c’est une horreur sans nom. Je comprend pas qu’on puisse pas simplement uploader ses fichiers, là, on doit copier/coller le contenu des différents composants (certif/clé/csr). C’est super crade.
Au final, j’ai généré une conf bidon en auto-signé et écrasé les fichiers générés. Tu comprend mieux maintenant la période d’osbervation ? 😀
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 😉
Salut Seb,
tu pourrais en profiter pour être compatible http2 ?
Ben ça viendra plus tard, manifestement j’ai un ou deux trucs qui coincent sans que je comprenne pourquoi (genre ce que m’a remonté Stan sur Twitter). Ca serait pas idiot de les régler avant. Faut que je regarde si ça le fait sur l’environnement de dev (qui n’est pas iso d’ailleurs, faudrait que je me colle à installer PHP 7). Et puis j’ai un changement de thème dans les cartons aussi, bref, comme d’hab, comme le disait le Joker dans le batman de Burton : « Tellement à faire, et si peu de temps ».
Un outil juste parfait pour faire les modifs en DB facilement et avoir une simulation avant. https://github.com/interconnectit/Search-Replace-DB