Обновите HTTP-соединение до SSL / TLS


8

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

Существует ли какой-либо механизм, который пытается заставить браузер использовать HTTPS вместо простого HTTP, и когда это не работает (например, сертификат не принят или SNI не поддерживается), он продолжает использовать HTTP.

В настоящее время я использую Apache 2.4 с несколькими виртуальными хостами, с которыми все перенаправляют HTTP-соединение Redirect / https://domain.example/.


3
Переключение с HTTPS на HTTP, когда сертификат не верен, это то, что вам никогда не следует посещать в качестве посетителя. Тот факт, что сертификат является неправильным, должен быть признаком того, что что-то не так, и возврат к незашифрованному соединению - это худшее, что вы могли сделать тогда. Лучшее решение, которое у вас есть, это исправить ваш сертификат так, чтобы он совпадал с вашими именами хостов, используя другой CA или не используя SNI.
Теун Винк

Хорошо понял. Но когда мы ожидаем, что есть браузер, который не поддерживает соединения HTTPS или не поддерживает предоставленные механизмы шифрования от сервера. Тогда у этого клиента (в моем случае) нет возможности использовать сайт, потому что я автоматически перенаправляю на сайт, эквивалентный HTTPS.
лисичка

В современном мире вполне возможно преодолеть это ограничение. У очень крупных сайтов есть переходы только на SSL. Если они могут это сделать, вы можете сделать это.
MichelZ

Ответы:


15

Браузер никогда не должен сам понижать http до http, если https не работает, потому что все, что нужно сделать злоумышленнику, это сделать https недоступным (например, заблокировать порт 443). Таким образом, единственный способ сделать это - дать браузеру указание сделать это, например, отправив HTTP-редирект. Конечно, это должно быть отправлено по безопасному соединению (в противном случае посредник может подделать его), но, к сожалению, именно ваша проблема заключается в том, что безопасное соединение не удается.

В итоге: нет, это невозможно, и лучше так.

Кстати, все современные браузеры поддерживают SNI, но не все приложения (например, приложения Java и т. Д.) Поддерживают. Если у вас есть несколько доменов на веб-сервере, но только один, необходимый для этих приложений, вы можете установить сертификат для этого домена по умолчанию. В противном случае вам потребуется получить (более дорогой) сертификат, который содержит все необходимые домены в качестве альтернативных имен субъектов.

Редактируйте с другой идеей: то, что вы можете попытаться сделать, это загрузить изображение со своей стороны в виде https и проверить успешность с помощью обработчика ошибки на img-tag. Может быть, это не вызывает видимое пользователю предупреждение, а просто не загружается. И если это удастся, вы знаете, что доступ https возможен и перенаправить пользователя.

Кроме того, вы должны спросить себя, зачем вообще предлагать https, если вы также принимаете доступ с помощью http. Либо есть данные, которые должны быть защищены, либо их нет. Пока вы предлагаете откат к http, злоумышленнику легко применить http вместо https.


1
Очень хорошо заявлено.
Тим Бригам

3

Прежде всего, должна быть возможность указать один сертификат для использования для всех клиентов, у которых отсутствует поддержка SNI. Это означает, что все домены, размещенные на этом IP-адресе, могут иметь хотя бы один из них для клиентов без SNI.

То, что вы могли бы сделать при перенаправлении с http на https, - это двухэтапное перенаправление. При первом перенаправлении с http на https используется доменное имя, которое, как вы уверены, будет работать с поддержкой SNI или без нее. Должен быть включен полный исходный URL-адрес, чтобы с этого сайта https вы могли перенаправить его на нужный сайт.

Доменное имя, которое работает с SNI или без него, может вести себя по-разному в зависимости от того, поддерживается ли SNI клиентом. Таким образом, вы знаете, что клиент поддерживает SNI, прежде чем перенаправить его в домен, для которого требуется SNI.

Как именно настроить это на Apache, с моей стороны будет немного гадать (так как я никогда не настраивал Apache с более чем одним сертификатом). Я думаю, что способ сделать это будет создать виртуальные хосты на основе имен для всех доменов, включая промежуточный домен.

Затем создайте виртуальный хост по умолчанию для клиентов без SNI, который использует тот же сертификат, что и тот, который использует имя. Эти два виртуальных хоста с одинаковым сертификатом будут отправлять клиентам различное перенаправление в зависимости от того, поддерживают ли они SNI.

Наконец, я бы включил IPv6 на сервере. С IPv6 вы получаете достаточно IP-адресов, чтобы вы могли выделить один для каждого виртуального хоста. Один и тот же набор виртуальных хостов может иметь имя на основе IPv4 и IP на основе IPv6, поэтому вам не нужно дублировать любую конфигурацию таким образом.

Конечным результатом будет установка, которая работает, пока клиент поддерживает SNI или IPv6. Только клиенты, которые не поддерживают ни одного, будут тогда иметь проблему, но вы все равно сможете обнаружить их и отправлять серверу другое перенаправление или сообщение об ошибке.

Что касается клиентов, которым не нравится CA, мое единственное предложение - узнавать их по их пользовательскому агенту и обращаться с ними так, как вы считаете нужным. Убедитесь, что у вас есть ссылка на сайт https, по которой они могут перейти, если вы по ошибке включили слишком много клиентов.


0

Просто дикая догадка: может ли быть так, что в вашей конфигурации apache нет директивы SSLCertificateChainFile, которая включает файл sub.class1.server.ca.pem, необходимый для StartSSL?


Нет, все работает нормально, но некоторые старые браузеры либо не поддерживают SNI, либо не доверяют StartSSL.com. Проблема в том, что эти посетители не имеют возможности просматривать страницу, не игнорируя предупреждение сертификата (что не является решением).
лисичка
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.