Перенаправляет http на https плохую идею?

Я читаю эту страницу, и он говорит, что если сайт является SSL и пользователь пытается получить к нему доступ через обычный http, приложение не должно перенаправлять пользователя на https. Он должен просто заблокировать его. Может ли кто-нибудь проверить достоверность этого? Это не похоже на хорошую идею, и мне интересно, что представляет собой реальный риск просто перенаправлять пользователя на https. Похоже, что за этим нет технических причин, просто чтобы это было хорошим способом обучить пользователя.

Отключить HTTP-доступ к домену, даже не перенаправлять или не связывать его с SSL. Просто сообщите пользователям, что этот веб-сайт недоступны через HTTP, и они для доступа к ней через SSL.

Это лучшая практика против MITM и phising атак. Таким образом, ваш пользователи получат приложение никогда не доступно через HTTP и когда они сталкиваются с фазе или атака MITM, они будут знать что-то не так.

Один из лучших способов защитить ваши приложения против атак MITM и Атаки phising - это пользователей.

Ответ 1

HTTP-запрос, содержащий файл cookie идентификатора сеанса, подвержен атакам захвата сеанса. Важно, что если вы разрешаете HTTP и перенаправляете HTTPS, эти файлы cookie помечены как безопасные.

Я не вижу никакой технической причины, по которой HTTP также должен быть полностью заблокирован, и многие сайты перенаправляют HTTP на HTTPS. При этом очень важно реализовать HTTP Strict Transport Security (HSTS), который является механизмом веб-безопасности, который заявляет, что браузеры должны использовать только HTTPS-соединения.

HSTS реализуется путем указания заголовка ответа, такого как Strict-Transport-Security: max-age=31536000. Соответствующие пользовательские агенты автоматически превратят небезопасные ссылки в безопасные ссылки, тем самым уменьшив риск нападений "человек-в-середине". Кроме того, если существует риск того, что сертификат не защищен, например, полномочия root не распознаются, затем отображается сообщение об ошибке, и ответ не отображается.

Ответ 2

Переход от HTTP к HTTPS на самом деле является не очень хорошей идеей. Например, злоумышленник может атаковать "человек в середине" с помощью инструмента, такого как ssl strip. Чтобы решить эту проблему, вы должны использовать протокол

Ответ 3

Я не вижу никаких технических рисков (кроме тех, что были в обновлении в конце моего ответа) при перенаправлении с HTTP на HTTPS. Например, gmail и почта yahoo делают это. Вы можете проверить это, используя инструмент отладки HTTP (например, Fiddler), где вы можете четко указать ответ перенаправления 302, возвращаемый сервером.

Я считаю, что блокирование - плохая идея с точки зрения юзабилити. Много раз пользователи вводили адрес в браузере без указания HTTP или HTTPS. Например, я обращаюсь к gmail, набрав "mail.google.com", по умолчанию "http://mail.google.com" и автоматически перенаправляется на "https://mail.google.com". Без автоматического перенаправления мне всегда нужно будет ввести полный адрес.

Я согласен с цитируемой статьей, что HTTPS - лучший метод против атак MITM, но я не согласен, что это лучшая практика против phising. Обучение пользователей действительно является ключевым фактором для атаки phising (пользователи должны проверить, что они обращаются к сайту из правильного домена), но вы никоим образом не делаете это образование, блокируя перенаправление HTTP на HTTPS.

Обновление @Pedro и @Spolto правы. Необходимо проявлять особую осторожность в отношении чувствительных файлов cookie (например, сеансовых или файлов cookie аутентификации), которые действительно должны быть помечены как безопасные, так что они будут передаваться только через HTTPS. Я пропустил это. +1 оба вы, ребята.

Ответ 4

Я только что заметил этот вопрос, но я написал пару ответов на похожие вопросы:

Я не думаю, что перенаправление с HTTP на HTTPS обязательно вредно, но это нужно делать с умом. Важно то, что вы не должны полагаться на эти автоматические перенаправления, которые должны присутствовать на этапе разработки. Их лучше всего использовать для пользователей, которые сами набирают адрес в браузере.

Это также исключительно ответственность пользователя за проверку, чем использование HTTPS (и что сертификат проверяется без предупреждения), когда они этого ожидают.

Фактические риски перехода с HTTP на HTTPS - это то, что вы можете надежно доверять тому, что было сделано перед коммутатором, если вы решите сохранить сеанс. Поток и процесс вашего сайта должны учитывать это.

Например, если ваши пользователи просматривают ваш сайт для покупок и добавляют в корзину различные элементы, используя HTTP, и вы планируете использовать HTTPS для получения реквизитов платежа, вы также должны заставить пользователя подтвердить содержимое своей корзины с помощью HTTPS.

Кроме того, при переключении с HTTP на HTTPS вам может потребоваться повторная аутентификация пользователя и сброс простого идентификатора сеанса HTTP, если таковой имеется. В противном случае злоумышленник может использовать этот файл cookie для перехода к этому разделу HTTPS сайта и потенциально олицетворять законного пользователя.

Ответ 5

С технической точки зрения, IMO не имеет побочных эффектов, кроме того, что принимает HTTPS.

С точки зрения UX/UI рекомендуется использовать переадресацию через клик или задержку, предоставляя визуальную индикацию, чтобы спросить людей, набирающих URL HTTPS, в первую очередь, поскольку само перенаправление подвержено атаке MITM. Однако не так много веб-сайтов HTTPS, потому что они предоставляют визуальные подсказки, чтобы люди искали значок блокировки в браузере на своих страницах HTTPS.

Ответ 6

Это совершенно приемлемый метод "начальной загрузки" - 301 перенаправление с HTTP на HTTPS, а затем на стороне HTTPS возвращает заголовок Strict-Transport-Security, чтобы заблокировать браузер в HTTPS.

Было бы большой проблемой юзабилити, чтобы полностью блокировать HTTP, поскольку веб-браузеры будут пытаться использовать HTTP-протокол, когда URL-адрес вводится без указателя протокола, если браузер не поддерживает HSTS, а токен HSTS находится в кеше браузера или список предварительной загрузки.