Je viens de travailler à nouveau sur le site, d'ailleurs il a été hors service pendant une bonne heure, je vous prie de m'en excuser, voici les explications.
Déjà, il y a le souci ci-dessus en HTTPS sur certain navigateurs qui posait problème, puis, Killer_of_Space m'indique qu'il y a des soucis au niveau du HTTPS du site.
En effet, j'avais configuré le HTTPS, il y avait le certificat, c'est super, mais je n'avais pas encore pris le temps de configurer finement les algorithmes de chiffrement.
Hors la machine virtuelle du site ayant été installée en 2012, la configuration par défaut du serveur web Apache proposait notamment des algorithmes vieux et troués (DES, RC4...) et de vieux protocoles (SSLv3).
Donc forcément, ce n'était pas très glorieux.
- https://tls.imirhil.fr/https/hellominecraft.fr
Celui-ci ce concentre sur la ciphersuite (liste des algorithmes de chiffrement proposés par le site) et les protocoles (méthode d'établissement du lien chiffré avec le site).
Rien de particulier à commenter si ce n'est que des valeurs par défaut de 2012 c'est carrément la loose (en plus de rimer, ok je sors).
Donc bon, il suffit de changer la configuration en utilisant par exemple l'outil SSL Config Generator qui donne une meilleure config.
- https://www.ssllabs.com/ssltest/analyze ... necraft.fr
Celui-ci était déjà plus clément, n'indiquant qu'une note de C sur la configuration par défaut d'Apache de 2012 (bon, ça méritait F aussi, mais passons ^^).
Les messages sont en revanche bien plus intéressants, passons les donc en revue un par un (pour ceux que ça intéresse... bon... allez au moins il y a Killer qui lira... se motive)
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
Celle-ci est plutôt simple, le protocole SSLv3 est trouvé (ordre d'apparition : SSLv1, SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2) et il suffit de bloquer tous les SSL car ils son troués.
POODLE est une attaque qui consiste à s'intercaler entre le client et le serveur, forcer un vieux SSLv3, et attaquer pour déchiffrer.
Pour l'avoir étudié, je peux quand même vous dire qu'il faut sacrément y aller pour déchiffrer quoi que ce soit, on a environ 1 chance sur 255 par requête de deviner un caractère... !
Enfin bon, quoi qu'il en soit, SSLv3 est désactivé via la propositon de SSL Config Generator, donc problème déjà résolu.
This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B.
L'algorithme de chiffrement RC4 peut être déchiffré par une attaque de force brute, c'est-à-dire si on capture les données chiffrées, qu'on a du temps, et un supercalculateur.
Quoi qu'il en soit, là aussi, RC4 désactivé via la propositon de SSL Config Generator, donc problème déjà résolu.
This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.
C'est une extension normée ici - non je n'ai pas lu tout le papier - qui permet d'éviter qu'un attaquant force un algorithme de chiffrement trop vieux.
Cela ne protège que TLS, pas SSLv3, et, bonne nouvelle, même en 2012, c'était déjà géré par défaut (le seul bon point de l'analyse, cool non ? :p)
This server's certificate chain is incomplete. Grade capped to B.
Celui-ci est très intéressant car il m'a permis de remarquer une erreur d'installation du certificat, ou plutôt, une omission.
En effet, détaillons comment est signé le certificat de HelloMinecraft :
Code : Tout sélectionner
DST Root CA X3 Autorité Racine
|
Approuve
\|/
Let's Encrypt Authority X1 Autorité de certification
|
Vérifie
\|/
HelloMinecraft.fr Certificat HTTPS du siteCela permet au visiteur du site de générer une clé temporaire de communication - je vous épargne la négociation - et de la chiffrer pour que seul le serveur la connaisse.
Cependant, pour savoir que le certificat - comportant la clé publique - du serveur est valide et pas celui d'un imposteur, il faut le vérifier.
Le client possède donc des certificats racines, et le certificat du site est signé par la clé privée de l'autorité de certification.
Sauf que Let's Encrypt est relativement récent, tout le monde n'a donc pas nécessairement le certificat Let's Encrypt sur son poste.
Lorsque cela arrive, le site n'est pas vérifié, et cela donne l'erreur HTTPS qu'on peut voir ci-dessous, à gauche : Il ne connait pas Let's Encrypt, il ne peut pas vérifier.
Le présent message est intéressant car il précise que la chaîne de certification est incomplète, mais surtout, que je peux y faire quelque chose.
Après recherche il est en effet possible de stocker les certificats intermédiaires - ici juste celui de Let's Encrypt - et de les fournir au visiteur en plus du certificat du site.
Le certificat de l'autorité racine 'DST Root CA X3' étant quant à lui largement diffusé, le fait de fournir celui de Let's Encrypt résout le problème.
Ainsi le navigateur peut vérifier HelloMinecraft.fr juste avec le certificat de l'autorité racine car on lui fournit la preuve que l'autorité racine approuve indirectement le site :
-> 
On passe de "Let's Encrypt approuve HelloMinecraft mais je ne connais pas Let's Encrypt" à "DST Root CA X3, que je connais, approuve Let's Encrypt qui approuve HelloMinecraft".
Après tous ces réglages, on passe à une note quasi parfaite :
Passons donc à l'ultime message, que j'ai volontairement gardé pour la fin :
The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-.
Comme dit précédemment, si on chiffre avec la clé publique et déchiffre avec la clé privée, en cas de compromission de la clé privée, on peut tout déchiffrer.
Cela veut dire qu'on peut faire une capture réseau à un instant T, puis hacker le serveur à un instant T+1 - on va supposer qu'on peut car on est la NSA - alors à T+2 on peut déchiffrer tout ce qu'on avait capturé.
Du coup, pour éviter cela, il faut en fait éviter d'utiliser l'échange de clé RSA, qui conciste à utiliser des couples clé publique / clé privée, et générer des clés temporaires par un autre moyen.
Pour cela il existe les algorithmes Diffie-Hellman (DHE) et une version utilisant les courbes elliptiques, dite Elliptic Curve cryptography (ECDHE).
Cela permet de générer des clés en parlant avec le correspondant, tout en empêchant à un tiers de deviner la clé, et sans utiliser de clé permanente sur le serveur ou le client.
Ainsi en cas de compromission du serveur on ne peut pas déchiffer des communications chiffrées que l'on aurait au préalable capturées. Elles restent protégées.
Le souci, c'est qu'avec un serveur Apache de 2012 eh bien, on ne peut pas faire cela, c'est trop vieux, et on ne peut pas l'activer.
Du coup, j'ai mis à jour la machine virtuelle hébergeant le site pour qu'elle dispose d'un système à jour et d'une version d'Apache à jour.
Cela m'a pris une heure environ, car il y avait en fait des différences à répercuter dans les fichiers de configuration, et divers pépins comme d'hab' en fait.
En plus de cela, j'avais sur le site à certains endroit, des balises PHP <? au lieu de <?php qui traînaient, et cette version plus récente de PHP ne les gère plus par défaut, j'ai dû corriger
Conclusion
Après tous ces ajustements et cette mise à jour faite non sans mal, le site dispose donc d'une configuration HTTPS solide :
- https://tls.imirhil.fr/https/hellominecraft.fr
- https://www.ssllabs.com/ssltest/analyze ... necraft.fr
PS: Java 6 et Internet Explorer sous Windows XP ne pourront pas accéder au site en HTTPS avec de tels réglages. Je pense qu'on s'en fiche, ce serait troué de toute manière alors autant qu'ils utilisent HTTP ^^
félicitations pour le boulot !
)
