SNI 是否真的在浏览器中使用和支持？

Question

我可以找到有关 SNI 的各种信息（请参阅 Wikipedia），但我找不到有关 SNI 的任何统计信息浏览器中的实际支持。

我能找到的最好结果是它应该可以在带有 SP3 的 Windows XP 上运行。

有谁知道SNI是否可以实际使用？

Answer 1

http://caniuse.com/#feat=sni 目前表示 97.6% 的浏览器支持 SNI 。

Answer 2

我认为这有两个方面，UI 和检测部分。

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]-->

很明显，使用 IE6 或更低版本 的任何人都很有可能使用 Windows XP 并且不支持 SNI。其他欺骗用户代理的人在这里并不重要。

服务器端

1. 嗅探用户代理。单元测试完成后将提出正则表达式。
2. 使用上面的 AJAX 实现。

特别说明

使用 AJAX 解决方案可为您提供 99% 的防弹检测，但不符合一些 Web 开发原则。

• 渐进式增强 - 您向所有用户发出相同的 AJAX 请求。支持 SNI 的用户不必担心。
• 遗留 - 您无法轻易弃用此代码。
• 如果您在 AJAX 请求中使用 jQuery，则可能会影响依赖于 $.ajaxStop() 方法的代码。

Answer 3

我可以分享我的经验和方法，从虚拟托管环境（每台服务器多个域）中每个证书一个 IP 切换到所有域一个 IP 的负载平衡环境。

我们查看了我们的分析（超过 100 万独立访问者/月），其中大部分是希望在线购买汽车零部件的北美男性用户，并在 2014 年 3 月 8 日发现，大约 4% 的用户在 Windows XP 上使用 Internet Explorer（其他都是次要的——最坏的情况下，总用户的 4.5% 将受到不支持 SNI 的影响）。请记住，我们无法“控制”这些用户，因此我们无法告诉他们切换浏览器。这一比例也在快速下降，至少在美国是这样。

我们首先认为，对于非 SNI 客户来说，与支持 SNI 的客户相比，获得稍有不同的体验是“可以的”。

我们的方法是检测服务器端（使用 UA 字符串）哪个浏览器/操作系统组合不支持 SNI（正如其他人提到的：有关 SNI 支持的维基百科文章）。我们所有的域（~ 120）都有一条 A 记录，指向单个负载平衡 IP。我们有一个名为 generic-autoparts.com 的域的第二个 IP（也是负载平衡的）。

所以设置是[我不与我在下面的示例中使用的任何域关联]：

mikesautoparts.com --> IP X 的名称服务器记录
dansautoparts.com --> IP X 的名称服务器记录
jensautoparts.com --> IP X 的名称服务器记录
...等

generic-autoparts.com --> IP Y 的名称服务器记录

如果客户点击 http://www.dansautoparts.com，并且支持 SNI，则不会发生任何情况。他浏览 dansautoparts.com，结账时使用 https://www.dansautoparts.com。

如果客户点击 http://www.dansautoparts.com，并且我们检测到他不支持 SNI，我们会立即将客户重定向到http://generic-autoparts.com/dansautoparts.com。他在那里购物，结账时使用 https://generic-autoparts.com/dansautoparts.com

现在，如果客户直接点击 https://www.dansautoparts.com（电子邮件中的链接、搜索引擎中的索引页面），您就出局了运气。他们会得到一个令人讨厌的证书错误。在我们的例子中，我们确保系统发送的所有电子邮件都不使用 https，并且我们知道搜索引擎尚未对我们的 https 页面建立索引。

每个环境都有不同的挑战和潜在的权衡。我们发现这在我们的案例中效果很好，客户会“接受”（或没有注意到）被重定向到 http://generic-autoparts。 com/[原始域名].com 。我们还通过 generic-autoparts.com 确保结账安全。

假设 20% 的非 SNI 用户注意到了重定向，这看起来很可疑，然后他们就离开了。在我们的案例中，这一比例为 0.8 - 0.9%（基于 2014 年 3 月 8 日的数字），我们愿意“接受”这一情况。我现在没有这方面的具体数据，但总体销售额保持稳定。 [编辑 2014 年 3 月 28 日：在更换 100% 的客户后，我们没有发现对销售产生任何影响]

2014 年 7 月 8 日实施更新

事实证明，不可能静态检测到每个 UA 代理字符串服务器。我们实现了以下 JavaScript 来检测浏览器的 SNI 功能。一般方法是针对需要 SNI 的域执行 JSONP 请求（Apache 通过“SSLStrictSNIVHostCheck on”支持此操作）。如果 JSONP 请求因超时而失败，我们会将客户重定向到非SNI 域。

更复杂的是，我们不想仅仅因为 SNI_TEST_DOMAIN 关闭就重定向每个人。如果 JSONP 请求失败（由于无法直接检测 JSONP 失败而导致超时），我们将通过执行 HTTP“运行状况检查”请求来验证服务器是否可用。此外，我们不想在每次页面加载时运行此 JavaScript 代码，因为这会增加出现奇怪超时和错误重定向许多客户的可能性，因此我们在 SNI 检查完成后设置一个会话变量，这样就不会发生这种情况当客户浏览网站时再次进行。

我们知道，由于 JSONP 超时不可靠，我们得到了某些错误检查，这些检查失败了，但自从实施此功能以来，我们没有收到客户的投诉。

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 4

您引用的维基百科文章列出了支持的浏览器和服务器版本。例如，Internet Explorer 7（Vista 或更高版本，而非 XP）或更高版本以及 Mozilla Firefox 2.0。除非您知道所有访问者都使用受支持的浏览器，否则您无法使用 SNI（一个 IP 地址上有多个证书），除非将他们与您网站的 SSL 部分切断。

Answer 5

问题是Windows XP客户端和Android < 3.0 客户端。不幸的是，他们加起来仍然占我们许多网站访问者的近 10%。此外，虽然黑莓用户数量较少，但他们是我们的一些付费客户。 XP、Blackberry 和 Gingerbread 的结合使得 SNI 目前（2015 年 2 月）在我们的大多数网站上不被接受。我预计这个问题会在一两年内消失。

2016 年 11 月更新（21 个月后）：访问一个相当标准的网站，每月约有 10,000 次访问。 2013 年 1 月 ~10% 为非 SNI。 2014 年 1 月 ~6%，2015 年 1 月 <2%，2016 年 1 月 ~0.5%，2016 年 11 月 ~0.1%（千分之一）。我们于 2015 年 11 月/12 月进行了切换。但是，某些市场可能拥有更多的此类用户。我在 Google Analytics 中创建了自定义受众群体，因此很容易看到影响。只需按操作系统名称、版本开头即可定义，对于 XP，浏览器为 IE。

Answer 6

Windows XP 上的 Internet Explorer（所有版本；6、7 和 8）不支持 SNI。其他人都工作。我真的不知道 XP 上有多少用户使用 Internet Explorer，但这是无法使用 SNI 的用户的神奇数量。

移动支持：

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

Answer 7

是的，

您将无法支持 XP 与 SNI 的 SSL 连接。但是，允许 XP 客户端连接无论如何都不符合某些标准，因此您可能必须出于其他原因删除这些用户。

2016 年这一比例仅为百分之几，并且还在下降。如果您必须使用 SSL 支持每个用户，那么您将需要动态切换，但如果您只需要绝大多数......当然。

Answer 8

我很晚才回答这个问题，但对于所有可能对这种解决方案感兴趣的读者来说。只需使用服务器端功能检测浏览器和操作系统，并告诉访问者使用“安装并使用 Chrome 或 Firefox 等安全浏览器进行在线购物，并提供下载和安装的链接。”

这是确保客户购物安全的最佳方式，这有两个目的，一是启用 SNI 的 SSL 使用，二是确保客户的“购物安全”。因为无论服务器是否使用启用 SNI 的 SSL，XP 上那些过时的浏览器确实不安全。

我们可以冒这个风险，因为在美国，在 XP 上使用旧版 IE 的用户比例低于 5%，而在其他国家/地区可以忽略不计或为零。事实上，其他国家的人们已经习惯了开源浏览器。

根据我自己的经验，我为自己和许多客户托管了许多网站，并且我使用 SNI 技术为所有网站提供了 SSL，无需专用 IP，而且我非常确定许多国家/地区的人们已经转向 Chrome 或 Firefox，几乎所有国家/地区在美国，95%。

如果有任何不准确的信息，请原谅我。