Хром ошибка - сила-всегда с SSL



С 10 минут chrome принудительно вводит SSL-сертификат в поддомены моего сайта.



Мой сайт: https: / /www.mywebsite.com - > SSL OK установлен



Поддомены: http://forum.mywebsite.com - > SSL не установлен



Теперь "хром" заставляет мой форум идти под SSL, возможно потому, что всегда посещает основной сайт, где он принудительно SSL, но это не имеет смысла. На IE, Firefox и других версиях Chrome ничего не происходит, только на этом ПК с Chrome.



У меня нет установленных расширений, а также антивирусов, которые заставляют защищенные соединения, такие как Kaspersky.



Это взято из журнала: chrome: / / net-internals / # events



17239: URL_REQUEST 
http://forum.mywebsite.com/
Start Time: 10/24/2014 22: 14: 16,596

t = -633,892 [st = 0] + REQUEST_ALIVE [dt =?]
                   -> Has_upload = false
                   -> Is_pending = true
                   -> Load_flags = 3384432 (BYPASS_DATA_REDUCTION_PROXY | main_frame | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                   -> Load_state = 0 (IDLE)
                   -> Method = "GET"
                   -> Status = "SUCCESS"
                   -> Url = "http://forum.mywebsite.com/"
                   -> Url_chain = ["http://forum.mywebsite.com/","https://forum.mywebsite.com/"]
543   2  

2 ответов:

В ответе HTTP с сайта HTTPS найдите HSTS в заголовках.

Http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Это будет делать то, что вы описываете; это может заставить Родительский домен и все поддомены всегда быть HTTPS.

Edit: вот более подробная информация, для тех, кто заинтересован.

Обычно пользователь приходит на ваш сайт по протоколу HTTP. Если вы затем хотите защитить их соединение, вы перенаправляете их на ту же страницу, но HTTPS. Проблема в том, что перенаправление происходит по сети, в HTTP, который не является безопасным. Атака "человек в середине" может заблокировать обновление и оставить пользователя застрявшим в HTTP; хуже того, они могут не осознавать, что на них нападают. Вы можете предложить свой сайт только в HTTPS, но тогда пользователи, которые пытаются использовать ваш сайт в HTTP, подумают, что ваш сайт не работает, и это тоже плохо.

Таким образом, HSTS (HTTP Strict-Transport-Security) является решением проблемы. Он поддерживается большинством современных браузеров (Chrome / Firefox, я думаю, Safari и IE12 будут иметь его.) Старые браузеры игнорируют его.

HSTS применяется для каждого домена. После ВПЖ активна yoursitehere.com если пользователь введет http://yoursitehere.com в браузере, браузер делает что-то другое, вместо того, чтобы связываться с yoursitehere.com используя HTTP, он переписывает запрос на HTTPS до, попав в сеть. Это смягчает человека в середине атаки.

Есть два способа включить HSTS. Один заключается в использовании заголовок ответа HTTP, который должен подаваться по протоколу HTTPS. Другой способ заключается в обращении к браузерным компаниям (Google, Apple, Mozilla, Microsoft) с просьбой добавить их в "список предварительной загрузки HSTS", который является конфигурационным файлом, поставляемым вместе с браузером.

Если это включено с заголовком ответа, есть еще одна дополнительная опция; на сколько секунд это должно быть включено?

При любом способе запуска есть один основной вариант. "includeSubDomains", который был задан о. Если includeSubDomains установлен, вместо простого включения yoursitehere.com... это также будет включать в себя www.yoursitehere.com, mail.yoursitehere.com, static.yoursitehere.com и так далее.

Это опасная вещь, чтобы включить, не проверив немного сначала.

Перемещение сайта на HTTPS может выделить ошибки смешанного контента; некоторые браузеры помещают их в консоль, некоторые всплывают, но это страница HTTPS, использующая ресурсы HTTP. Если ваш сайт уже поддерживает HTTPS все время, это не проблема.

Опять же, это также опасно, потому что это-домен, а не путь.

Итак, если yoursitehere.com/your-application хочет HSTS, но yoursitehere.com/another-teams-application нет, один продукт / сервер может принудительно включить его для всех, если они все сопоставлены под одним доменом.

Google (Gmail, Drive и т. д.), Twitter, Facebook, Paypal и другие используют это уже некоторое время.

Возможно, сервер отправляет редирект на этот конкретный браузер из-за того, как он идентифицирует себя.

Если вы откроете инспектор разработчиков и выполните запрос, какой код возврата вы получите от вашего первоначального запроса?

Comments

    Ничего не найдено.