Назад | Перейти на главную страницу

Могу ли я определить, не поддерживает ли клиент 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-странице загрузите <script> с вашего конечного сервера SNI HTTPS, и если сценарий загружается и работает правильно, вы знаете, что браузер поддерживает SNI.

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

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

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