Quais são os riscos de confiar em um certificado auto-assinado em uma máquina de desenvolvimento?

Question

Temos máquinas de desenvolvimento que testam aplicativos da web em desenvolvimento em https, porque o aplicativo implantado opera por meio de https.

Temos alguns URLs internos configurados em nosso arquivo de hosts, para que o link e link pode ser usado para testar diferentes ramificações. Também depuramos no windows azure dev fabric, o que faz com que o aplicativo ultrapasse o link . Há outro certificado para isso, no entanto, ele é gerado automaticamente pelo dispositivo de desenvolvimento.

Para fazer com que nossos navegadores ignorem os certificados não seguros, os arrastamos de Personal para Trusted Root Certification Authorities.

Isso torna nossas máquinas dev vulneráveis de alguma forma? Se sim, como?

    

Answer 1

A única diferença entre um certificado assinado por CA e um certificado autoassinado é que seu navegador (ou outro cliente ssl) não confia implicitamente no certificado autoassinado. Se você confia no certificado, importá-lo de modo que seu cliente não avise não é diferente do gravador do navegador que importa os certificados em seus keystores.

    

Answer 2

Potencialmente, se a chave privada do seu certificado sair, você poderá permitir que alguém o atenda ao MITM.

Conclusão: não realmente.

Sempre há um pequeno risco, mas você é um desenvolvedor que alguém teria que segmentar explicitamente para que isso aconteça.

Talvez haja algo em que eu não esteja pensando, mas de alguma forma eu acho que você vai conseguir.

    

Answer 3

Um certificado auto-assinado não é mais vulnerável do que aquele assinado por uma autoridade de certificação. Torna-se inseguro por causa do comportamento dos usuários, que serão usados para aceitar e confiar neles cegamente. Se você adicionar um certificado a Autoridades de certificação raiz confiáveis, qualquer certificado assinado por esse certificado será confiável para sua máquina. Portanto, se um de seus certificados auto-assinados for comprometido, todas as máquinas em que ele estiver instalado se tornarão vulneráveis ao ataque do meio. O pior é que você não pode ter uma lista de revogação para eles e você terá que removê-los manualmente caso seja comprometido.

A melhor abordagem é usar uma autoridade de certificação interna e cantar TODOS os certificados internos com sua CA. Isso é muito seguro, conveniente e barato.

Para configurar uma autoridade de certificação:

1. Crie uma máquina física que será usada como CA. Somente administradores confiáveis devem ter acesso a essa caixa (idealmente, 2 pessoas).
2. Crie um servidor de revogação, isso deve ser diferente da máquina CA. (servidor com a lista de certificados revogados, que será acessível pelo menos em toda a sua organização)
3. Crate um certificado raiz.
4. Crie um certificado intermediário que será usado para fins de assinatura.
5. Imprima a chave particular da CA raiz em um papel e bloqueie o papel em um cofre seguro.
6. Destrua a chave particular da raiz da autoridade de certificação do servidor da autoridade de certificação.
7. Distribua o certificado da CA em toda a empresa e instale-o como uma autoridade de certificação confiável.
8. Distribua o certificado intermediário da CA e instale-o como uma CA intermediária (não confiável).
9. Assinar todos os certificados com o certificado intermediário da autoridade de certificação. Não permita datas de vencimento superiores a 1-2 anos. Não permita chaves assimétricas inferiores a 2048.
10. Adicionar à lista de revogação todos os certificados comprometidos.