Utilisation d'OpenSSL sur Zeste de Savoir

Sujet récapitulatif

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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.

+2 -0
  • On autosigne notre certificat (on aura alors un simple avertissement) ;

Ge0

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.

Édité par Javier

Happiness is a warm puppy

+2 -0
Auteur du sujet

Double post.

@Ge0 problème de certificat aussi sur firefox : "Le certificat n'est pas sûr car aucune chaîne d'émetteurs de confiance n'est fournie. "

Tick

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

+0 -0
Staff

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.

Auteur du sujet

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 ?

firm1

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.

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.

firm1

J'en prends bonne note.

Edit : j'enverrai les clefs, SpaceFox.

Édité par anonyme

+0 -0

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.

+4 -0

On perd le support de JAVA ou des choses comme ça.

Saucisson

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));
}

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ; length=128

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ; length=128

TLS_RSA_WITH_AES_128_CBC_SHA256 ; length=128

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 ; length=128

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 ; length=128

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 ; length=128

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 ; length=128

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ; length=128

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ; length=128

TLS_RSA_WITH_AES_128_CBC_SHA ; length=128

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA ; length=128

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA ; length=128

TLS_DHE_RSA_WITH_AES_128_CBC_SHA ; length=128

TLS_DHE_DSS_WITH_AES_128_CBC_SHA ; length=128

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA ; length=128

TLS_ECDHE_RSA_WITH_RC4_128_SHA ; length=128

SSL_RSA_WITH_RC4_128_SHA ; length=128

TLS_ECDH_ECDSA_WITH_RC4_128_SHA ; length=128

TLS_ECDH_RSA_WITH_RC4_128_SHA ; length=128

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA ; length=128

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA ; length=128

SSL_RSA_WITH_3DES_EDE_CBC_SHA ; length=128

TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ; length=128

TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA ; length=128

SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA ; length=128

SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA ; length=128

SSL_RSA_WITH_RC4_128_MD5 ; length=128

TLS_EMPTY_RENEGOTIATION_INFO_SCSV ; length=128

TLS_DH_anon_WITH_AES_128_CBC_SHA256 ; length=128

TLS_ECDH_anon_WITH_AES_128_CBC_SHA ; length=128

TLS_DH_anon_WITH_AES_128_CBC_SHA ; length=128

TLS_ECDH_anon_WITH_RC4_128_SHA ; length=128

SSL_DH_anon_WITH_RC4_128_MD5 ; length=128

TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA ; length=128

SSL_DH_anon_WITH_3DES_EDE_CBC_SHA ; length=128

TLS_RSA_WITH_NULL_SHA256 ; length=128

TLS_ECDHE_ECDSA_WITH_NULL_SHA ; length=128

TLS_ECDHE_RSA_WITH_NULL_SHA ; length=128

SSL_RSA_WITH_NULL_SHA ; length=128

TLS_ECDH_ECDSA_WITH_NULL_SHA ; length=128

TLS_ECDH_RSA_WITH_NULL_SHA ; length=128

TLS_ECDH_anon_WITH_NULL_SHA ; length=128

SSL_RSA_WITH_NULL_MD5 ; length=128

SSL_RSA_WITH_DES_CBC_SHA ; length=128

SSL_DHE_RSA_WITH_DES_CBC_SHA ; length=128

SSL_DHE_DSS_WITH_DES_CBC_SHA ; length=128

SSL_DH_anon_WITH_DES_CBC_SHA ; length=128

SSL_RSA_EXPORT_WITH_RC4_40_MD5 ; length=128

SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 ; length=128

SSL_RSA_EXPORT_WITH_DES40_CBC_SHA ; length=128

SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA ; length=128

SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA ; length=128

SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA ; length=128

TLS_KRB5_WITH_RC4_128_SHA ; length=128

TLS_KRB5_WITH_RC4_128_MD5 ; length=128

TLS_KRB5_WITH_3DES_EDE_CBC_SHA ; length=128

TLS_KRB5_WITH_3DES_EDE_CBC_MD5 ; length=128

TLS_KRB5_WITH_DES_CBC_SHA ; length=128

TLS_KRB5_WITH_DES_CBC_MD5 ; length=128

TLS_KRB5_EXPORT_WITH_RC4_40_SHA ; length=128

TLS_KRB5_EXPORT_WITH_RC4_40_MD5 ; length=128

TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA ; length=128

TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 ; length=128

java version "1.7.0_45"

mon terminal

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

Édité par Javier

Happiness is a warm puppy

+1 -0

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.

+0 -0
Auteur du sujet

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 ?

+0 -0
Staff

Cette réponse a aidé l'auteur du sujet

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

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.

Bref, keep cool.

Édité par nohar

I was a llama before it was cool

+2 -0
Staff

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

+0 -0
Staff

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.

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 ?

Édité par Nicofuma

Développeur de phpBB

+0 -0
Auteur du sujet

Petit Up.

Je vais vous replacer dans le contexte avec ce message :

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 ?

Ge0

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 !

Édité par anonyme

+2 -0

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 !

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte