Respostas:
Pergunta interessante, depende do uso na minha opinião. Você ainda está protegido em termos de criptografia da sessão, mas não tem como saber se o certificado SSL correto é apresentado a menos que você distribua seu certificado raiz da CA para usuários / clientes. Para testes internos / projetos de desenvolvimento, isso funcionaria muito bem, você gera um certificado de CA raiz que você distribui para seus usuários (pode ser feito via Diretiva de Grupo no Windows e via linha de comando openssl no Linux / BSD) e depois usa esse certificado raiz para assinando seus CSRs. Os usuários não verão um aviso nem nada e você sabe que o certificado é assinado por sua CA interna.
Para sites externos em que você não pode garantir isso, eu ainda diria que um certificado autoassinado é melhor que nenhum SSL, se você estiver enviando senhas ou outras informações confidenciais pela conexão.
No entanto, no lado positivo, existem muitos emissores de certificados "comerciais" muito baratos, sendo o GoDaddy um deles. Você pode obter um certificado por cerca de 40 euros por ano. A GoDaddy oferece até certificados gratuitos para sites de projetos OpenSource.
Vou discordar, uma vez por motivos técnicos estreitos, e uma vez por motivos gerais.
A base técnica restrita é que o OP perguntou sobre certificados autoassinados e várias outras respostas se referem a certificados assinados por CAs privadas, o que é um problema um pouco diferente. Mas não muito diferente, então isso é realmente apenas uma nota de passagem.
A principal objeção é que, desde que os certificados assinados comercialmente sejam mais do que uma despesa trivial - e US $ 40 por ano não é uma despesa trivial para muitas pessoas neste planeta - os certificados autoassinados têm um papel importante a desempenhar na segurança da Internet, desde que suas limitações sejam reconhecidas .
Um certificado autoassinado é como uma chave ssh do meu known_hostsarquivo. Sem verificação independente, não posso garantir que estou falando com o sistema que acredito que sou; mas pode me garantir que o sistema com o qual estou falando agora é o mesmo com o qual falei da última vez que pensei que estava tendo uma conversa com ele. Armazenamos em cache chaves ssh o tempo todo e nunca conheci um administrador de sistema que verificasse independentemente mais de uma fração das chaves públicas em seu known_hostsarquivo.
Certificados autoassinados (e, nesse caso, certificados assinados por CAs geralmente não válidas) são muito melhores do que nenhum SSL, desde que as pessoas percebam que, a menos que os verifiquem, apenas protegem a comunicação, o servidor na outra extremidade do registro DNS, e qualquer homem do meio atualmente na linha. Se eles verificarem independentemente o certificado, a autenticação e a criptografia serão pelo menos tão fortes quanto as fornecidas por um certificado assinado por uma CA reconhecida.
Além disso, aqueles que desejam apresentar o uso de certificados assinados por uma CA reconhecida como a única panacéia de segurança na Internet podem precisar refletir bastante sobre questões como a inclusão da CA de assinatura do governo chinês no pacote padrão Mozilla e o certificados SSL fraudulentos assinados pela Comodo .
known_hostsreferência a @MadHatter.
Para sites externos, nos quais os usuários não têm seu certificado de CA instalado (que é o caso mais comum), sim, um certificado autoassinado fornece uma falsa sensação de segurança e, portanto, é pior que inútil:
Primeiro, sem um certificado CA pré-instalado, como o usuário verifica se o certificado realmente vem de você e não de um invasor? Combinando os campos do certificado (CN, impressões digitais, etc.), é claro - mas contra o quê? Portanto, agora você precisa de um canal lateral para verificar o certificado - e nos poucos casos em que vi isso, os operadores da linha de suporte (que deveriam ter servido como canal lateral para verificação) não têm idéia do que isso significa; Além disso, a operação desse canal lateral é muito mais cara do que a obtenção de um certificado assinado pela CA confiável; portanto, o usuário deve confiar cegamente em você.
Segundo, o alerta assustador que o usuário recebe é assustador por um bom motivo: como o usuário não pode / não verifica o certificado apresentado, ele pode estar transmitindo dados com segurança ao Elbonian Haxx0r D00dz.
Terceiro, e o pior de tudo, você está dessensibilizando os usuários : "bem, eles me disseram que eu deveria ignorar esse aviso em https://mysite.example.com/ , e uma bigorna não caiu na minha cabeça, e minha o goldfish também não morreu; muuuuito, isso significa que é apenas mais uma caixa de alerta sem nenhum significado real, para que eu possa ignorá-la sempre que a encontrar - recebo aquele belo ícone de cadeado de qualquer maneira, e isso é importante ".
Em outras palavras, o nível de proteção é comparável ao HTTP simples (exceto pelo sniffing on-the-wire: embora os dados sejam criptografados em trânsito, esse é um recurso bastante anêmico sem verificação de terminal), mas a sensação de proteção é irracionalmente alta . Analogia do carro ruim: "Eu tenho ABS, então agora posso dirigir com mais segurança em más condições" - exceto que o ABS existe apenas na brochura de vendas do carro, sem estar presente no carro.
Leitura sugerida: práticas recomendadas do OWASP SSL
TL; DR: Ao usar certificados autoassinados em sites públicos, você está tornando a Internet um lugar pior, um usuário sem noção de cada vez.
Depende. Se você acha que isso o torna mais seguro, aumenta o risco à medida que você escolhe fazer coisas mais arriscadas com seu falso senso de segurança. Se você o tratar funcionalmente equivalente ao HTTP, diria que você é um pouco mais seguro.
Sem SSL / HTTPS, qualquer pessoa com o wireshark na sua rede (ou a rede local de quem estiver logando) pode ouvir e capturar trivialmente e capturar nomes de usuário / senhas enviados como texto sem formatação.
Com o SSL autoassinado, eles não podem simplesmente ouvir, mas agora precisam falsificar seu site, alterar potencialmente o DNS para fazer um ataque MITM. Isso ainda é uma ameaça, mas significativamente mais difícil para eles realizarem.
O outro problema com o uso de SSL autoassinado é que muitos navegadores tratam os certificados autoassinados como uma grande ameaça à segurança e avisam você antes de entrar (por exemplo, chrome) com uma página vermelha gigante. http://www.sslshopper.com/article-ssl-certificates-in-google-chrome.html Isso pode ser um grande inconveniente.
Portanto, a questão é: se você executa algo que não precisa ser particularmente seguro (por exemplo, sem dados de cartão de crédito, sem #s de seguridade social) e não pode pagar um certificado adequado, um certificado autoassinado pode fazer algum sentido (para impedir que outros usuários da rede detectem facilmente suas informações de login).
Depende do que você quer dizer com "segurança" e qual é a extensão.
Por exemplo, seu navegador vem com um conjunto de CA aceito por padrão. Isso significa que qualquer certificado emitido por esta CA é aceito pelo seu navegador (até corresponder ao nome do DNS). Agora, imagine que algum governo maligno possua uma CA ou possa forçá-la a emitir um certificado para o site que você está visitando. Então, fazer um MITM é muito fácil: eles podem fazer proxy da sua conexão, enviando para o navegador o certificado que possuem e o navegador o aceitará, pois vem de uma CA "confiável". Até que eles sejam transparentes ao DNS (que é a base do MITM), isso está ok.
Portanto, a "lista de ACs aceitas" é basicamente uma grande falha de segurança, até que uma delas ajude com algum governo maligno. Ter sua própria CA é muito melhor.
Obviamente, você pode fazê-lo em sua empresa ou em seu servidor doméstico, porque você pode instalar seu próprio certificado CA no cliente, que você também controla. Em um servidor público, você não pode lidar com nenhum usuário, solicitando que ele adicione uma exceção ou adicione seu certificado.
Portanto, depende do que você quer dizer com "segurança" e do escopo. Se você possui os clientes, COM CERTEZA, o autoassinado é mais seguro, até você instalar no próprio cliente o certificado de sua própria CA.
Obviamente, você não pode fazer isso em um site público, pois não possui todos os clientes. Portanto, você terá o risco de comportamentos diferentes, o que não é seguro.