Utilisation d'OpenSSL sur Zeste de Savoir

Bonjour,

suite à la demande de firm1, je me permets de faire un récapitulatif de l'utilisation d'OpenSSL sur Zeste de Savoir.

Chiffrement et certificats

J'ai obtenu le certificat de www.zestedesavoir.com grâce au site http://startssl.com/ ; nous sommes donc certifiés par StarCom jusqu'au 2 Juillet 2015, après quoi il faudra très certainement renouveler le certificat.

En ce qui concerne la pré-production (preprod.zestedesavoir.com) j'ai fait une boulette (eh oui) et il est impossible de révoquer le certificat pour le renouveler. J'ai perdu la clef privée comme une andouille. On a alors deux choix si on souhaite avoir une pré-prod avec SSL :

• On autosigne notre certificat (on aura alors un simple avertissement) ;
• On trouve une autre autorité de certification qui accepte de délivrer des certificats gratuits (de préférence)

Les clefs sont chiffrées en RSA 2048 bits.

Sécurité

Grâce à Saucisson j'ai découvert deux choses intéressantes récemment.

La première, c'est que nous étions apparemment "vulnérables" face à la CVE-2014-0224. Une mise à jour de la version d'OpenSSL semble avoir corrigé le problème.

La seconde, c'est qu'il est possible de connaître le niveau de sécurité par SSL grâce à ce site web : https://www.ssllabs.com/ssltest/analyze.html?d=zestedesavoir.com.

Il est possible d'appliquer des configurations à nginx pour renforcer la sécurité du serveur. J'éditerai la liste des paramètres que j'ai appliqués pour le serveur de production (toujours sous les bons conseils de Saucisson) :

1

server_tokens off;

Cette directive permet de masquer la version de nginx dans les réponses HTTP du serveur. Cela fait davantage office de sécurité par l'obscurité, certes, mais ça limitera sans doute les attaques automatiques lancées par des bots qui vérifient la version de nginx et qui attaquent en conséquence.

Documentations, manuels, etc.

• Configurer HTTPS sur nginx : http://nginx.org/en/docs/http/configuring_https_servers.html
• Créer un certificat auto-signé : http://www.akadia.com/services/ssh_test_certificate.html

Si vous pouvez vous en passer, essayez de le faire, c'est hyper casse-couille. C'est le cas dans ma boîte et ça finit par nous rendre barge.

Oui dans le browser on a un simple avertissement sur fond jaune pisse dans Chrome, ça va on a vu pire.

Le problème c'est quand les applications tierces rentrent dans la danse.

Je ne sais pas ce que vous envsagez, mais en admettant que vous ayez des APIs et que des développeurs bien intentionnés développent des softs annexes (app mobile, extension, client lourd, ou même des petites routines de tests automatisés), bref des trucs qui auront besoin de se connecter programmatiquement (ou pas, dans le cas d'une app) sur la preprod parce que les gens sont consciencieux et qu'ils veulent vérifier que les dernières modifs avant qu'elles partent en prod ne cassent pas leur programme tiers.

Dans certains cas, ils vont devoir faire des pieds et des mains pour s'y connecter à cause du certificat auto-signé. C'est le cas des programmes Java, ou dérivés (Groovy, Scala probablement), ou il faut aller se démerder avec le TrustedStore, c'est pénible à souhait mais ça se trouve sur le net et on finit par s'en sortir.

Dans d'autres cas, ils ne pourront pas tester des features de leur programme. Je prends un exemple simple :

Admettons que Eskimon n'a rien à faire et qu'il développe une app iPhone qui lit les tutoriels. Il devrait pouvoir se connecter aux APIs si elles existent pour récupérer la liste des tutos, un tuto au format markdown, etc. Ca devrait pas poser de soucis.

A la fin de la page dans l'app y'a un lien "posez une question parce que vous n'avez pas compris" qui ouvre le child browser (le Safari embarqué natif machin des iDevices). Evidemment, il ouvre en https (on sait jamais, peut-être l'utilisateur est loggé dans l'app ou quoi que ce soit j'en sais rien).

Pour le child browser : certificat auto-signé => j'ouvre pas, point final.

Résultat : Eskimon va devoir tester sa feature en http, avec un comportement différent en préprod et en prod. Et ça pue un peu.

Je le vis au quotidien, je vous assure que c'est casse-pieds. Maintenant ça reste marginal, donc à vous de trancher en connaissance de cause.

NB : y'a aussi des cas un peu pénibles où tu redémarres le navigateur, la page est rendue sans te réafficher l'avertissement de sécurité (pourquoi j'en sais rien) mais dès que tu vas chercher une image "à la volée" (en AJAX j'entends) la requête échoue. Faut ouvrir l'image dans un nouvel onglet (et accepter l'avertissement) pour que ça fonctionne à nouveau. C'est pas la mort, mais pour peu que tu n'y penses pas t'as perdu 20 minutes pour que dalle.

Merci pour toutes ces précisions, Javier.

Pour refaire les choses proprement, j'ai fait, cette fois, une demande à GlobalSign pour des certificats gratuits.

Si vous connaissez d'autres autorités, je suis preneur…

Double post.

Que se passe-t-il si tu désactives l'OCSP dans Firefox ?

Excellente initiative, et merci pour les MAJ de sécurité

Si ce n'est déjà fait, je propose que tu envoies les clés privés au bureau de l'association (ou au moins au président), qui sont gardiens de toutes les clefs du site si j'ai bien compris.

Merci Ge0 pour les précisions.

Comme l'a dit Javier, il faudrait vraiment que la preprod ait une certficat comme la prod. Il n'ya pas moyen de retrouver la clé de la pré-prod quelque part ?

Autre chose aussi, dès qu'on passe en public officiel, c'est à dire à partir du 21 juillet, je pense que toute manipulation sur la prod (nginx, etc.) passera d'abord par un test en préprod, du coup si la préprod n'est pas signée, ça va être difficile d'être iso-prod.

Non. C'est sur ce coup-là que j'ai merdé.

Par contre, tu peux renommer "preprod" en autre chose et là je peux générer un certificat pour ce sous-domaine sans faire de gaffe cette fois-ci.

J'en prends bonne note.

Edit : j'enverrai les clefs, SpaceFox.

Je viens présenter quelques petits morceaux de configuration que j'ai l'habitude d'utiliser. Alors attention par contre, je suis très excluant (les utilisateurs de XP et/ou IE6 vont avoir du mal à utiliser le TLS avec ceci).

Dans un premier temps, je désactive SSL, pour ne garder que TLS. (Adieu XP)

1

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Ensuite j'utilise une liste de ciphers plutot restrictive et sécurisée. J'enlève tous les algo de chiffrements qui utilisent des clef de 128 bits (c'est bourrin, j'aime ça). On perd le support de JAVA ou des choses comme ça.

1
2

ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !AES128 !CAMELLIA128 !SEED !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

On notera aussi que j'ai désactivé RC4 il y a pas longtemps. Effectivement, il n'y a pas très longtemps, on conseillait de garder RC4 pour atténuer les attaques de type BEAST. Simplement, avec le temps on se rend compte que RC4 est encore moins secure que ce qu'on pensait. De plus BEAST est une attaque coté client, et la majorité des clients modernes ont des contre-mesures.

Ensuite, pour économiser en ressource, j'utilise un petit cache :

1
2

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Et enfin j'active OCSP. Pour se faire on a besoin de donner la chaine complète de certification. Dans le cas StartCom, ça veut dire le certificat du site, l'intermédaire, enfin le certificat racine. Normalement tu n'es pas obligé de mettre le certificat racine, mais une RFC le conseille, alors je le mets.

1

cat toncertificat lecertCAinterm lecertCA > cert-bundle.pem

Et on modifie :

1

ssl_certificate /chemin/vers/cert-bundle.pem

Et on ajoute :

1
2
3
4

ssl_stapling on;
ssl_stapling_verify on;
resolver_timeout 5s;
resolver <adresse ip de tes serveurs dns>;

En bonus, quand j'ai des certificats signés, j'active souvent le STS (Strict Transport Security) :

1

add_header Strict-Transport-Security "max-age=31536000";

Normalement, à la fin, ça donne ça.

Merci de l'info. Pour ceux qui veulent s'en convaincre :

1
2
3
4

SSLServerSocketFactory factory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
for (String cipher : factory.getSupportedCipherSuites()){
  System.out.println(cipher + " ; length="+Cipher.getMaxAllowedKeyLength(cipher));
}

Je sais pas ce que vous en pensez, ça ferme quelques portes à des clients tiers comme ceux dont je parlais un peu plus haut.

Pour information, il suffit de supprimer le point d'exclamation devant AES128, pour que JAVA fonctionne très bien (et Android 2.3.7 que j'avais oublié de préciser). Dans le même genre CAMELLIA128 et SEED sont aussi simplement désactivés comme ils sont sur 128 bits. Il va de soit, qu'on peut les activer aussi.

Hello, petit récapitulatif de ce qui a été fait et de ce qu'il reste à faire en ce qui concerne la certification.

Pour rappel, je me suis planté sur l'acquisition d'un certificat pour la preprod. J'ai perdu la clef privée et impossible de regénérer un nouveau certificat sur http://startssl.com/.

De ce fait, j'ai fait une demande à http://globalsign.com/ et celle-ci date de six jours.

DEUX alternatives s'offrent à nous :

• on attend la réponse de globalsign. Elle ne devrait normalement pas tarder et devrait nous offrir au moins un certificat pour la prod. Sauf que j'ignore si on aura accès à un second certificat pour la preprod.
• on renomme la preprod et on génère un nouveau certif. Et en ce qui concerne ce détail, j'ignore s'il faut en parler en privé ou ici.

Au vu du temps restant et des incertitudes, je penche pour la seconde solution. Qu'en pense le DTC ? Les autres ?

C'est bien de s'y pencher dès le début, mais attendre quelques jours que les certifs arrivent et aviser à ce moment là est tout à fait envisageable. Ne pêchons pas par excès d'impatience : ce ne sont pas quelques semaines sans https qui nous feront perdre des visiteurs ou des contributeurs.

D'autant qu'actuellement ce n'est pas actif que sur la préprod

En fait je demandais ça car firm1 voulait une preprod iso-fonctionnelle. Mais si on peut attendre c'est tant mieux !

Je ne crois pas que la mise en place d'SSL/TLS soit un point vraiment bloquant ou urgent, perso.

Hmmm … pas bloquant mais il faut bien être conscient des conséquences :

• une ébauche d'API ne pourra pas être testée en préprod car nécessitant du SSL
• si jamais on doit faire une correction ssl en prod et que la préprod n'est pas active, il faudrait couper la prod pour une durée indéterminée (dépendant des compétences de l'admin sys).
• j'en oublis

Donc si on est pret à s'engager dans ce sens, allons y, mais au moins au sait à quoi s'attendre.

Ouais enfin c'est pas le genre de truc qui va se présenter avant au moins plusieurs semaines : regarde la milestone V1.

Quelques précisions sur le support de SSL pour zds

Certaines parties du site n'étant pas transmises via ssl (les avatars par exemple) ne serait-il pas possible d'utiliser un proxy ssl (tel que camo par exemple) afin d'envoyer toutes les images (même distantes) via ssl ?

Honnêtement, je ne vois pas l'intérêt de sortir ce genre d'artillerie lourde sur un site tel que Zeste de Savoir.

Petit Up.

Je vais vous replacer dans le contexte avec ce message :

GlobalSign ne nous ont jamais répondu, peut-être parce que nous sommes un projet francophone… Je ne les ai pas relancés, cela dit.

En ce qui concerne ce problème de preprod qui ne possède pas de certificat signé par une autorité de certification de confiance (en fait, si, elle en possède un, mais j'ai perdu la clef de la preprod…), je ne peux pas faire de révocation de certificat comme ça.

Avec firm1, nous avons donc pensé à renommer le sous-domaine de la pré-prod (preprod.zestedesavoir.com) en beta (beta.zestedesavoir.com) et de générer un certificat pour ce nom de domaine (sans que je ne me chie dessus avec cette histoire de clef privée perdue, cette fois).

Cela nous permettra d'avoir une preprod iso-fonctionnelle sur le plan chiffrement / authentification / confiance, et d'éviter de se manger des messages type "Attention, aucune autorité ne peut vérifier le certificat de la preprod !".

J'aimerais recueillir les avis / l'aval des personnes concernées sur ce topic, si possible. Ou que firm1 vienne confirmer mes propos.

Merci à vous !

Moi cela ne me dérange pas si l'on renomme la preprod en beta car ça garde son sens. Par contre, une petite redirection preprod –> beta pour ceux qui n'ont pas l'information serait cool !