Принудительно https весь сайт без перенаправления http на https


14

Было много дискуссий, пока я изучал, как сделать весь мой сайт https. Большинство ответов заключалось в том, чтобы перенаправить http на https (файл .htaccess), что не очень хорошо, потому что не стоит выполнять одну и ту же работу дважды (два запроса). Кроме того, «человек посередине» сначала берет http, и я хочу, чтобы мой сайт перешел прямо на https. Есть ли другой способ сделать весь сайт https и как это сделать? Например, когда пользователь вводит example.com, этот example.com автоматически переходит на https, без перенаправления с http или чего-либо еще в первую очередь?


если вы не хотите, чтобы люди были перенаправлены на https, что вы хотите вместо этого?
Майкл Хэмптон

@MichaelHampton Возможно, я задаю вопрос новичку, но я хочу практически «удалить» http, и единственное, что существует, это https. Или, если это невозможно, я мог бы просто использовать перенаправление, если оно достаточно для безопасности. Я слышал, что перенаправление http-> https не так хорошо, потому что это все еще http, и трафик может быть перехвачен во время перенаправления.
Марко Тамбурик

Постоянный редирект HTTP 301 - ваш друг, просто не забудьте установить срок действия.
Марсель

Вы можете просто удалить http. Но затем пользователь получает только сообщение об отказе в соединении, если он не вводит https: // Для некоторых сайтов это лучше, потому что безопасность выше. Если доступна версия http, может случиться так, что куки отправляются с первым незашифрованным первым запросом. Для таких вещей, как корпоративная почтовая система только https + обучение пользователей в порядке, для обычного сайта вы, вероятно, потеряете много посетителей.
Джозеф говорит восстановить Монику

Afaik стал возможен с HTTP2, однако он все еще не избежит атаки ssl чередование (описано в ответах ниже).
Петер - Восстановить Монику

Ответы:



22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security позволяет вашему серверу указывать, что доступ к домену должен осуществляться только через HTTPS. Это относится только к последующим запросам, поэтому будет начальная загрузка HTTP, но будущие запросы будут загружать HTTPS, даже если кто-то явно введет HTTP.

IE пока не поддерживает, но все остальные специализируются.


Это все еще не защищает от первого запроса.
Дженни Д

3
@JennyD Я уже точно сказал это в своем ответе.
ceejayoz

@JennyD Что вы подразумеваете под "защищать"? MiM не может ничего сделать с перенаправлением http -> https, если только он не связывается с локальным dns / маршрутизацией и не подделывает весь ваш домен. В этом случае не имеет значения, что вы делаете, поскольку к вашим серверам никогда не обращаются.
Red Alert

2
@JennyD Ну, HSTS - действительно лучшее решение, чем ваш пост, в котором говорится, что «редирект - это способ сделать это». Перенаправление может быть MITMed в любое время. Перенаправление с HSTS может быть выполнено MITMed только один раз в год для пользователя + браузера (или независимо от того, какое время истекло в заголовке) - все остальное время оно не запрашивается.
ceejayoz

1
@MarkoTamburic Нет причин, по которым вы не можете объединить их.
ceejayoz

7

Как уже говорили другие, вы не можете заставить пользователей выбрать правильный протокол. Но когда пользователь пытается использовать HTTP, что вы должны делать? Перенаправление также недостаточно, поскольку злоумышленник, сидящий между вами и клиентом, может перехватить перенаправление, поэтому клиент никогда его не увидит. Клиент продолжит отправлять обычный HTTP, а злоумышленник уберет слой SSL с сервера ( атака с разбором SSL ).

Единственный надежный способ предотвратить это - вообще не обслуживать HTTP . Не отвечайте на порт 80, за исключением, может быть, обслуживания простой текстовой страницы, предлагающей пользователю повторить попытку с HTTPS (но не предоставляя ссылку, которой злоумышленник может манипулировать). Это заставит пользователя вводить данные https://в свой браузер, поэтому он установит соединение с SSL и предотвратит атаку MITM.


3
Однако это компромисс, так как большинство пользователей не собираются печатать https://. Вместо этого они собираются сказать «да, сайт сломан» и уйти. В лучшем случае может быть www.example.comответ как по HTTP, так и по HTTPS, но само приложение работает на чем-то похожем admin.example.comтолько на HTTPS.
ceejayoz

Согласовано. На практике это практически никто не делает.
Эндрю Шульман

Я действительно не понимаю, как это было бы больше MiM-доказательство. Если человек посередине может изменить вашу гиперссылку, чтобы она указывала куда-то еще, это означает, что он контролирует входящие пакеты пользователя. Он может так же легко перенаправить на свой сайт или добавить любую гиперссылку, которую он хочет, независимо от того, как сайт должен выглядеть.
Red Alert

Но не теоретически, если клиент инициирует соединение с помощью SSL.
Эндрю Шульман

3
это правда - но если клиент начинает с SSL, у OP нет проблем. Его проблема в том, когда они инициируют без SSL, и нет никакого способа надежно получить их в SSL, если есть MiM, активно саботирующий это.
Red Alert


1

У ceejayoz есть лучший ответ, чтобы предотвратить специально упомянутую атаку здесь, но я хочу также указать, чего не хватает многим здесь людям, в основном то, что HTTP уже выяснил другую часть. Вы хотите сделать постоянное перенаправление 301. Это говорит клиенту делать дальнейшие запросы на новый адрес. Так что да, если кто-то введет неправильный URL-адрес, он сделает 2 запроса, НО, в будущем хороший клиент должен обнаруживать запросы на этот URL-адрес и вместо этого делать правильный запрос, чтобы предотвратить больше ненужных запросов. Проблема в том, что это только для этого точного URL. HSTS улучшает эту схему, также говоря: «в течение следующих n секунд также не разрешайте никаких незащищенных соединений из этого домена».

Пользователи не должны посещать конфиденциальные сайты в небезопасных местах. Они особенно не должны подписываться на них в небезопасных местах. Это основные принципы безопасности пользователей, которым нужно учить так же, как «не открывайте вложения из ненадежных источников». Это действительно лучший ответ для предотвращения атак MiM для сайтов, которые никогда не посещались.

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

Дополнительное чтение: http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.