Por que um certificado SSL não assinado é tratado pior do que nenhum certificado SSL?

Question

Se eu visualizar um site que tenha um certificado SSL não assinado ou autoassinado, meu navegador me avisará. No entanto, o mesmo navegador não tem problemas em permitir o envio de credenciais através de páginas não seguras.

Por que o certificado auto-assinado é tratado pior do que não ter certificado?

    

Answer 1

Há muitas pessoas que acham que esse sistema está quebrado.

Veja a lógica por trás do motivo pelo qual o seu navegador fornecerá um aviso tão alarmante quando um certificado SSL for inválido:

Um dos propósitos originais de design da infraestrutura SSL foi fornecer autenticação de servidores da web. Basicamente, se você for ao www.bank.com, o SSL permite que o servidor web que responde prove que ele pertence ao seu banco. Isso impede que um impostor manipule o DNS ou use outro método para que um servidor malicioso responda.

O "Trust" no SSL é fornecido por um terceiro confiável (empresas como VeriSign e Thawte Consulting) assinar o certificado, indicando que ele confirmou que ele é de propriedade de quem ele diz ser (em teoria, visitando o site). Administrador de TI em pessoa ou outro método que cria confiança direta, embora as evidências mostrem que eles são realmente um pouco negligentes - tudo o que é necessário para obter um certificado SSL assinado é geralmente um número 800 e um pouco de habilidade de atuação).

Portanto, se você se conectar a um servidor da Web que forneça um certificado SSL, mas não seja assinado por terceiros confiáveis, isso poderia significar que você está se comunicando com um impostor que está fingindo ser um servidor pertencente a uma organização diferente.

Na prática, um certificado auto-assinado geralmente significa apenas que a organização que executa o servidor optou por não pagar por um certificado assinado (eles podem ser muito caros, dependendo dos recursos desejados) ou não tinha o conhecimento técnico necessário. configure um (algumas soluções de pequenas empresas oferecem um mecanismo de um clique para um certificado autoassinado, mas a obtenção de um certificado confiável requer etapas mais técnicas).

Pessoalmente, acredito que esse sistema está quebrado e que comunicar-se com um servidor que não oferece criptografia é muito mais perigoso do que se comunicar com um servidor que oferece SSL com um certificado autoassinado. Existem três razões pelas quais os navegadores não agem assim:

1. Comunicações não criptografadas são a norma na internet, por isso, se os navegadores fizerem com que você clique em um aviso para visualizar sites que não oferecem criptografia, você ficará rapidamente irritado e desativará o aviso.
2. Devido aos terríveis avisos aos clientes, é anormal ver um certificado autoassinado em um site de produção. Isso estabelece um sistema de autoperpetuação: os certificados auto-assinados são suspeitos porque são raros, são raros porque são suspeitos.
3. Isso soa cínico para mim, mas existem empresas que ganham muito dinheiro com a assinatura de certificados SSL ( cough Verisign cough ), então eles use whitepapers (um termo de TI que significa "anúncio longo e chato") e outras publicações para impor a ideia de que os certificados não assinados são perigosos.

Answer 2

O envio de credenciais de uma página para outra está basicamente fazendo HTTP POST. Não há nada de especial sobre o envio de credenciais em comparação com o envio, por ex. Termos de pesquisa via POST.Se qualquer post para a página não segura provocasse um aviso, os usuários seriam bombardeados por avisos inúteis.

O uso de canal seguro indica a intenção do programador de proteger a transferência. Neste caso, usar aviso de certificado autoassinado é uma coisa muito certa a fazer.

    

Answer 3

As conexões protegidas pelo protocolo https: // são indicadas pelo navegador para serem "protegidas". Por exemplo, um pequeno cadeado é exibido ou partes do URL são marcadas em verde.

Portanto, o usuário deve confiar que as páginas que ele está visitando são realmente da URL em que ele entrou e não são de outra pessoa.

Se ele não estiver usando https: //, o usuário deve saber que os dados inseridos não estão protegidos e o site em que ele está navegando pode ser impostado.

Um certificado auto-assinado não garante que a expectativa de que a página foi explorada não é imposta, portanto, não oferece segurança extra.

    

Answer 4

Eu não posso comentar, então vou postar esta informação que complementa as informações corretas do user40350.

Yet the same browser has no problem allowing credentials to be sent across unsecured pages.

Isso nem é verdade. A maioria dos navegadores mostrará um aviso como você está prestes a enviar dados por uma conexão não segura quando tentar, mas pode desativá-lo para que ele nunca seja exibido novamente, e aposto que é exatamente isso você fez ...

Miro A escreveu:

Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST

Isso também é incorreto, já que os campos de senha são tags html especiais, por exemplo. Além disso, os rótulos como "nome de usuário" e "senha" também revelam grande parte de sua sensibilidade. Seria perfeitamente viável para os navegadores levarem em conta esse tipo de informação.

    

Answer 5

Uma distinção deve ser feita entre um certificado confiável (assinado por uma autoridade confiável) e um não confiável. Caso contrário, alguém pode se passar por um banco (por exemplo) usando um certificado autoassinado com relativa impunidade.

Um aviso direto é preferível a um sutil neste caso, porque o risco potencial é relativamente alto. As pessoas podem clicar em um link https e nem pensar que alguém pode estar sentado no meio monitorando a conexão. Se a indicação de que o certificado não é confiável é sutil (digamos, um ícone vermelho em vez de verde, etc), então as pessoas poderiam ser facilmente enganadas, removendo os benefícios do SSL.

    

Answer 6

Muitas boas razões foram listadas. Aqui está mais um:

Pense nos casos em que uma página da Web segura incorpora elementos de outra. Um invasor pode detectar quais solicitações são para a página da web externa (digamos, olhando para o tempo, ele precisa vir primeiro) e quais são para os elementos internos. Ele poderia se injetar como um MITM apenas nos elementos internos, usar um certificado autoassinado e controlar partes da página. A menos que um aviso tenha sido apresentado para os elementos internos usando SSL, mas não usando um certificado confiável, a segurança da página externa seria comprometida.

Aqui está um exemplo realista. Digamos que sou um fornecedor e tenho um link "pagar com o PayPal". Você clica sobre isso e eu sei. Eu o redireciono para o PayPal e deixo você obter a legítima e segura página do PayPal. Se eu estiver assistindo à sua rede, sei que essa será sua primeira solicitação do PayPal e, logo em seguida, você enviará sua senha. Então eu MITM o submit contendo seu endereço de e-mail e senha, substituindo meu certificado autoassinado pelo PayPal.

Você vê como a segurança da página externa é comprometida por não avisar se o certificado da página interna é autoassinado? Por isso, deve avisar sobre certificados autoassinados provenientes de links.

E, claro, se você inserir https manualmente, ele deverá avisar você. Porque você espera que seja seguro.

    

Answer 7

Quando o homem no ataque do meio é executado em https: // website o aviso é apenas indicação de algo errado para o usuário médio. Portanto, é parte muito importante da segurança HTTPS.

A boa pergunta é por que a criptografia parcialmente insegura não é possível no HTTP.