Juste une remarque là dessus : pour ceux qui ne sont pas compatibles SNI, ils auront un certificat serveur qui ne correspond pas à leur site, donc potentiellement ils n'arriveront pas sur la page qui demande à mettre à jour car ils ne passeront pas outre la popup de sécurité du navigateur. A avoir en tête pour le choix.
Et pour le certificat "par défaut" à utiliser pour eux, il vaut mieux qu'il soit neutre pour ne pas afficher le certificat d'un des vrais sites quand on se connecte à un autre.

Autre note : le navigateur par défaut sur Android 2.3 ne gère pas non plus le SNI. A voir si cela représente une proportion non négligeable de la cible.

Le 1 avril 2015 14:34, Manuel OZAN <manuelozan@gmail.com> a écrit :
Cette solution est il me semble la plus "propre".
Si le client n'a pas de navigateur/plateforme compatible SNI --> on le route vers une page/vhost qui lui demande de mettre à jour son navigateur.

Finalement c'est plutôt politique que technique...

Le 1 avril 2015 14:23, Baptiste <bedis9@gmail.com> a écrit :
2015-04-01 14:18 GMT+02:00 Antoine Benoit <antoine.benoit@gmail.com>:
> D'après ce que je sais, la suppression d'SSL v3 n'interdit que IE6 + XP,
> mais on peut avoir des IE plus récents sous XP.
> Et SSLLabs indique que IE8 + XP gère le TLS par défaut, mais pas le SNI,
> donc si ça change le problème.
>

HAProxy peut gérer un certificat par "défaut" pour les gens qui
n'enverraient pas le SNI.
En plus, HAProxy peut logger le SNI (et pleins d'autres info du SSL,
comme la version du TLS et le cipher utilisé), mais aussi le
user-agent HTTP.
Ca permet de faire un "audit" et de savoir si certains site ont 100%
de clients "compatibles" SNI (car ils l'ont envoyé) et donc migrables
sur une même IP.

Baptiste
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/



--
Cordialement.

Manuel Ozan