Я могу найти различную информацию о SNI (см. Wikipedia), но я не могу найти статистику фактической поддержки в браузерах.
Лучшее, что я могу узнать, это то, что он должен работать на Windows XP с пакетом обновления 3 (SP3).
Кто-нибудь знает, действительно ли SNI можно использовать на практике?
Я могу поделиться своим опытом и подходами к переходу с одного IP-сертификата на виртуальную хостинговую среду (несколько доменов на сервер) в среду с балансировкой нагрузки с одним IP-адресом для всех доменов.
Мы посмотрели нашу аналитику (более 1 миллиона уникальных посетителей/месяц), в основном это пользователи из Северной Америки, которые хотят купить автозапчасти онлайн, и обнаружили 8 марта 2014 года, что примерно 4% пользователей были в Windows XP, используя Internet Explorer (другие были незначительными - худший случай 4.5% от общего числа пользователей пострадали бы от поддержки SNI). Имейте в виду, что у нас нет "контроля" над этими пользователями, поэтому мы не можем сказать им переключать браузеры. Этот процент также снижается довольно быстро, по крайней мере, в США.
Сначала мы решили, что для клиентов, не владеющих SNI, было "нормально", чтобы иметь несколько иной опыт, чем клиенты, поддерживающие SNI.
Наш подход заключался в обнаружении серверной части (с использованием строки UA), которая не поддерживает SNI (как упоминалось в других публикациях): Статья в Википедии о поддержке SNI). Все наши домены (~ 120) будут иметь запись A, указывающую на единый сбалансированный по нагрузке IP-адрес. У нас был второй IP-адрес (также с балансировкой нагрузки) для домена, который мы можем назвать generic-autoparts.com.
Итак, настройка [Я не связан ни с одним из доменов, которые я использую в качестве примеров ниже):
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 DIRECTLY (ссылка на адрес электронной почты, индексированная страница в поисковых системах), вам не повезло. Они получат неприятную ошибку сертификата. В нашем случае мы следили за тем, чтобы все электронные письма, отправленные нашей системой, не использовали https, и мы знали, что поисковые системы не проиндексировали наши https-страницы.
Каждая среда имеет различные проблемы и потенциальные компромиссы. Мы обнаружили, что это хорошо работает в нашем случае, и клиенты "принимают" (или не замечают) перенаправление на http://generic-autoparts.com/[ORIGINAL DOMAIN].com. Мы также сохранили контроль за безопасностью через generic-autoparts.com.
Скажем, 20% пользователей nonSNI замечают перенаправление, это кажется подозрительным, и они уходят. В нашем случае, что 0,8 - 0,9% (по состоянию на 8 марта 2014 года) пользователей, и мы были готовы "жить" с этим. У меня нет конкретных данных об этом прямо сейчас, но общие продажи сохраняются стабильно. [РЕДАКТИРОВАТЬ 3/28/2014: Мы не видели никакого влияния на продажи после того, как мы переключили 100% наших клиентов]
Обновление реализации 8 июля 2014 года
Оказывается, невозможно обнаружить каждую строку агента UA статически на сервере. Мы реализовали следующий JavaScript для обнаружения возможности SNI браузера. Общий подход заключается в том, чтобы выполнить запрос JSONP в отношении домена, для которого требуется SNI (Apache поддерживает это через "SSLStrictSNIVHostCheck on" ). Если запрос JSONP завершится с ошибкой, мы перенаправляем клиента в домен nonSNI.
Чтобы еще больше усложнить ситуацию, мы не хотим перенаправлять всех только потому, что 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";
}
Internet Explorer (все версии, 6, 7 и 8) в Windows XP не поддерживают SNI. Все остальные работают. Я действительно не знаю, сколько пользователей на XP используют Internet Explorer, но это волшебное число пользователей, которые не могут использовать SNI.
Мобильная поддержка:
Android default browser on Honeycomb or newer
Windows Phone 7
MobileSafari in Apple iOS 4.0 or later
Проблема - клиенты Windows XP и Android < 3.0 клиентов. К сожалению, они все еще почти 10% посетителей на многих наших сайтах. Кроме того, в то время как пользователи Blackberry имеют низкий объем, они являются одними из наших платежных клиентов. XP, Blackberry и Gingerbread вместе делают SNI неприемлемым на большинстве наших веб-сайтов в это время (февраль 2015 г.). Я ожидаю, что эта проблема уменьшится примерно через год или два.
Обновление в ноябре 2016 года (21 месяц спустя): переход на довольно стандартный сайт с ~ 10 000 посещений/мес. Январь 2013 ~ 10% non-SNI. Январь 2014 г. - 6%, январь 2015 г. < 2%, январь 2016 г. - 0,5%, ноябрь 2016 г. - 0,1% (1 из 1000). Мы сделали переключение в ноябре/декабре 2015 года. Однако на некоторых рынках может быть больше пользователей. Я создал пользовательскую аудиторию в Google Analytics, поэтому ее легко увидеть. Просто определите по имени ОС, начиная с версии, а для XP браузер - IE.
Вы не сможете поддерживать SSL-соединения из XP с помощью SNI. Тем не менее, разрешая клиентам XP подключаться, в любом случае не соответствует каким-либо стандартам, поэтому вам придется отказаться от этих пользователей по другим причинам.
Это всего лишь несколько процентов в 2016 году и падение. Если вы должны поддерживать каждого пользователя с помощью SSL, вам нужно будет динамически переключаться, но если вам просто нужно подавляющее большинство... конечно.
Я опаздываю в ответ на это, но для всех читателей, которые могут быть заинтересованы в таком решении. Просто определите браузер и ОС, используя серверную функцию, и попросите посетителя использовать "Установить и использовать безопасный браузер для покупок в Интернете, например, в Chrome или Firefox, и предоставить ссылку для загрузки и установки".
Это лучший способ сделать покупки безопасными для вашего клиента, и это служит двум целям: одному протоколу SSL, используемому SSL, и обеспечению безопасности покупок для клиентов. Поскольку эти устаревшие браузеры на XP действительно небезопасны независимо от сервера, использующего SSL с поддержкой SNI или нет.
Мы можем рискнуть этим, потому что процент пользователей, использующих старые версии IE на XP, составляет менее 5% в США, и в других странах он ничтожен или равен нулю. Фактически люди в других странах люди используются для браузеров с открытым исходным кодом.
Мой собственный опыт, я размещаю много веб-сайтов для себя, а также для многих клиентов, и у меня есть SSL для всех, использующих технологию SNI без выделенного IP-адреса, и я уверен, что люди перешли на Chrome или firefox во многих странах, почти все они и в США, 95% из них.
Простите меня за любую неточную информацию.
http://caniuse.com/#feat=sni в настоящее время говорит, что SNI поддерживается на 97,6% браузеров.
Я думаю, что есть два аспекта этого: пользовательский интерфейс и часть обнаружения.
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 or below, имеет большие шансы находиться на Windows XP и не поддерживает SNI. Другой, кто обманывает своего агента-пользователя, не имеет значения здесь.
Серверная сторона
Специальное примечание
Использование решения AJAX дает вам 99% -ное обнаружение пули, но не соответствует нескольким принципам веб-дизайна.