Archives par étiquette : Nginx

Poodle et SHA1

Juste un article lié à l’actualité (Poodle &co) et sur les mesures à prendre sur nos serveurs SSL/TLS.

SHA-1 : datant de 1996, encore considéré comme fiable, cette fonction de hash, largement utilisée pour signer des certificats, et plein d’autres choses, va être dépréciée. Google et Microsoft ont en effet annoncé qu’ils allaient progressivement refuser les certificats signés avec SHA-1 dans leurs navigateurs respectifs et recommandent d’utiliser SHA256.

=>c’est une bonne nouvelle pour notre sécurité, non pas parce que SHA256 est plus fiable que SHA-1, mais parce que ça va obliger de nombreuses autorités de certifications à renouveler leurs certificats d’autorités et les administrateurs à faire de même pour leurs certificats serveurs.

Je vous laisse chercher pourquoi ce surcroit de travail devrait être une bonne chose …

Poodle : datant de 1996 lui aussi, SSLv3 vient probablement de casser sa pipe, une faille protocolaire permet de déchiffrer tout ou partie d’une connexion HTTPS. Comme la faille concerne le protocole et pas une implémentation, la correction est assez simple, il suffit de désactiver la prise en charge de SSLv3.

C’est une très bonne nouvelle, on va enfin pouvoir se débarrasser d’Internet Explorer 6 (ce dernier ne prend pas en charge le TLS).

Vivement qu’on trouve une faille dans TLS1 afin de faire sauter les versions 7 et 8, voir même 9 et 10 (puisque que TLS 1.1 et 1.2 y sont désactivés par défaut)

Certificats en SHA256

Google et Microsoft ont annoncé qu’ils allaient progressivement refuser les certificats signés avec SHA1 dans leurs navigateurs respectifs et recommandent d’utiliser SHA256.

Les certificats déjà publiés ne devraient pour la plupart pas être concernés, mais si vous avez un certificat à générer à partir de maintenant, il vaut mieux directement le signer en SHA256.

Vérifiez bien que votre autorité de certification a fait de même avec ses chaines de certifications!

Par défaut, OpenSSL utilise SHA-1 pour générer une demande de certificat (CSR), pour utiliser SHA256 il suffit d’ajouter default_md = sha256 dans la section appropriée du fichier de configuration ([ ca ] et/ou [ req ] selon l’usage), ou d’ajouter -sha256 dans la ligne de commande.

Poodle

Pas besoin de détailler, il est temps de débrancher les ancêtres.

La suite indique comment faire pour quelques logiciels serveur de qualité :

Nginx

Configuration avec une bonne compatibilité :

Le dernier cipher permet la compatibilité avec IE 8 sur XP, n’hésitez pas à le supprimer.

Pour plus de sécurité on peut générer une clef de session plus forte :

On l’utilise avec la directive :

Si le site est uniquement en HTTPS, on peut l’indiquer aux navigateurs compatibles via l’entête HSTS , ainsi ils ne tenteront plus (pendant la durée indiquée) d’accéder à votre site en HTTP :

Apache2

Configuration avec une bonne compatibilité :

Pour l’HSTS :

Postfix

Dovecot

Nginx – mise en cache

Le billet suivant présente un manière simple et efficace d’optimiser un site dynamique avec la mise en cache de Nginx. Pour l’exemple il s’agira d’un site sous WordPress.

Il n’y a rien de neuf ici, c’est juste une reprise des informations que vous pouvez trouver un peu partout.

Par site dynamique, j’entends un site dont les pages sont constituées dynamiquement à partir de données en base et de scripts exécutés coté serveur (ici du php). C’est typiquement le fonctionnement de WordPress.

A l’opposé, un site statique est constitués d’un ensemble de fichiers qui sont transmis directement aux utilisateurs, comme des images ou des fichiers html/css/js/…

Comme c’est la spécialité de Nginx, servir des fichiers statiques, nous allons voir comment « transformer » notre site dynamique en site statique.
Si vous n’utilisez pas Nginx, cet article perd de son intérêt.

Le principe est simple et bien connu, on met en cache les pages générées dynamiquement.

Voici les directives importantes :

La zone de cache :

  • /run/shm est une zone montée en mémoire (ramfs) afin de limiter les accès disques
  • levels : c’est la structure des dossiers qui sera utilisée pour le cache
  • keys_zone : le nom de l’espace de cache et sa taille maximale
  • inactive : la durée de rétention d’un objet non utilisé, ici 60 minutes

La méthode de mise en cache :

Les directives suivantes permettent d’activer ou de désactiver la mise en cache :

Un exemple d’appel au cache :

La directive suivante permet de purger tout ou partie du cache sous certaines conditions :

nb : le module fastcgi_cache_purge n’est pas intégré dans la version officielle de nginx (au moins en 1.9.x), mais il l’est dans celle fourni dans par Debian ou Dotdeb (1.8.x).

Pour WordPress, vous trouverez un plugin permettant de purger intelligemment le cache en cas de création/modification du contenu : Nginx Helper

Ensuite il faut jouer avec les « location » pour mettre ou non les pages en cache.

A titre d’exemple, voici un exemple de configuration pour WordPress :

Vous pouvez bien entendu utiliser cette méthode pour tout type de site, pas seulement WordPress.

Source : rtCamp

About – ce site

Juste une petite description de l’architecture de ce site.

Pas de détails, rien de très compliqué non plus.

Ce site est installé comme suit :

  • Nginx avec un cache fastcgi
  • php5-fpm avec plusieurs pool
  • et bien sur WordPress (sans aucune extension d’optimisation)

Sa base de données est :

  • MariaDB

Le tout est sur une petite Dedibox qui fait plein d’autres trucs.