Olá,
às vezes, um fórum apresenta avisos de conteúdo misto. Veja agora o Let’s Encrypt:
Alguns favicons - http://alohadentalgroup.com/assets/icons/favicon.ico
Encontrado em https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
Não é possível alterar esses links para https ou ignorar esses links http?
Um fórum com conteúdo misto é ruim.
Esse URL de favicon não está hospedado no Discourse. Você está usando o Discourse? Qual é o URL da instalação?
Você tem o force_https ativado?
Se sim, faça o upload novamente dos seus ícones. Se não, ative-o e depois faça o upload novamente.
Não sei, não sou administrador do fórum Letsencrypt.
Mas se houver uma opção local, vou perguntar no fórum interno Regular.
PS: Obrigado por mover.
O aviso não é motivo de preocupação.
Um dos usuários do site do Let’s Encrypt adicionou uma URL em http neste tópico: Issues running certbot command - Help - Let's Encrypt Community Support.
Por esse motivo, o navegador avisa (corretamente) que há conteúdo misto.
Avisos de conteúdo misto são sempre ruins. É possível adicionar cookies via HTTP que são usados na próxima conexão HTTPS. Portanto, o software do fórum nunca deve iniciar conexões HTTP.
Especialmente em um fórum que discute “Meu certificado está errado” ou “Tenho avisos de conteúdo” (o certificado está correto, mas há conteúdo misto — primeiro certificado com esse domínio, os links precisam ser atualizados).
Esse favicon não está disponível via HTTPS. O aviso de conteúdo misto não é ideal, mas é preferível à confusão do usuário sobre por que os links não funcionam.
Eu sei. Mas é possível que um homem do meio use essa conexão HTTP iniciada pelo navegador para adicionar um cookie via HTTP. Mais tarde, o cookie é enviado do navegador via HTTPS — e o homem do meio conhece o cookie de sessão.
Isso funciona. O status HTTP (404, 301, 410, 500) não é relevante.
Isso é
não é um problema. O favicon não é um link iniciado pelo usuário; o usuário adiciona apenas o link HTTP ao site, sem HTTPS.
Solução simples: Sem pré-visualização se o destino for HTTP. Assim, não será necessário carregar o favicon.
Não em uma conexão de terceiros. O navegador não está enviando seus cookies do site do fórum para outro site, seja HTTP ou HTTPS.
Você está criando um problema onde não existe nenhum. Por favor, demonstre uma exploração disso no try.discourse.org se realmente acha que isso é um problema.
Isso não é o problema. Isso seria um bug do navegador.
Um homem no meio pode adicionar um cookie na conexão http://alohadentalgroup.com com o domínio alohadentalgroup.com, usando o nome conhecido de um cookie de sessão (se existir, não verifiquei isso) daquele domínio (não do domínio do fórum).
Se um usuário - mais tarde - usar o login de https://alohadentalgroup.com para gerenciar aquele domínio, esse cookie (criado via HTTP) será enviado de volta via HTTPS.
Essa é uma funcionalidade crítica (e muitas vezes desconhecida) dos cookies.
Essa é uma das razões pelas quais os cookies com prefixo são criados. Cookies que começam com __Secure- ou __Host- exigem HTTPS. Assim, isso não é mais possível. O mesmo vale para Preload (mas a maioria dos sites não usa HSTS e não está pré-carregado).
Veja (2017)
ou outros links.
PS: Minha ferramenta “verifique seu site” (veja meu perfil) tem uma página com alguns exemplos. E uma pequena demonstração. Um cookie criado via HTTP e enviado de volta via HTTPS. Via HTTP não é possível (com um navegador moderno) criar o cookie __Host-. Mas cookies com prefixo são raros.