Привет,
иногда на форумах возникают предупреждения о смешанном содержании. Посмотрите, например, здесь: Letsencrypt:
Некоторые фавиконки — http://alohadentalgroup.com/assets/icons/favicon.ico
Обнаружено в https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
Неужели нельзя изменить эти ссылки на https или игнорировать такие http-ссылки?
Форум со смешанным содержимым — это плохо.
Этот URL-адрес фавиконки не размещен в Discourse. Вы используете Discourse? Какой URL-адрес установки?
У вас включена опция force_https?
Если да, перезагрузите ваши иконки. Если нет, включите её, а затем перезагрузите.
Я не знаю, я не администратор форума Letsencrypt.
Но если есть локальная опция, я спрошу во внутреннем регулярном форуме.
PS: Спасибо за перемещение
Предупреждение не о чем беспокоиться.
Один из пользователей на сайте Let’s Encrypt добавил URL в http в этой теме: Issues running certbot command - Help - Let's Encrypt Community Support.
По этой причине браузер (правильно) предупреждает о наличии смешанного контента.
Предупреждения о смешанном контенте всегда плохи. Возможно добавить куки через http, которые используются при следующем соединении https. Поэтому программное обеспечение форума никогда не должно инициировать соединения по http.
Особенно в форуме, где обсуждаются темы вроде «Мой сертификат неверен» или «У меня есть предупреждения о контенте» (сертификат верен, но есть смешанный контент — первый сертификат с этим доменом, ссылки необходимо обновить).
Эта иконка сайта недоступна по HTTPS. Предупреждение о смешанном контенте не идеально, но оно предпочтительнее, чем путаница пользователей, когда они не понимают, почему их ссылки не работают.
Я знаю. Но возможно, что человек посередине использует такое инициированное браузером HTTP-соединение, чтобы добавить cookie через HTTP. Позже этот cookie отправляется браузером через HTTPS — и человек посередине знает сессионный cookie.
Это работает. HTTP-статус (404, 301, 410, 500) не имеет значения.
Это
не является проблемой. Favicon — это не ссылка, инициированная пользователем; пользователь добавляет только HTTP-ссылку на сайт без HTTPS.
Простое решение: не показывать превью, если адрес назначения — HTTP. Тогда не потребуется загружать favicon.
Не при подключении к стороннему ресурсу. Браузер не отправляет cookie форума на другой сайт, ни по HTTP, ни по HTTPS.
Вы создаёте проблему, которой не существует. Пожалуйста, продемонстрируйте уязвимость для этого на try.discourse.org, если вы действительно считаете это проблемой.
Это не проблема. Это был бы баг браузера.
Человек посередине может добавить куку в соединение http://alohadentalgroup.com с доменом alohadentalgroup.com, используя известное имя куки сессии (если она существует, я не проверял это) этого домена (не домена форума).
Если пользователь позже использует вход на https://alohadentalgroup.com для управления этим доменом, эта кука (созданная через HTTP) будет отправлена обратно через HTTPS.
Это одна из критических (и часто неизвестных) особенностей работы куки.
Именно поэтому создаются куки с префиксами. Для куки, начинающихся с __Secure- или __Host-, требуется HTTPS. Тогда это больше невозможно. То же самое касается Preload (но большинство сайтов не используют HSTS и не добавлены в preload-списки).
См. (2017)
или другие ссылки.
PS: Мой инструмент “проверьте ваш сайт” (см. мой профиль) содержит страницу с примерами. И небольшую демонстрацию. Кука, созданная через HTTP и отправленная обратно через HTTPS. Через HTTP невозможно (в современном браузере) создать куку с префиксом __Host-. Но куки с префиксами встречаются редко.