16 janv. 2017

dehydrated, un client alternatif pour Let's Encrypt

Après quelques galères avec Certbot, j'ai découvert dehydrated, un client pour Let's Encrypt écrit en Bash.

Depuis plusieurs semaines, voire mois, le client officiel de l'autorité de certification Let's Encrypt, Certbot, ne fonctionne plus sous NetBSD. Cela semble venir du fait que Python, dont dépend Certbot, est compilé avec PaX MPROTECT. C'est tout du moins ce qu'indique ce rapport de bug.

N'ayant ni le temps ni les compétences pour voir ce qui bloque exactement du côté de Certbot, j'ai fait ce que pas mal d'autres ont fait : j'ai recherché une alternative. La première alternative qui a attiré mon attention est acme-client, en version portable, d'ailleurs disponible au moment où j'écris ces lignes dans pkgsrc-wip. Mais en fait celui-ci ne semble pas fonctionner sous NetBSD, me hurlant des histoires de droits et de suid bizarres.

J'ai ensuite jeté mon dévolu sur dehydrated, un client écrit en Bash. Celui-ci a l'avantage non-négligeable de fonctionner, contrairement au précédent. Je me suis donc lancé dans son empaquetage (wip/dehydrated au moment où j'écris ces lignes, mais j'espère l'importer dans pkgrsc-current dès que possible). Dehydrated est assez pratique à utiliser, il nécessite des dépendances assez classiques pour un script shell (sed, awk, curl), en plus d'OpenSSL. Bien qu'il dispose de fichiers de configuration, de nombreuses options peuvent être spécifiées sur la ligne de commandes. Dehydrated prévoit aussi des scripts "hook" pour pouvoir déclencher d'autres actions avant et après le renouvellement d'un certificat par exemple.

Le paquet est globalement fonctionnel sous NetBSD, le seul prérequis avant de se lancer dans l'édition des fichiers de configuration est d'avoir une configuration OpenSSL existante (ce qui se fait rapidement, en copiant simplement le fichier d'exemple fourni dans /usr/share/examples/openssl/), et de savoir dans quel répertoire le challenge ACME sera déposé. J'espère d'ici là avoir amélioré la prise en compte d'OpenSSL d'ailleurs (utilisation de celui de pkgsrc par exemple). Idéalement, ce serait assez cool que dehydrated puisse utiliser LibreSSL.

Il existe d'autres clients alternatifs que je n'ai pas essayés, comme getssl, mais lequel est votre préféré et pourquoi ? Le formulaire de commentaire n'attend que votre réponse !

2 janv. 2017

Vous naviguez toujours sur un site HTTPS

Bon d'accord, je suis over-méga-à la bourre sur celui-ci : en gros il y a quelques mois, après avoir passé ce blog en HTTPS, je me suis rendu compte que certains couples OS/navigateurs ne fonctionnaient plus, par exemple certaines version d'Internet Explorer sous Windows 7. J'imagine que cela ne doit pas être beaucoup en terme de proportion, mais je me suis quand même dit que c'était vachement dommage. Je suis donc retourné voir générateur de configuration SSL proposé par Mozilla, et j'ai sélectionné un choix "intermédiaire".

Première conséquence : une augmentation des clients compatibles, ça tombe bien, c'est le but ! Maintenant, pour profiter de ce blog, il suffit de disposer d'au minimum Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3 ou bien Java 7.

Deuxième conséquence : une baisse de la ^W ^W ^W ^W et bien non, même pas ! J'ai toujours une note de A+ au test SSL Labs ! Dans ces conditions, pourquoi se priver ? :)

10 fév. 2016

Vous naviguez sur un site web HTTPS

Depuis hier, ce blog est dorénavant accessible uniquement en HTTPS. Pour l'exercice, j'ai fait en sorte que celui-ci dispose d'une note A+ au test SSL Labs de chez Qualys, en me basant sur une configuration proposée par le générateur de configuration SSL proposé par Mozilla. J'ai choisi une configuration "moderne". Côté certificat, j'ai choisi d'utiliser Let's Encrypt.

On peut très vite noter quelques impacts :

  • d'abord, la liste des plus vieux clients compatibles : Firefox 27, Chrome 22, IE 11, Opera 14, Safari 7, Android 4.4, Java 8 ;
  • ensuite, une légère augmentation du temps de chargement du site, qui peut s'avérer plus que significative lors d'une redirection HTTP vers HTTPS.

Concernant les clients compatibles, je ne m'en fais pas trop, ce blog n'est pas très visité, et je doute que beaucoup de personnes visitent ce site avec Internet Explorer. Je suis un peu plus embêté pour Android, du fait d'une fragmentation assez importante. Du côté du temps de chargement, de nouvelles mesures réalisées un peu plus tard sont encourageantes, j'imagine donc que les divers caches possibles feront toujours leur travail et que la navigation sera confortable.

Propulsé par Dotclear