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

19

Se eu visualizar um site que possui um certificado SSL não assinado ou autoassinado, meu navegador emitirá um aviso. No entanto, o mesmo navegador não tem problemas em permitir que credenciais sejam enviadas entre páginas não seguras.

Por que o certificado autoassinado é tratado pior do que não ter um certificado?

— Macha
fonte

16

Muitas pessoas sentem que esse sistema está quebrado.

Aqui está a lógica por que seu navegador emitirá um aviso tão alarmante quando um certificado SSL é inválido:

Um dos propósitos de design original da infraestrutura SSL era fornecer autenticação de servidores da web. Basicamente, se você acessar o site www.bank.com, o SSL permitirá que o servidor da Web responda para provar que ele realmente pertence ao seu banco. Isso impede que um impostor manipule o DNS ou use outro método para que um servidor mal-intencionado responda.

A "Confiança" no SSL é fornecida por terceiros confiáveis (empresas como VeriSign e Thawte Consulting) assinam o certificado, indicando que verificaram que ele pertence a quem diz ser (em teoria, visitando o administrador de TI em pessoa ou outro método que crie confiança direta, embora as evidências mostrem que elas são realmente pouco exigentes - 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, em teoria, isso pode significar que você está se comunicando com um impostor que finge ser um servidor pertencente a uma organização diferente .

Na prática, um certificado autoassinado 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 que você deseja) ou não possuíam os conhecimentos técnicos necessários para configurá-lo ( algumas soluções para pequenas empresas oferecem um mecanismo de um clique para um certificado autoassinado, mas a obtenção de um certificado confiável exige etapas mais técnicas).

Pessoalmente, acredito que este sistema está com problemas e que a comunicação com um servidor que não oferece criptografia é muito mais perigosa do que a comunicação com um servidor que oferece SSL com um certificado autoassinado. existem três razões pelas quais os navegadores não agem assim:

As comunicações não criptografadas são a norma na Internet; portanto, se os navegadores fizerem você clicar em um aviso para exibir sites que não oferecem criptografia, você rapidamente se irritará e desativará o aviso.
Por causa dos avisos terríveis para os clientes, é anormal ver um certificado autoassinado em um site de produção. Isso estabelece um sistema auto-perpetuante: certificados autoassinados são suspeitos porque são raros, são raros porque são suspeitos.
Isso me parece cínico, mas há empresas que ganham muito dinheiro assinando certificados SSL ( tosse Verisign tosse ), então usam whitepapers (um termo de TI que significa "anúncio longo e chato") e outras publicações para reforçar a ideia de que certificados não assinados são perigosos.

— jcrawfordor
fonte

5

Sem uma cadeia de confiança, que é o que você obtém com um certificado assinado pela CA e não com uma assinatura automática, não há como verificar se o servidor ao qual você está se conectando é quem diz que é. Certificados autoassinados são perigosos no sentido de que eles não fornecem meios para que um usuário verifique se os dados que estão transmitindo estão chegando ao destino que afirmam. As pessoas estão começando a aprender a procurar "https" ao fazer transações seguras; portanto, ter um grande aviso sobre um certificado inválido ou autoassinado é 100% garantido, porque eles estão perdendo um dos principais benefícios do SSL.

— MDMarra

Eu não diria 'quebrado'. Eu acho que o complemento Firefox Certificate Patrol está muito mais próximo da implementação correta de certificados e do gerenciamento de confiança do que o padrão. Ainda assim, o padrão é melhor do que ignorar completamente as redes de confiança.

— precisa

4

@MarkM - Meu sentimento é que a autenticação não deve ser considerada o principal benefício do SSL. Não tenho os dados para me fazer backup, mas acho que muito mais incidentes de segurança resultam de dados transferidos por conexões não criptografadas (como exemplo, o engenheiro de segurança do Facebook cuja senha foi roubada - eles farejaram a senha de uma rede wifi , como o login do facebook não é criptografado) do que através de ataques MitM ou impostores, que são relativamente muito mais complicados de implementar. O foco na autenticação sobre criptografia no SSL é, como observei, precisamente o que cria essa situação.

— Jcrawfordor

11

@MarkM - embora definitivamente haja custos indiretos, o que é uma preocupação legítima, o uso de certificados não assinados não causará nenhum estresse às autoridades de certificação, especificamente porque uma autoridade de certificação não seria usada para um certificado autoassinado. Além disso, para organizações com poder suficiente, não é uma preocupação - considere que o Google agora usa o https para o Gmail e alguns outros serviços. Entendo que, sem autenticação, a utilidade do SSL é degradada. O modelo atual não está bem desenhado. O que realmente precisamos é de um protocolo criptografado padrão e um protocolo autenticado para usos mais seguros.

— Nhinkle

5

O significado maior do meu argumento, e NRHinkle disse diretamente isso, é que precisamos começar a considerar a criptografia e a autenticação como objetivos separados e permitir que eles sejam alcançados separadamente. Essas são as falhas fundamentais do sistema SSL no momento: 1) Vemos a criptografia e a autenticação como inextrincavelmente conectadas - para obter uma, você deve obter a outra. Fornecer apenas um é "suspeito". 2) A autenticação deve ser obtida de um número limitado de CAs com fins lucrativos. Em geral, as CAs ou são muito caros (Verisign etc.) ou muito obscuro (NameCheap etc)

— jcrawfordor

6

O envio de credenciais de página para página está basicamente executando o HTTP POST. Não há nada de especial no envio de credenciais em comparação com o envio, por exemplo, termos de pesquisa via POST. Se qualquer postagem em uma página não segura disparasse 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. Nesse caso, usar o aviso de certificado autoassinado é uma coisa muito correta.

— Miro A.
fonte

Justo o suficiente para mim.

— Dag729 9/07

Por uma questão de facto, recordo que em versões menos antigas do Netscape Navigator fez aparecer um aviso para cada POST não encriptado. Claro, todo mundo desativado-los depois de cinco minutos, então eu acho que é por isso que eles levaram para fora ...

— sleske

4

Como não posso comentar, publicarei essas informações que complementam as informações corretas do usuário40350.

No entanto, o mesmo navegador não tem problemas em permitir que credenciais sejam enviadas entre páginas não seguras.

Isso nem é verdade. A maioria dos navegadores exibe um aviso de que você está prestes a enviar dados por uma conexão não segura quando tentar pela primeira vez, mas pode desativá-lo para que ele nunca apareça novamente, e aposto que foi exatamente isso que você fez ...

Miro A escreveu:

O envio de credenciais de página para página está basicamente executando o HTTP POST. Não há nada de especial no envio de credenciais em comparação com o envio, por exemplo, termos de pesquisa via POST

Isso também está incorreto, pois 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 muita sensibilidade. Seria perfeitamente viável que os navegadores levassem esse tipo de informação em consideração.

— ufotds
fonte

3

As conexões protegidas pelo protocolo https: // são indicadas pelo navegador como "protegidas". Por exemplo, um pequeno cadeado é mostrado 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 do URL que ele havia inserido e nã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 imposto.

Um certificado autoassinado não garante que a página navegada não seja imposta e, portanto, não oferece segurança extra.

— usermac75
fonte

1

É necessário fazer uma distinção entre um certificado confiável (assinado por uma autoridade em que você confia) e um certificado não confiável. Caso contrário, alguém poderia se passar por seu banco (por exemplo) usando um certificado autoassinado com relativa impunidade.

Nesse caso, é preferível um aviso de alerta, 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 (por exemplo, um ícone vermelho em vez de verde, etc.), as pessoas podem ser facilmente enganadas, removendo os benefícios do SSL.

— Slartibartfast
fonte

Não é fácil se passar por um banco se você tiver acesso ao computador do usuário e modificar seus certificados? Se o computador do usuário não for alterado, o navegador da Web não poderá modificar o URL da página da Web para reivindicar que é o banco; e se eles obtiverem um URL muito semelhante, ainda poderão obter um certificado para esse site e o usuário não se importará com quem a página da Web está assinada, eles apenas verão que é https e esperamos notar que o URL não é o URL do banco deles ...

— Dmitry

O benefício do SSL não é a confiança de que o site é quem você pensa que é (isso é impossível, pois um aplicativo de terceiros pode alterar seus certificados ou o banco pode ser invadido); mas confie que a comunicação entre você e quem quer que seja que o site seja, é apenas entre vocês dois e ninguém mais pode entender essa comunicação. Não ter um certificado é pior do que ter um autoassinado porque não importa com quem você está falando, o que importa é que ninguém mais deve poder interceptar o que você está dizendo.

— Dmitry

Além disso, como usuário, eu realmente sei quem é a Verisign e por que devo confiar neles? O interesse deles em vender certificados é maior do que responsabilizar os proprietários de certificados pelo uso indevido das informações enviadas a eles?

— Dmitry

0

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, observando o momento, ela 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 fosse 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 eu seja um fornecedor e tenha um link "pagar com PayPal". Você clica nisso, e eu sei. Eu o redireciono para o PayPal e recebo a página legítima e segura do PayPal. Se eu estiver assistindo a sua rede, sei que essa será sua primeira solicitação do PayPal e, em seguida, você enviará sua senha. Então, eu envio o MITM submitcontendo seu endereço de e-mail e senha, substituindo meu certificado autoassinado pelos do PayPal.

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

E, é claro, se você digitar httpsmanualmente, ele deverá avisá-lo. Porque você espera que seja seguro.

— David Schwartz
fonte

-1

Quando o homem no ataque do meio é executado em https: // website, o aviso é apenas uma 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 exemplo sobre HTTP.

— Cmazay
fonte