A conexão HTTPS "não é segura" devido a imagens


14

Atualmente, estou trabalhando em um site e instalei com êxito o meu certificado SSL.

O verificador GeoTrust SSL / TLS confirmou que a cadeia de certificados (incluindo CA) está instalada corretamente. Tudo parece bem no Chrome, mas meu cadeado não é verde e, no Firefox, ele afirma que o site não é seguro porque há elementos não criptografados.

Usei um serviço on-line para verificar por que isso ocorre e, de fato, minhas imagens não são consideradas URLs seguras. Como faço para lidar com essa situação, também conhecida como incorporar imagens no meu site com segurança?

Respostas:


32

No momento, suas tags de imagem devem ter a seguinte aparência:

<img src="http://example.com/images/image.jpg">

Isso httpsignifica que a imagem NÃO é veiculada com segurança. Um invasor pode alterar a imagem em trânsito e, assim, alterar a aparência de sua página segura para os usuários.

Em vez disso, você pode usar qualquer um dos seguintes itens para veicular as imagens com segurança:

  • Link para httpsexplicitamente:<img src="https://example.com/images/image.jpg">
  • Use links relativos a imagens em seu próprio domínio: <img src="/images/image.jpg">
  • Use a vinculação relativa do protocolo para usar imagens de outros domínios: <img src="//example.com/images/image.jpg">

O Explícito httpssempre exibirá a imagem com segurança (mesmo quando a página não for veiculada com segurança), enquanto os links relativos servirão a imagem com segurança somente se a página for veiculada com segurança.

No Firefox e no Chrome, você pode clicar no cadeado e obter mais informações sobre o problema. Feito isso, aqui está uma captura de tela do Firefox, mostrando uma lista de todas as imagens na página. É fácil escanear a lista e ver quais são http:


2
"Um invasor pode alterar a imagem em trânsito e, assim, alterar a aparência de sua página segura para os usuários". - ou até mesmo acionar uma vulnerabilidade no renderizador.
John Dvorak

2
E seqüestrar cookies, que podem incluir tokens de acesso.
Darkhogg

Parece muito que é aconselhável fazê-lo. Graças a você, consegui meu cadeado verde, mas um amigo disse que as imagens criptografadas podem diminuir a velocidade da página. Isso é um problema no meu caso?
M17_

3
Certamente há alguma sobrecarga na criptografia, no entanto, geralmente não é superior a 10% atualmente. Essa penalidade de desempenho (mesmo para imagens) é o preço que você paga por um site seguro.
Stephen Ostermiller

whynopadlock.com é uma ferramenta útil para localizar rapidamente os recursos não seguros em um URL específico.
Ville

5

O problema é que sua página está exibindo links de um local http em vez de https. Isso se deve ao uso de links http absolutos para fazer referência a recursos, como imagens. Existem dois métodos melhores que permitirão que você faça referência a links em http ou https e evite esse problema.

Requer que você encontre esses links e altere-os para:

  1. links relativos: ie./wp-content/yourtheme/images/image1.jpg
  2. ou coloque // na frente do domínio, como em //example.com/wp-content/wp-content/yourtheme/images/image1.jpg Isso servirá esses recursos por http ou https com base em qualquer solicitação feita.

No Chrome e no Firefox, você pode clicar no ícone do cadeado e clicar para visualizar uma lista dos links inseguros ofensivos. E se você não conseguir ver nenhuma imagem ou outros recursos destacados no navegador, mas ainda estiver recebendo erros, poderá descobrir que existe uma chamada javascript que faz referência a links absolutamente via http .


2
//no início não é padrão, e navegadores como o Lynx reclamam.
mirabilos

2
@mirabilos O RFC 1808 é o padrão para URLs e especifica os links relativos ao protocolo (começando com //) na seção 2.4.3. O padrão agora tem 15 anos e foi implementado por todos os principais navegadores, incluindo Lynx
Stephen Ostermiller

#mirabilos Verifique os links de repositório do Google recomendados. Você verá que o Google os utiliza há muitos anos.
Garth

1

É realmente básico. Quando você estiver criando sites servidos por SSL (https), qualquer referência no seu código que não seja precedida por https exibirá avisos de segurança - exceto links. Observe que a maioria dos navegadores (todos) também usa links relativos padrão para http. Portanto, se você referenciar /uploads/12/5/img.jpg ou /js/jquery.js, o protocolo de transferência será padronizado como http - o que é realmente irritante.

Todos os navegadores lidam com os avisos um pouco diferentes, mas você receberá algum tipo de mensagem. Uma declaração geral seria que, quanto mais novo o navegador, mais severa será a mensagem. Alguns navegadores mais antigos praticamente ignoram esses erros, enquanto navegadores mais novos podem agir como se seu mundo estivesse sendo atacado por causa dos "s" ausentes.


10
"a maioria (todos) os navegadores também usam links relativos padrão para http" Err, o que? Absolutamente todos os navegadores, a menos que estejam quebrados, usariam o protocolo atual se você não especificar um novo explicitamente.
Oleg V. Volkov

5
Oleg está certo; isso não é "irritante": está completamente errado.
Lightness Races com Monica

3
Isso está completamente errado. Desconsidere esta resposta.
martijnve

@martijnve - Como minha resposta está errada?
Blankip

4
@blankip veja o comentário de oleg V. Volkovs. Qualquer referência que inclua http está incorreta. Todos os outros estão bem. (relativo ao protocolo, relativo ao domínio, relativo ao caminho). E você deve usar links relativos em quase todos os casos de qualquer maneira.
martijnve

1

Se nenhuma dessas sugestões ajudar no que diz respeito à incapacidade de exibir imagens após a ativação do SSL em sua página da Web, verifique se as configurações de HotPages do cPanel estão na seção Segurança do cPanel. É muito possível que nessa configuração você tenha o seguinte: http://example.come http://www.example.comesteja habilitado para permitir o acesso às imagens enquanto a httpsversão delas não estiver ativada.


-4

Verifique a configuração do seu protocolo de URL seguro no seu cms / wordpress / magento ou em qualquer outra plataforma que você estiver usando. Você também pode compartilhar algumas de suas tags de imagem, mas as imagens img src básicas não fornecem esse tipo de erro.

A estrutura da tag da imagem é importante, mas acho que o foco da sua pergunta é relativo ao "tipo" de certificado SSL instalado no seu site. Um caso pessoal aconteceu comigo com um "Certificado SSL padrão GoDaddy.

Você verá um ícone de aviso na barra de pesquisa de URLs do Firefox, especificamente dizendo que pode haver imagens ou elementos inseguros no seu site. Até onde eu sei, é apenas uma questão de como o firefox processa informações sobre o certificado ou as informações incluídas nele. Isso não acontece no Safari, Chrome ou outros navegadores. Encontrei uma solução para isso, instalando em vez de um "SSL padrão" um "Certificado SSL Premium ou certificado de validação estendido EVC ", que possui informações mais detalhadas sobre a empresa do site. Você receberá uma barra de URL segura do cadeado verde.

No entanto, o certificado SSL premium pode ser um pouco mais caro, em torno de US $ 150 a US $ 200 por ano.

insira a descrição da imagem aqui


5
Isso não é verdade porque: 1) as tags <img src = "..."> podem realmente causar esse tipo de erro, se você inserir um URL HTTP (em oposição a um URL HTTPS) e 2) o tipo de certificado ou o forma como é processado não têm absolutamente nada a ver com isso
fNek

Eu uso para tags de mídia global img src como {{media url = "path / to / image.jpg"}} com ou sem protocolo ssl e não recebo erros. A propósito, estou apontando para o erro ssl do Stephen no Firefox exibido. Saudações.
Gaio RoOts

3
Se você usa URLs relativos, não há problemas, porque eles são relativos. Por favor, leia a outra resposta. Eu sei que você está se referindo ao erro de Stephen. Os tipos de certificado ainda não têm nada a ver com isso.
fNek

O tipo de certificado não afeta o chamado 'aviso de conteúdo misto'. Além disso, todos os navegadores modernos hoje em dia mostram o aviso, alguns claramente, outros simplesmente recusando-se a exibir o ícone Bloquear.
Martijn Heemels
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.