Suppression de SSLv3 et des ciphers vulnérables

[alh]

Repost depuis l'ancien forum : https://forums.web4all.fr/topic/10335-suppression-de-sslv3-et-des-ciphers-vulnérables/

Une idée de la date de disparition de SSLv3 sur les hébergements mutualisés ? Tous les sites mutualisés en HTTPS utilise SNI, cependant SSLv3 ne le supporte pas, donc un client qui ne supporte que SSLv3 ne pourra de toute façon pas se connecter...

Dans la même logique, supprimer les ciphers vulnérables (RC4, 3DES &Co) serait aussi un plus, puisse qu'ils ne sont utiles qu'avec les clients qui supportent uniquement des protocoles obsolètes.

Idées pour la chaine de ciphers de mod_ssl

SSLCipherSuite EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES:EDH+CAMELLIA:CAMELLIA:!3DES:!aNULL:!MD5:!PSK:!SRP:!LOW:!ADH:!DSS:!RC4:!EXPORT:!eNULL:!DES
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLStrictSNIVHostCheck On
SSLCompression off

Merci d'étudier la question.

[Aurelien P.]

Bonjour, 

on doit encore valider certaines choses car nous avons des clients qui sont encore avec du IE6 ou IE7 qui utilisent d'anciens protocoles.

Concernant le SSL, certains n'utilisent pas SNI voir pas de SSL donc le cas de figure présenté là ne s'applique pas à tous les clients.

Il y aura des évolutions sur la partie HTTP, côté frontend et backend c'est prévu mais pour le moment la priorité est la reprise des clients de Web4all du mieux que possible  

[alh]

Merci pour la réponse Aurélien,

XP n'est plus supporté par Cro$osft depuis combien de temps maintenant, et en plus avec IE 6/7... C'est plus dramatique à ce niveau, c'est effroyable... Vista vient aussi de passer l'arme à gauche... Ils savent que Firefox sous XP leur offre TLSv1.2 ?

Ils représentent quel pourcentage des visiteurs ces clients ? Vu que le manager n'est plus accessible (pas de SSLv3 sur my.yulpa.io et sur l'ancien manager), ça doit pas être une grande proportion.

Citation

certains n'utilisent pas SNI voir pas de SSL

On peut donc avoir une IP dédiée pour un domaine ? Jusqu'à maintenant, tous les sites que j'ai utilise HTTPS via SNI uniquement et il n'est fait nulle part mention de la possibilité d'avoir des IP dédiées (à ma connaissance) lors de l'utilisation de HTTPS.

Pour l'argument du "pas de SSL" est abscons : Faudra que l'on m'explique en quoi supprimer SSLv3 et des suites de chiffrements trouées va poser problème à un site qui n'utilise pas HTTPS ?

Une option de compromis serait de permettre de modifier, par virtualhost, les protocoles et les suites de chiffrements (via une option dans le manager ou via SSH). Ainsi celui qui souhaite disposer de SSLv3 le peu, celui qui souhaite uniquement TLSv1.2 et AES-GCM le peu aussi.

[Aurelien P.]

Bonjour, 

pour le moment on "hérite" de ce qui a été fait / pas fait du temps de Web4all. On a beaucoup de chantier qui doivent permettre de mettre en place / remplacer / améliorer / supprimer des éléments. Il y avait en effet des IP en dédié.

Il est impossible de permettre au client de choisir les protocoles et suites car cela est effectué sur le frontend et est donc global à tout le monde.

Comme je l'ai dis : "Il y aura des évolutions sur la partie HTTP, côté frontend et backend c'est prévu mais pour le moment la priorité est la reprise des clients de Web4all du mieux que possible  "

[alh]

Un autre truc "cool" serait de permettre la modification de l'ordre de préférence des courbes ECC pour ECDHE, mais j'en demande sans doute un peu trop...

[Aurelien P.]

Comme je l'ai dit tout cela est commun à tout le monde car LB mutualisé.