Qualys SSL Labs (https://www.ssllabs.com/ssltest/) avant : | Qualys SSL Labs aujourd'hui : |
(https://lafibre.info/images/ssl/201701_qualys_ssl_labs_avant_mini.png) (https://lafibre.info/images/ssl/201701_qualys_ssl_labs_avant.png) | (https://lafibre.info/images/ssl/201701_qualys_ssl_labs_apres_mini.png) (https://lafibre.info/images/ssl/201701_qualys_ssl_labs_apres.png) |
Observatory by Mozilla (https://observatory.mozilla.org/) avant : | Observatory by Mozilla aujourd'hui : |
(https://lafibre.info/images/ssl/201701_mozilla_avant_mini.png) (https://lafibre.info/images/ssl/201701_mozilla_avant.png) | (https://lafibre.info/images/ssl/201701_mozilla_apres_mini.png) (https://lafibre.info/images/ssl/201701_mozilla_apres.png) |
CryptCheck (https://tls.imirhil.fr/) avant : | CryptCheck aujourd'hui : |
(https://lafibre.info/images/ssl/201701_cryptcheck_avant_mini.png) (https://lafibre.info/images/ssl/201701_cryptcheck_avant.png) | (https://lafibre.info/images/ssl/201701_cryptcheck_apres_mini.png) (https://lafibre.info/images/ssl/201701_cryptcheck_apres.png) |
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression off
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLUseStapling on
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(150000)
Seule régression : la taille de la clé RSA est passée de 4096bits à 2048bits. J'imagine que si Let's Encrypt crée des clé de 2048bits et pas plus, il y a une explication logique. Si vous l'avez, je suis preneur.
Premièrement, générer un certificat avec une clé 4096 Bits :
Pour une première génération :Code: [Sélectionner]sudo ./letsencrypt-auto certonly --rsa-key-size 4096
Pour un renouvellement (J'ai de gros soucis à ce niveau, d'ailleurs.)Code: [Sélectionner]sudo ./letsencrypt-auto renew --rsa-key-size 4096 --force-renew
C'est un point discuté sur le repo de Certbot (cf https://github.com/certbot/certbot/issues/489 (https://github.com/certbot/certbot/issues/489) et https://github.com/certbot/certbot/issues/2080 (https://github.com/certbot/certbot/issues/2080)).
- 2048 bits devrait être ok jusqu'à environ 2030, et d'ici là tout le monde devrait utiliser quelque chose de mieux comme ECDSA ou EdDSA, donc il n'y a aucune bonne raison d'utiliser des clés RSA plus grandes.
Quand une personne scan des IP, elle tente ensuite de trouver des failles de sécurité pour s'introduire.Est-ce que ça change quelque chose, à partir du moment où il suffit d'une requête DNS pour récupérer le nom de domaine, puisque le PTR est renseigné ?
Une solution que j'utilise est de mettre une page vide si la requête ne se fait pas avec le nom de domaine.
Toutefois il existe une astuce pour trouver le nom de domaine : le récupérer dans le certificat SSL.
Depuis hier, je ne présente plus le certificat sans le bon nom de domaine.
Il a cet outil qui permet de voir les nom de domaines des serveurs voisins : http://www.tcpiputils.com/browse/ip-address/46.227.16.8 Je ne sais pas comment il fait, mais ce n'est pas le reverse DNS car il est capable de trouver plusieurs sites sur une même IP.
Our DNS crawlers try to resolve every domain name once per month
En tout cas, c'est une très bonne décision de quitter StartCom, qui est une autorité connue pour avoir sciemment triché depuis son intégration avec WoSign, en anti-datant des certificats signés en SHA-1. Il y a un petit résumé ici : https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ , et pour ceux qui ont un peu de temps à perdre, je vous recommande la lecture de l'historique qui a mené à cette conclusion : https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/previewOui, une autorité se doit d'être irréprochable; et si un incident arrive, d'être transparent et de ne pas prendre les gens pour des idiots.
Je suis curieux : Comment avoir la liste des nom de domaines enregistrés ?De la même façon que Google?
Je suis curieux : Comment avoir la liste des nom de domaines enregistrés ?
Je suis curieux : Comment avoir la liste des nom de domaines enregistrés ?