Могу ли я определить, не поддерживает ли клиент SSL индикацию имени сервера, и предоставить стандартный HTTP-сайт в этом случае?

Мне нужно будет использовать SSL SNI, но, к сожалению, из недавнего поста блога Cloudflare его поддерживают только 90% сети. Как я могу (например, с помощью nginx) определить, поддерживает ли клиент SNI, и предоставить / перенаправить на HTTP-версию веб-сайта? Это возможно? Как еще можно не потерять 10% трафика при использовании SNI? Правильно ли предположить, что я не смог бы перенаправить трафик HTTPS на HTTP без действительного сертификата, и, таким образом, этот запрос невозможен?

Спасибо.

Если вы хотите предложить HTTPS с самого начала, вы должны предоставить сертификат, принятый клиентом с самого начала. Потому что в противном случае клиент не примет SSL-соединение, и вы не сможете перенаправить клиента на другой сайт или версию только для HTTP. Это означает, что для поддержки этого случая вы

• либо нужно иметь один сертификат, содержащий все ваши домены, чтобы вы могли предоставить клиентам, не являющимся SNI, надлежащий сертификат. Но в этом случае вам вообще не нужен SNI.
• или вы должны установить сертификат по умолчанию, который не соответствует большинству ваших имен. В этом случае вы можете предоставить клиенту другую страницу или перенаправить ее только в том случае, если клиент примет этот неверный сертификат.

Если вам не нужно иметь HTTPS с самого начала, то есть если клиент обычно сначала подключается с помощью простого HTTP, то вы можете попытаться обнаружить поддержку SNI, чтобы позже можно было перенаправить клиент. Это может быть сделано путем добавления изображения, некоторого JavaScript или подобного материала с вашего HTTPS-сайта, и если загрузка прошла успешно, вы знаете, что клиент либо поддерживает SNI, либо игнорирует ошибки сертификата.

Конечно, это оставляет все открытыми для атак «человек посередине», потому что все, что нужно сделать человеку «посредник», - это обслуживать какой-то другой сертификат или вообще сделать HTTPS недоступным, потому что в этом случае вы никогда не попробуете обновить подключение к HTTPS. Кроме того, это можно использовать для того, чтобы заставить клиентов выглядеть как SNI, если вместо этого это делает посредник. И это касается не только не-SNI-клиентов, но и SNI-совместимые клиенты могут только перехватываться. Таким образом, хотя это было бы теоретически возможно, это не рекомендуется, потому что вы можете просто все посредничать и, таким образом, сделать основной смысл использования HTTPS спорным.

Как я писал в StackOverflow , вы можете протестировать только поддержку SNI, прежде чем потребовать ее. Таким образом, вы не можете принудительно заставить пользователей использовать SNI HTTPS, а затем откатиться, если они его не поддерживают, потому что они получат такую ​​ошибку (из Chrome в Windows XP) без возможности продолжить.

Поэтому (к сожалению) пользователь должен фактически начать через незащищенное HTTP-соединение, а затем обновляться, только если он поддерживает SNI.

Вы можете обнаружить поддержку SNI через:

1. Удаленный скрипт
   С вашей простой HTTP-страницы загрузите a <script>с целевого HTTPS-сервера SNI, и если скрипт загружается и работает правильно, вы знаете, что браузер поддерживает SNI.

2. Междоменный AJAX (CORS)
   Подобно варианту 1, вы можете попробовать выполнить междоменный AJAX-запрос со страницы HTTP к HTTPS, но имейте в виду, что CORS имеет только ограниченную поддержку браузера .

3. Обнаружение пользовательского агента.
   Вероятно, это наименее надежный метод, и вам нужно будет выбрать между черным списком браузеров (и операционных систем), которые, как известно, не поддерживают его, или белым списком известных систем, которые его поддерживают.

   Мы знаем, что все версии IE, Chrome & Opera для Windows XP и ниже не поддерживают SNI. Смотрите CanIUse.com для получения полного списка поддерживаемых браузеров .