Let’s Encrypt, du SSL (vert !) gratuit pour tous

Ça y est !

Depuis le 3 décembre, le glas des prestataires de certificats SSL a sonné… Ou presque !
En effet, jusqu’à ce 3 décembre, avoir un beau certificat vert dans la barre d’adresse lorsque l’on affichait son site était forcément fait contre monnaie sonnante et trébuchante !
lets_encrypt

Aujourd’hui, la démocratisation du SSL est en marche,.. A quelques conditions…

Je ne vais pas parler technique (à venir), mais bien théorie.

Edward Snowden déclarait en juin 2013 qu’une réflexion sur la sécurité informatique était lancée, et le projet porté par l’Electronic Frontier Foundation en collaboration avec la fameuse Université du Michigan démarre. Ce projet sera rejoint par Mozilla qui alors ensemble créent « Let’s Encrypt », donc la naissance est officialisée le 18 novembre 2014.
lets-encrypt

Aujourd’hui, le projet est en beta publique et permet à chacun de générer des certificats gratuits X.509 pour le protocole cryptographique TLS.

Donc, la limite de ce système est la garantie financière que proposent les prestataires de certificats, qui est donc là inexistante,… Normal !

Par contre, pour le référencement, c’est le top ! Et si comme moi vous êtes à la recherche de performances, que vous voulez utiliser HTTP/2 ou autres TLS via Nginx, alors il ne faut plus hésiter… Foncez ! Les certificats sont reconnus par tous les navigateurs, sauf apparemment sur windows XP IE8 pour le simple motif que XP n’est plus mis à jour.

Je ferai un debrief sur mes futures installs un peu plus tard, le modus operandi d’installation étant très bien fait sur le site de Let’s Encrypt :
https://letsencrypt.readthedocs.org/en/latest/intro.html

A lire en français, un résumé via wikipédia :
https://fr.wikipedia.org/wiki/Let%27s_Encrypt

Quelques questions réponses résumant la situation :
Qui soutient le projet ?
Ce projet est gratuit, open source, et est soutenu par des organismes, fondations sociétés tels que Facebook (depuis le 3 décembre 2015), Mozilla, Akamai, Cisco, etc… Bref, des monstres du net…
LetsEncryptSponsors
Wilcard ?
– non, mais il suffit d’indiquer à la génération des certificats tous les domaines concernés
Mieux que StartSSL gratuit ?
– pas mieux sur la certification, mais en tout cas, possibilité de gérer les sous-domaines, les multi-domaines, etc… Gratuitement (mais sans garanties financières !)
Quid du renouvellement de certificat ?
– une génération automatique est possible pour le renouvellement (à voir, je testerai), « Let’s Encrypt » vous averti de l’expiration par mail (donné à la génération des clés)

lets-encrypt

Voilà, maintenant, je ne souhaite que voir votre joie à découvrir vos magnifiques A sur SSL Labs :letsencryptssllabsa

A plus !

bench Nginx, de 1.4.2 à 1.9.5, options http/2 thread aio et spdy

Depuis que j’utilise NginX, j’ai toujours gardé les binaires compilés de Nginx sur ma machine.

Aujourd’hui, je me fais un plaisir, reprendre chacun de ces binaires, et les tester sur mon portail phpmynewsletter, portail qui fonctionne avec du SSL, une HHVM avec un fallback en php-fpm. (Donc sur un serveur en production !)

Concernant http/2, je vous conseille l’excellente doc de Daniel Stenberg, ingénieur réseaux chez Mozilla : http://daniel.haxx.se/http2/http2-v1.8.pdf. (Autres lecures conseillées :
https://fr.wikipedia.org/wiki/SPDY
https://http2.github.io/)

Pour le protocole d’essai, je vais utiliser wrk, dépôt et explications sur Github dont l’installation est très simple, et que je préfère largement à ab de apache2-utils. J’utilise également un portail qui est réellement en production (au lieu d’utiliser un portail en localhost, ce qui explique des chiffres que l’on peut trouver bas, mais qui ont au moins le mérite de se rapprocher de ce que vous pourrez avoir, vous, en réel. Le matériel est un core i5, 16 go de Ram, et une partition sur un disque en raid mirroré, donc pas de raid 0. Enfin, le moteur PHP derrière tout ça est une HHVM).

Je détaillerai pour chaque test la config par le simple résultat de la commande « nginx -V », et chaque test sera déroulé 5 fois. Je ne posterai que le meilleur résultat de chaque bench.

Chaque wrk sera lancé selon la commande :

Qui signifie : 12 threads, 400 connexions ouvertes pendant 30 secondes.

Tout d’abord, on installe wrk, super simple, en root :
Sur Debian (moi 7,xx, noyau 2.6.xx) :

 

Juste pour info sur CentOS / RedHat et Defora :

 

Les configurations de chacun des Nginx testés :

Nginx 1.4.2 :

 

Nginx 1.6.0 :

 

Nginx 1.9.4 avec spdy, ssl 1.0.2d (dernière version de Nginx disponible avec spdy, à partir de Nginx 1.9.5, spdy est replacé par http/2) :

 

Nginx 1.9.5 sans thread aio, http/2, ssl 1.0.1e :

 

Nginx 1.9.5 avec thread aio, avec http/2, ssl 1.0.1e :

 

Nginx 1.9.5 avec thread aio, avec http/2, ssl 1.0.2d :

 

 

Les résultats :

Nginx 1.4.2 sans spdy, ssl 1.0.1e :

A noter, 51 connexions en Time Out…

Nginx 1.6.0 sans spdy, ssl 1.0.1e

Ouch !!! 1400 requêtes exécutées en moins et 80 timeout en plus (je vais avoir un oeil qui va tomber…)

Je n’ai pas utilisé la V1.7.1, qui a pourtant bonne réputation, d’autres sujets étaient sur le feu (désolé, on priorise parfois !), donc je suis passé à la v1.9.3…

Nginx 1.9.3 sans spdy, ssl 1.0.1e :

Je respire ! Nombre de requêtes encore en baisse à 27700, mais par contre une meilleure gestion des timeout (qui étaient dues à Nginx, les modules php ayant été pour l’occasion poussés à 300 secondes de timeout). Donc un taux de 100% de réponses assurées, et quand on est webmaster, administrateur, ça, c’est VRAIMENT important ! Sic !!!

Nginx 1.9.4 avec spdy, ssl 1.0.2d :

On repasse au dessus des 30.000 requêtes exécutées pour arriver à 33.000, 1110 requêtes secondes… Bien, suis content !

On passe aux choses sérieuses. La version 1.9.5 de Nginx abandonne le mode spdy au profit de 2 nouvelles choses importantes : http/2 et thread_pool (attention, c’est un module encore expérimental qui reste à utiliser avec modération… Je laisserai un mot sur quelques bugs rencontrés à ce sujet).

Nginx 1.9.5 sans http/2, sans thread_pool, ssl 1.0.1e :

De bonnes performances, on est encore au dessus de 30.000 requêtes, mais plus de spdy, et toujours pas de http/2 activé, ni thread_pool… Voyons la suite, activons http/2…

Nginx 1.9.5 avec http/2 activé, sans thread_pool, ssl 1.0.1e :

A noter pour mieux comprendre : je rappelle que le serveur est un serveur de production, c’est à dire qu’il tourne en conditions réelles, avec des vrais sites dessus (dont une grosse base de données cinéma), que le protocole http/2 est une fonctionnalité offerte par certains navigateurs : (source : https://www.keycdn.com/blog/keycdn-http2-support/ du 6 octobre 2015)
caniuse-http2-browser-supportJe rappelle aussi que Nginx 1.9.5 avec le module http/2 est censé être compilé avec openssl 1.0.2, alors que ce dernier exemple de bench est avec un openssl en 1.0.1 (des conséquences ?).
J’ai également constaté un bug… Lors de mon authentification sur le forum de Phpmynewsletter.com, je suis sans cesse envoyé sur une page 403, et une erreur de connexion, sur Chrome Version 45.0.2454.101 m, alors que j’ai un résultat tout à fait correct sur Firefox 41.0.1. Un autre bug : des soucis avec des uploads de fichiers volumineux (dossier de presse cinéma) sur le portail cinéma… Pas top ça…
Et en conclusion : que le protocole http/2 ne peut donc pas donner de résulats probants avec un appel via wrk (ou curl, wget, ab ou quoi que ce soit !)

Enfin bon, donc l’avant dernier test, avec le pool thread_aio… :

On est pas mal… Plus de 31.000 requêtes, pas de timeout… Je veux voir la différence avec le dernier test…

Nginx 1.9.5 avec thread aio, avec http/2, ssl 1.0.2d :

Conclusion…

Que dire ?....

Que penser de tout cela ?…..

Nginx évolue, gère mieux les time out et sert mieux donc toutes les connexions. Le serveur utilisé n’est pas neutre, d’autres process tournent ! Il ne fallait non plus s’attendre à des chiffres de folie, je le savais. Ce que je crois, c’est que dans son ensemble le serveur physique et la gestion des processus sont arrivés aux limites de ce qu’ils peuvent donner à Nginx.

La vue usager est par contre plus intéressante : les pages s’affichent quasi instantanément, plus d’attente de chargement qui d’un objet qui attend sur le précédent qui attend sur le précédent, etc… Tout s’affiche d’un bloc.

Oui, mais alors… Les GTMetrix et autres sites de tests de chargement des pages ?
Et bien ils ne sont pas encore près aux tests http/2, ils retombent donc dans l’usage d’un navigateur commun, ordinaire,…ancien !

La seule chose qui compte, ne l’oubliez jamais : c’est l’usage et le confort de vos usagers, visteurs, membres, etc… Sur votre ou vos sites hébergés ainsi.

On aurait pu pousser le test avec usage différencié de php5-fpm et hhvm, ajouter ou pas du memcache et autres modules de tunning de vos php. Je ne l’ai pas fait, c’est totalement volontaire !

Je suis très content des résultats, tout simplement !

Allez, @+

hhvm avec un fallback php-fpm

Bonjour !

Un petit billet en passant.
Depuis quelques jours j’utilise avec le plus grand bonheur hhvm (Hip Hop un petit coup d’Yop Virtual Machine), la machine virtuelle développée par Facebook et rendue Open Source depuis quelques temps déjà (et j’aime l’open source !)

Je l’ai installée sur Nginx, faudrait que j’y consacre également un petit billet.

Aujourd’hui, c’est juste un bout de code, une explication, une possibilité de basculer automatiquement en mode php5-fpm si jamais hhvm venait à s’arrêter…

En bref, si jamais mon NginX renvoie une erreur 502 à cause d’une hhvm indisponible, alors on bascule automatiquement sur php-fpm.

Les 2 services sont considérés comme lancés sur la machine.

J’avais un bout de code Nginx relatif au paragraphe « location » :

C’est la base de l’intégration de hhvm dans NginX.

On change ce bout de code en intégrant un fallback si on a du 502, et dans le paragraphe « server » on ajoute un « location » de connexion au php-fpm :

Voilà, c’est tout bête !

Pour essayer que ça fonctionne bien, arrêtez hhvm

et accédez à votre page, hip hop, ça marche !

Bon fallbacks à vous

Quand les sessions de php.ini ne sont pas potes avec hhvm (session.save_path qui part en sucette !)

hhvm-logo1

Je viens d’installer une hhvm sur mon petit serveur qui me va bien, et après avoir customisé les paramètres du fichier php.ini (paramètres  php de base de la Hip Hop Virtual Machine), je constate que la modification du répertoire des sessions n’a pas été prise en compte !

(Peu importe l’avis des puristes, seul compte le résultat, j’ai déplacé mon répertoire de sessions dans /home qui dispose d’une trèèèèèèès grande place, la racine ayant été taillée pour ne pas risque de débordement…)

Donc, le bug connu de hhvm dans sa config, est de garder le répertoire initial :

et que hhvm refuse de prendre en compte mon

Ce n’est pas grave, je ne vais pas aller batailler avec Facebook et ses développeurs qui nous font déjà la grâce bienveillante de nous mettre à disposition ce code. Je choisis donc la solution la plus simple qui existe : créer un lien symbolique !

Je vais faire un petit tour dans mon nouveau répertoire de stockage des sessions et « ls -l » :

Bref, c’est ok !
applause-sign

L’avantage est qu’il n’y a rien à modifier pour cette directive qui reste tout simplement :

Sinon, je pense que je ferai un petit topo rapide sur cette petite merveille… Enfin, moi j’adore !

Pour information, PHP est en version 5.6, derrière un petit Nginx, et je vais me lancer dans quelques benchs, histoire de vérifier les qualités de tout ce schmilblic !

schmilblic

 

@+ !

 

 

le bug bash CVE-2014-6271, résolution…

Le bug bash, c’est quoi ?
slide
C’est une faille (connue depuis longtemps, si si !!!) qui affecte les systèmes Linux, Unix, et Mac OS X, et qui est une sérieuse vulnérabilité qui permet à tout esprit malveillant (le monde de l’informatique est cruel grrr grrr) de prendre le contrôle total d’une machine, donc d’en effacer le contenu (ça, c’est dommage), ou d’y installer des logiciels-espions (en même temps s’il n’y a plus rien, y’a aucun intérêt !) Lire la suite

ngx_pagespeed_cache… Faire encore mieux !

Après avoir mis en place le mode pagespeed (voir le billet précédent : https://blog.aulica-conseil.com/index.php/installation-full-de-nginx-1-4-2-ngx_pagespeed-inside/) (et j’espère que comme moi vous apprécierez ce mode et ce qu’il apporte), on va voir que l’on peut encore améliorer les performances, en plaçant le cache en RAM !

C’est très simple, et ça se déroulera en 3 étapes :

  • Création du répertoire en RAM
  • Configuration de Nginx.conf
  • Reload du serveur

Lire la suite

installation full de nginx 1.4.2 ngx_pagespeed inside

Allez vite fait, comment installer Nginx, version 1.4.2, version full, avec plus particulièrement le mod ngx_pagespeed :

On va commencer par résoudre en préalable toutes les dépendances, connecté root :

Téléchargement de pagespeed et psol :

 Téléchargement et préparation de nginx :

J’en profite pour installer le dernier module rtmp :
(https://github.com/arut/nginx-rtmp-module et je vous en parlerai plus tard…)

Et enfin on compile, voici ma liste d’option :

Je fais vite fais une sauvegarde du binaire antérieur :

Et je peux lancer la compilation :

Une fois terminée, je copie le binaire obtenu :

Dans chaque bloc « server » de /etc/nginx/nginx.conf où l’on veut activer le mode pagespeed, on ajoute bien :

Pour vérifier votre installation (présence de la ligne X-Page-Speed)

On n’oublie pas que toute la doc se trouve là :
https://developers.google.com/speed/pagespeed/module/using
et que chaque configuration est à tester !

NB : pour booster encore un peu votre pagespeed, je vous invite à voir ce billet :
https://blog.aulica-conseil.com/index.php/ngx_pagespeed_cache-faire-encore-mieux/

Installer Sympa, Mailing list server sur Nginx, c’est possible !

Sympa est l’outil idéal pour gérer des mailings list, mais la documentation pour une installation sur Nginx est encore assez légère.
J’héberge un client sur un dédié Debian et serveur web Nginx.
Je lui installe donc ce « Sympa » sur mon nginx.
On va faire une installation standard :

Je ne rentre pas dans le détail de la configuration de Sympa, ce n’est pas l’objectif dans ce billet, retour à Nginx :
Dans notre nginx.conf, on va créer un serveur (sous-domaine) :

Dans la doc Sympa, on vous dira de passer par un socket :

Le hic c’est que vous aurez souvent un joli « 403 » affiché à ‘écran, en fonction des droits que vous aurez accordé dans votre système.
Oui passer par le port 8999 est moins rapide, mais nous sommes ici dans une configuration mode « user standalone » !
Si vous développez un portail complet en perl, alors oui vous aurez à passer par les sockets. Aujourd’hui, ce n’est pas le cas !

Si vous n’avez de wrapper perl installé :

Ajouter un script de démarrage /etc/init.d/perl-fcgi :

et enfin :

Recharger Nginx, et accéder à votre liste : http://lists.votredomaine.com