SNI est-il réellement utilisé et pris en charge par les navigateurs ?

Question

Je peux trouver diverses informations sur SNI (cf. Wikipedia ), mais je ne peux pas trouver de statistiques sur le support réel des navigateurs.

Le mieux que j'ai pu trouver est qu'il devrait fonctionner sur Windows XP avec SP3.

Quelqu'un sait-il si le SNI peut être utilisé dans la pratique ?

Answer 1

Je peux partager mon expérience et mon approche pour passer d'une IP par certificat dans un environnement d'hébergement virtuel (plusieurs domaines par serveur) à un environnement à charge équilibrée avec une IP pour tous les domaines.

Nous avons examiné nos statistiques (plus d'un million de visiteurs uniques par mois), qui sont principalement des utilisateurs masculins nord-américains cherchant à acheter des pièces automobiles en ligne, et nous avons constaté le 8 mars 2014 qu'environ 4 % des utilisateurs étaient sous Windows XP et utilisaient Internet Explorer (les autres étaient mineurs - dans le pire des cas, 4,5 % du total des utilisateurs seraient affectés par la non-prise en charge de SNI). Gardez à l'esprit que nous n'avons aucun "contrôle" sur ces utilisateurs et que nous ne pouvons donc pas leur dire de changer de navigateur. Ce pourcentage diminue également assez rapidement, du moins aux États-Unis.

Nous avons d'abord décidé qu'il était "normal" que les clients non SNI aient une expérience quelque peu différente de celle des clients soutenant SNI.

Notre approche consistait à détecter côté serveur (à l'aide de la chaîne UA) la combinaison navigateur/système d'exploitation qui ne prend pas en charge SNI (comme d'autres personnes l'ont mentionné) : Article Wikipedia sur le support SNI ). Tous nos domaines (~ 120) auraient un enregistrement A pointant vers une seule IP équilibrée en charge. Nous avions une deuxième IP (également équilibrée en charge) pour un domaine que nous pouvons appeler generic-autoparts.com.

La configuration est donc la suivante [je ne suis associé à aucun des domaines que j'utilise comme exemples ci-dessous] :

mikesautoparts.com --> Un enregistrement de serveur de nom de l'IP X
dansautoparts.com --> Un enregistrement de serveur de nom de l'IP X
jensautoparts.com --> Un enregistrement de serveur de nom de l'IP X
... etc.

generic-autoparts.com --> Un enregistrement de serveur de noms de IP Y

Si un client frappe http://www.dansautoparts.com et supporte SNI, rien ne se passe. Il navigue sur dansautoparts.com, et quand vient le moment de passer à la caisse, il utilise https://www.dansautoparts.com .

Si un client frappe http://www.dansautoparts.com et nous détectons qu'il ne supporte pas SNI, nous redirigeons immédiatement le client vers http://generic-autoparts.com/dansautoparts.com . Il fait ses courses sur ce site, et à la caisse il utilise https://generic-autoparts.com/dansautoparts.com

Maintenant, si un client tape https://www.dansautoparts.com DIRECTEMENT (lien dans le courrier électronique, page indexée dans les moteurs de recherche), vous n'avez pas de chance. Ils obtiendront une méchante erreur de certificat. Dans notre cas, nous nous sommes assurés que tous les e-mails envoyés par notre système n'utilisaient pas https, et nous savions que les moteurs de recherche n'avaient pas indexé nos pages https.

Chaque environnement présente des défis différents et des compromis potentiels. Nous avons trouvé que cela fonctionnait bien dans notre cas et que les clients "acceptaient" (ou ne remarquaient pas) d'être redirigés vers [http://generic-autoparts.com/ [ORIGINAL](http://generic-autoparts.com/[ORIGINAL) DOMAINE].com . Nous avons également sécurisé le paiement par le biais de generic-autoparts.com.

Disons que 20 % des utilisateurs non-SNI remarquent la redirection, que cela leur semble louche et qu'ils quittent le site. Dans notre cas, cela représente 0,8 - 0,9 % (sur la base des chiffres du 8 mars 2014) des utilisateurs et nous étions prêts à " vivre " avec cela. Je n'ai pas de données spécifiques à ce sujet pour le moment, mais les ventes globales sont restées stables. [EDIT 3/28/2014 : Nous n'avons constaté aucun impact sur les ventes après avoir basculé 100 % de nos clients].

Mise à jour de la mise en œuvre le 8 juillet 2014

Il s'avère qu'il est impossible de détecter chaque chaîne de l'agent UA de manière statique sur le serveur. Nous avons implémenté le JavaScript suivant pour détecter la capacité SNI du navigateur. L'approche générale est de faire une requête JSONP contre un domaine qui requiert SNI (Apache supporte ceci à travers "SSLStrictSNIVHostCheck on"). Si la requête JSONP échoue, nous redirigeons le client vers le domaine non SNI.

Pour compliquer encore les choses, nous ne voulons pas rediriger tout le monde juste parce que le SNI_TEST_DOMAIN est hors service. Si la requête JSONP échoue (en raison d'un dépassement de délai, car il n'existe aucun moyen de détecter directement un échec JSONP), nous vérifions que le serveur est disponible en effectuant une requête HTTP "health-check". En outre, nous ne voulons pas exécuter ce code javascript à chaque chargement de page, car cela augmente le risque d'un délai d'attente étrange et d'une redirection incorrecte de nombreux clients. Nous définissons donc une variable de session une fois que la vérification SNI est effectuée afin que cela ne se reproduise pas lorsque le client navigue sur les sites.

Nous savons que certaines vérifications erronées échouent en raison du manque de fiabilité du délai d'attente JSONP, mais depuis la mise en œuvre de cette mesure, nous ne recevons aucune plainte des clients.

var redirect='http://REPLACE_WITH_NON_SNI_URL';

var sni_https_timeout, sni_http_timeout;
var https_req = $.ajax({
    url : 'https://SNI_TEST_DOMAIN.com/snitest.php',
    dataType : "jsonp",
}).done(function() {
        window.clearTimeout(sni_https_timeout);
        var request = $.ajax({
        url: "index.php?ua=sni_check_done",
       type: "POST"
    });
})

sni_https_timeout = window.setTimeout(function() {
    var http_req = $.ajax({
        url : 'http://SNI_TEST_DOMAIN/sni_healthcheck.php',
        dataType : "jsonp"
    }).done(function()
        {
            window.clearTimeout(sni_http_timeout);
            window.setTimeout(function()
            {
                window.location = redirect;
            },
        200);
    });

    sni_http_timeout = window.setTimeout(function() { sni_http_fail(); }, 8000);

}, 8000);

function sni_http_fail() {
    var request = $.ajax({
        url: "index.php?ua=sni_check_done",
        type: "POST"
    });
}

snitest.php / sni_healthcheck.php :

<?php
if (array_key_exists('callback', $_GET))
{
    header( 'Content-type: application/javascript' );
    echo "{$_GET['callback']}();\n";
}

Answer 2

Le site Article de Wikipedia auquel vous faites référence liste les versions de navigateur et de serveur prises en charge. Internet Explorer 7 (Vista ou supérieur, pas XP) ou plus récent et Mozilla Firefox 2.0, par exemple. À moins de savoir que tous vos visiteurs utilisent des navigateurs pris en charge, vous ne pouvez pas utiliser SNI (avec plusieurs certificats sur une adresse IP) sans les couper de la partie SSL de votre site.

Answer 3

Internet Explorer (toutes les versions 6, 7, 8 et 9) sous Windows XP ne prend pas en charge SNI. Tous les autres fonctionnent. Je ne sais pas vraiment combien d'utilisateurs de XP utilisent Internet Explorer, mais c'est le nombre magique d'utilisateurs qui ne peuvent pas utiliser SNI.

Support mobile :

Android default browser on Honeycomb or newer      
Windows Phone 7
MobileSafari in Apple iOS 4.0 or later

Answer 4

Je réponds tardivement à cette question, mais pour tous les lecteurs qui pourraient être intéressés par ce type de solution. Il suffit de détecter le navigateur et le système d'exploitation en utilisant la fonction côté serveur et de dire au visiteur d'utiliser "Installer et utiliser un navigateur sécurisé pour les achats en ligne comme Chrome ou Firefox et fournir un lien pour le télécharger et l'installer".

C'est la meilleure façon de sécuriser les achats de vos clients et cela sert deux objectifs : l'utilisation de SSL activé par SNI et la sécurisation des achats de vos clients. En effet, ces navigateurs obsolètes sous XP ne sont vraiment pas sûrs, que le serveur utilise ou non le protocole SNI SSL.

Nous pouvons prendre ce risque, car le pourcentage d'utilisateurs utilisant des versions plus anciennes d'IE sur XP est inférieur à 5 % aux États-Unis et est négligeable ou nul dans les autres pays. En fait, dans les autres pays, les gens sont habitués aux navigateurs Open Source.

D'après ma propre expérience, j'héberge de nombreux sites Web pour moi-même ainsi que pour de nombreux clients et j'ai mis en place le SSL pour tous ces sites en utilisant la technologie SNI sans IP dédiée. Je suis certain que les gens sont passés à chrome ou firefox dans de nombreux pays, presque tous et aux États-Unis, 95 %.

Pardonnez-moi pour toute information inexacte.

Answer 5

Je pense qu'il y a deux aspects à cela, l'interface utilisateur et la partie détection.

UX

<!--[if lt IE 7]>
   <div>You're using a browser that has high security risks (SSL, XSS, etc). Please consider upgrading it.</div>
<![endif]-->

Il est clair que toute personne utilisant IE6 or below a de grandes chances d'être sur Windows XP et ne supportant pas SNI. Les autres qui usurpent leur user-agent n'ont pas d'importance ici.

Côté serveur

1. Renifler l'agent utilisateur. Nous proposerons des regex une fois les tests unitaires terminés.
2. Utilisez l'implémentation AJAX ci-dessus.

Note spéciale

L'utilisation de la solution AJAX permet une détection à 99 % sans faille, mais elle n'est pas conforme à certains principes du développement web.

• Amélioration progressive - vous donnez la même requête AJAX à tous les utilisateurs. Les utilisateurs qui soutiennent SNI ne devraient pas être dérangés.
• Héritage - vous ne pouvez pas déprécier ce code facilement.
• Si vous utilisez jQuery pour vos requêtes AJAX, il se peut que votre code dépende de la méthode $.ajaxStop().