web-dev-qa-db-fra.com

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

Je peux trouver diverses informations sur SNI (voir Wikipedia ), mais je ne trouve aucune statistique sur le support réel dans les navigateurs.

Le mieux que j'ai pu découvrir, c'est que cela devrait fonctionner sous Windows XP avec SP3.

Est-ce que quelqu'un sait si SNI peut réellement être utilisé dans la pratique?

sslcross-browsersni
66
Aljosa Mohorovic

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

Nous avons examiné nos analyses (plus d'un million de visiteurs uniques par mois), qui sont principalement des utilisateurs masculins d'Amérique du Nord cherchant à acheter des pièces automobiles en ligne, et nous avons découvert le 8 mars 2014 qu'environ 4% des utilisateurs étaient sous Windows XP en utilisant Internet Explorer (d'autres étaient mineurs - 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, donc nous ne pouvons pas leur dire pour changer de navigateur. Ce pourcentage diminue également assez rapidement, du moins aux États-Unis.

Nous avons d'abord décidé qu'il était "OK" pour les clients non SNI d'avoir une expérience quelque peu différente de celle des clients supportant SNI.

Notre approche était de détecter côté serveur (en utilisant une chaîne UA) quelle combinaison navigateur/système d'exploitation ne prend pas en charge SNI (comme d'autres l'ont mentionné: article Wikipedia sur la prise en charge SNI ). Tous nos domaines (~ 120) auraient un enregistrement A pointant vers une seule adresse IP à charge équilibrée. 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 [je ne suis associé à aucun domaine que j'utilise comme exemples ci-dessous]:

mikesautoparts.com -> Un enregistrement de serveur de noms IP X
dansautoparts.com -> Un enregistrement de serveur de noms IP X
jensautoparts.com -> Un enregistrement de serveur de noms IP X
... etc

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

Si un client frappe http://www.dansautoparts.com et prend en charge SNI, rien ne se passe. Il parcourt dansautoparts.com, et quand vient le temps de vérifier, il utilise https://www.dansautoparts.com .

Si un client frappe http://www.dansautoparts.com , et que nous détectons qu'il ne prend pas en charge SNI, nous redirigeons immédiatement le client vers http://generic-autoparts.com /dansautoparts.com . Il fait ses achats là-bas, et à la caisse, il utilise https://generic-autoparts.com/dansautoparts.com

Maintenant, si un client frappe https://www.dansautoparts.com DIRECTEMENT (lien dans l'e-mail, page indexée dans les moteurs de recherche), vous n'avez pas de chance. Ils obtiendront une mauvaise 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 constaté 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 DOMAIN] .com. Nous avons également sécurisé le paiement via generic-autoparts.com.

Disons que 20% des utilisateurs non-SNI remarquent la redirection, cela semble louche, et ils s'en vont. Dans notre cas, cela représente 0,8 - 0,9% (sur la base des chiffres du 8 mars 2014) d'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 28/03/2014: Nous n'avons vu aucun impact sur les ventes après avoir changé 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 statiquement chaque chaîne d'agent UA sur le serveur. Nous avons implémenté le JavaScript suivant pour détecter la capacité SNI du navigateur. L'approche générale consiste à effectuer une requête JSONP sur un domaine qui nécessite SNI (Apache le prend en charge via "SSLStrictSNIVHostCheck on"). Si la demande JSONP échoue en expirant, nous redirigeons le client vers le domaine nonSNI.

Pour compliquer davantage les choses, nous ne voulons pas rediriger tout le monde simplement parce que SNI_TEST_DOMAIN est en panne. Si la requête JSONP échoue (en expirant car il n'y a aucun moyen de détecter directement une panne JSONP), nous vérifions que le serveur est disponible en effectuant une requête HTTP "Health-Check". De plus, nous ne voulons pas exécuter ce code javascript à chaque chargement de page, car cela augmente les risques de dépassement de délai étrange et de redirection incorrecte de nombreux clients, nous définissons donc une variable de session une fois la vérification SNI terminée afin qu'elle ne se produise pas. à nouveau lorsque le client navigue sur les sites.

Nous savons que nous obtenons certaines fausses vérifications qui échouent en raison du manque de fiabilité du délai JSONP, mais depuis la mise en œuvre de cela, 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";
}
90
ronneseth

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

19
Robert

Le problème est Windows XP clients et Android <3.0 clients. Malheureusement, ensemble, ils représentent encore près de 10% des visiteurs de plusieurs de nos sites Web. De plus, même si Les utilisateurs de Blackberry sont un faible volume, ils font partie de nos clients payants. XP, Blackberry et Gingerbread combinés rendent SNI inacceptable sur la plupart de nos sites Web en ce moment (février 2015). Je m'attends à ce que ce problème diminue dans environ un an ou deux. .

Mise à jour de novembre 2016 (21 mois plus tard): Aller sur un site assez standard avec environ 10 000 visites/mois. Jan 2013 ~ 10% non-SNI. Jan 2014 ~ 6%, Jan 2015 <2%, Jan 2016 ~ 0,5%, Nov 2016 ~ 0,1% (1 sur 1000). Nous avons effectué le basculement en novembre/décembre 2015. Cependant, certains marchés peuvent avoir un plus grand nombre de ces utilisateurs. J'ai créé des audiences personnalisées dans Google Analytics, il est donc facile de voir l'impact. Définissez simplement par le nom du système d'exploitation, la version commence par, et pour XP, le navigateur est IE.

9
jeffmcneill

Internet Explorer (toutes les versions; 6, 7 et 8) sous Windows XP ne prend pas en charge SNI. Toutes les autres fonctionnent. Je ne sais pas vraiment combien d'utilisateurs sur XP utilise 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
5
themihai

Oui

Vous ne pourrez pas prendre en charge les connexions SSL à partir de XP avec SNI. Cependant, autoriser XP clients à se connecter n'est pas conforme à certaines normes de toute façon, donc vous Il se peut que vous deviez supprimer ces utilisateurs pour d'autres raisons.

Ils ne sont que quelques pour cent en 2016 et en baisse. Si vous devez prendre en charge chaque utilisateur avec SSL, vous devrez alors basculer dynamiquement, mais si vous avez juste besoin de la grande majorité ... bien sûr.

3
DigitalRoss

Je suis en retard pour répondre à cela, mais pour tous les lecteurs qui pourraient être intéressés par ce type de solution. Détectez simplement le navigateur et le système d'exploitation à l'aide de la fonction côté serveur et dites au visiteur d'utiliser "Installer et utiliser un navigateur sécurisé pour faire des achats en ligne comme Chrome ou Firefox et fournir un lien pour télécharger et installer."

C'est le meilleur moyen de sécuriser les achats pour votre client et cela sert à deux fins, une utilisation SSL activée par SNI et la sécurisation des achats du client. Parce que ces navigateurs obsolètes sur XP ne sont vraiment pas sûrs quel que soit le serveur utilisant SSL activé par SNI ou non.

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

Ma propre expérience, j'héberge de nombreux sites Web pour moi-même ainsi que de nombreux clients et j'ai SSL pour tous en utilisant la technologie SNI sans IP dédiée et je suis sûr que les gens sont passés à chrome ou firefox dans de nombreux pays, presque tous et aux États-Unis, 95% d'entre eux.

Pardonnez-moi pour toute information inexacte.

2
LuckyBabu

http://caniuse.com/#feat=sni indique actuellement que SNI est pris en charge par 97,6% des navigateurs.

1
Bryan Legend

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 prend pas en charge SNI. Les autres qui usurpent leur agent utilisateur n'ont pas d'importance ici.

Côté serveur

  1. Reniflez pour l'agent utilisateur. Fournira des expressions rationnelles une fois les tests unitaires terminés.
  2. Utilisez l'implémentation AJAX ci-dessus).

Remarque spéciale

L'utilisation de la solution AJAX vous offre une détection pare-balles à 99% mais n'est pas conforme à quelques principes de développement Web.

  • Amélioration progressive - vous donnez la même demande AJAX à tous les utilisateurs. Les utilisateurs qui prennent en charge SNI ne devraient pas être dérangés .
  • Héritage - vous ne pouvez pas déprécier ce code facilement.
  • Si vous utilisez jQuery avec vos requêtes AJAX, vous pouvez avoir un impact sur votre code dépend de la méthode $ .ajaxStop ().
0
Șerban Ghiță