У меня есть определенная часть моего сайта, которая защищена SSL, который зарезервирован для зарегистрированных пользователей, и хочу, чтобы остальная часть сайта, которая открыта для публики, обслуживалась только по http. В настоящее время он настроен так, что все страницы, будь то общедоступные или иным образом, обслуживаются по https. Кроме того, как общедоступный, так и непубличный контент находится в одном корневом веб-каталоге.
Не могли бы вы предложить мне способ решить эту проблему или, возможно, руководство по передовой практике? Спасибо!
РЕДАКТИРОВАТЬ
Мы используем стек LAMP.
Во-первых, имейте в виду, что обслуживание смешанного контента может вызывать предупреждения браузера, которые говорят пользователю, что не все, что они видят, является «безопасным контентом».
Во-вторых, если вы не испытываете проблем с производительностью или задержкой, вероятно, не стоит прилагать усилия для разделения защищенного и незащищенного содержимого. Предельная нагрузка на сервер, создаваемая SSL, в наши дни довольно мала по сравнению с 10-12 лет назад, и большая часть воздействия вызвана первоначальным согласованием соединения, которое произойдет независимо от того, что, если какая-либо часть вашего сайта требует SSL. .
Тем не менее, если вам нужно повышение производительности, и вы не против потенциального замешательства / раздражения пользователя, я бы рекомендовал настроить хост с отдельным именем (например, если ваш защищенный веб-сайт www.sample.com, зарегистрируйтесь, например, static .sample.com в качестве CNAME / псевдонима для этой записи DNS (или в качестве отдельного IP-адреса, если вы чувствуете себя экстравагантным)), настраивая новый VirtualHost в Apache для этого имени без включенного SSL, а затем используйте это местоположение для хранения ваших статических содержание.
Если вам необходимо разделение содержимого SSL и не-SSL по каталогам, лучший способ - настроить второй VirtualHost в Apache, который будет прослушивать порт 80 и указывать на то же место, где указан ваш SSL VirtualHost, а затем добавить перенаправляет URI, которые вам необходимо зашифровать. Например:
<VirtualHost *:80>
ServerName www.sample.com
DocumentRoot /var/www/www.sample.com
Redirect permanent /secure https://www.sample.com/secure
</VirtualHost>
<VirtualHost *:443>
Servername www.sample.com
DocumentRoot /var/www/www.sample.com
SSLEngine On
</VirtualHost>
(Я, очевидно, многое упустил, не пытайтесь копировать и вставлять.)
Лучше всего не смешивать трафик http и https. Смешанный контент может представлять угрозу безопасности. Злоумышленник может настроить не-SSL-трафик таким образом, чтобы получить доступ к части SSL.
В частности, опасен Javascript. Но они могут изменить изображение, которое изменяет инструкции, показанные на странице. В прошлом в браузерах также были уязвимости изображений и css.
Другое обсуждение Вот.
Если вы действительно хотите, это довольно просто. Имейте два хоста apache vhosts, один SSL и один нет; но в остальном то же самое. Затем в своем php-коде укажите соответствующие URL-адреса.
Я это сделал для многих своих сайтов. Например, сайт не поддерживает SSL до вашего входа в систему, а затем полностью SSL.
Этот псевдоконфигурация для Apache будет делать то, что вам нужно: два виртуальных хоста, один с SSL, и перенаправлять с требуемого SSL пути на HTTPS-версию сайта.
<VirtualHost *:80>
ServerName www.sample.com
DocumentRoot /var/www/www.sample.com
Redirect permanent /secure https://www.sample.com/secure
Redirect permanent /secure2 https://www.sample.com/secure2
</VirtualHost>
<VirtualHost *:443>
Servername www.sample.com
DocumentRoot /var/www/www.sample.com
SSLEngine On
</VirtualHost>
После того, как вы предоставили своим пользователям cookie-ключ для их личности, лучше всего оставить их на SSL-версии сайта, чтобы, например, их cookie-файлы не могли быть перехвачены злонамеренными пользователями через их незашифрованное беспроводное соединение с кофейней. У вас есть несколько вариантов, как заставить это работать. Либо используйте язык вашего приложения (например, PHP) для обнаружения файла cookie, а затем перенаправьте его на версию SSL текущей страницы, либо вы можете использовать mod_rewrite для принудительного использования SSL при наличии файла cookie. Но это другой вопрос ...
Лучшая практика состоит в том, чтобы обеспечить доступ к защищенным страницам только через HTTPS, а к не-HTTP-страницам нельзя обращаться через HTTPS. Используя такой язык, как PHP, вы можете обнаружить это и перенаправить пользователя на соответствующий протокол. Вы также можете настроить это через mod_rewrite, если необходимо.
Одна проблема, которую вы можете заметить, заключается в том, что если вы обслуживаете страницу через HTTP и идет атака MITM, злоумышленник может манипулировать HTML и изменять формы и ссылки, чтобы вместо этого перейти на HTTP, чтобы злоумышленник все еще мог отслеживать. Таким образом, даже если вы заставляете доступ к странице только через HTTPS, злоумышленник все равно отслеживает любые конфиденциальные данные.
В настоящее время предлагается решение этой проблемы: Строгая безопасность транспорта HTTP который уже используется на некоторых сайтах. Это приводит к принудительному использованию HTTPS в браузере, поэтому даже если действие формы было искажено через MITM, браузер не отправит его через HTTP.
Если вы смешиваете содержимое https и http, клиент получит ошибку «Предупреждение о неавторизованном содержимом».
Apache фактически затрудняет смешивание такого контента - сайты SSL и не-SSL должны быть определены в отдельных vhosts - вам просто нужно убедиться, что деревья каталогов не перекрываются.