Existe algum conceito de confiar em um certificado SSL / TLS para identificar um único site, mas não para atuar como CA para outros certificados?

Question

Eu regularmente me vejo lidando com certificados ruins em minha intranet (ou em servidores temporários sem um certificado assinado corretamente). Eu não passei por uma abordagem que me permite salvar o certificado de um único site (incluindo seu CN) em um navegador sem também confiar nele como uma autoridade de certificação para outros sites. Isso é conceitualmente possível, ou está fora do projeto do sistema PKI?

Editar para esclarecer : digamos que estou trabalhando em algum servidor local, megaserver . Eu o acesso via link no navegador. Tem um certificado autoassinado. Para acessar com segurança esse servidor por enquanto, adiciono seu certificado à minha CA Store em meu navegador. Alguém rouba esse certificado, cria um novo certificado para o link , assina-o com os certificados megaserver e ataca-me como um homem-na- estilo médio. Meu navegador aceita o certificado do Google porque está assinado por um certificado de CA confiável no meu sistema. Este cenário hipotético é possível?

    

Answer 1

Sim.

Do RFC 5280:

4.2.1.9. Basic Constraints

The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate.

Em seguida, ele diz:

If the basic constraints extension is not present in a version 3 certificate, or the extension is present but the cA boolean is not asserted, then the certified public key MUST NOT be used to verify certificate signatures.

verificar assinaturas de certificado efetivamente significa agir como uma AC.

Portanto, se o seu certificado autoassinado não tiver a CA de restrição básica definida como verdadeira, ela não poderá ser usada para assinar certificados subordinados.

Tem certeza de que todos esses certificados auto-assinados têm esse sinalizador definido como verdadeiro? Se assim for, você realmente precisa ter uma palavra com quem está gerando e apontá-los na direção de alguns recursos gratuitos de treinamento de PKI on-line.

Roubar um certificado não é um risco - afinal, os certificados são de conhecimento público. Roubar a chave privada associada é, no entanto, e torna o seu certificado inútil. Esse problema de longa data (no mundo da PKI) de proteger a chave privada resultou no desenvolvimento de módulos de segurança de hardware para evitar que a chave privada caísse em mãos erradas. Eu duvido que você queira gastar tanto para o certificado auto-assinado da sua intranet.

Uma abordagem melhor é garantir que você gerencie quem faz logon nos dispositivos que criam esses certificados. Sistemas que usam OpenSSL, GnuTLS, Java, etc. podem proteger por senha a chave privada. O Windows criptografa a chave privada, mas, uma vez que um administrador tenha efetuado login nesta máquina Windows, a chave privada estará efetivamente pronta para ser usada.

    

Answer 2

Q: I add its certificate to my CA store in my browser. Someone steals that certificate, creates a new certificate for https://www.google.com

Você está adicionando à chave Pública do armazenamento de certificados da CA local autônoma. O único proprietário da chave privada da CA pode assinar o certificado de alguém (como você disse para o link ), portanto, roubar a chave pública da CA do navegador é inútil, já que não é um segredo e não pode ser usado para assinar outros certificados.

Q: My browser accepts the Google certificate because it's signed by a trusted CA cert on my system. Is this hypothetical scenario possible?

Você confia no seu navegador que, por sua vez, confia no escopo específico das CAs. Se você adicionou ao seu navegador a sua CA local como confiável para o armazenamento de certificados, então você confia automaticamente em todos os certificados assinados por essa CA local.

Dessa forma, o departamento de TI que gerencia sua CA local pode emitir e assinar um certificado falso para google.com, e seu navegador confiará nele, mas ... Veja dois detalhes técnicos que você precisa saber.

Quando você se conecta diretamente a algum domínio https , o servidor da Web responde com certificado público que carrega as informações que assinaram esse certificado e o navegador procurando em seu repositório de certificados a CA que assinou o certificado deste servidor da Web. ser um trabalho difícil para os caras que tentam falsificar o google.com, que deve configurar cópias falsas do google.com como seu próprio servidor da Web e substituir o registro de DNS que apontaria para o site falso fingindo ser o google.com

Mas, na realidade, isso pode ser feito de forma relativamente fácil. Embora pareça impossível (ou difícil de fazer), devo informar que não é difícil fazer isso e que, na verdade, é uma prática comum, com muitas empresas, assistir / interceptar https tráfego por várias razões (filtragem, monitoramento e logging), empregando o proxy HTTP transparente (ou com autorização).

Se você adicionou CA local ao repositório de certificados, a sua empresa pode usar certificados HTTP para qualquer conexão https e alimentá-la no seu navegador, e seu navegador confiará (como descrevi anteriormente) a tais certificados falsos. Proxy em seu lado pode descriptografar essas conexões desde suas próprias chaves privadas para todos os certificados emitidos com o propósito de filtrar, monitorar, registrar e se a conexão ignorar o filtro do proxy, o proxy perguntará o site real direcionado como um cliente e então reescrever responda e retorne ao destino original (ou pode decidir reproduzir uma conexão de timeout falsa se algumas regras exigirem isso).

O que eu posso aconselhar se você não quiser ser um assunto de https filtering - configure alguma máquina virtual (VirtualBox por exemplo) com o SO que você goste e adicione lá sua CA local enquanto mantém a máquina host não infectada CA local.
Outra solução, - você pode usar perfis diferentes em seu navegador (o Firefox é bom nisso), um para o trabalho que conterá seu certificado de CA local e outro perfil privado que não inclui CA local. Dessa forma, você (na verdade, navegador) poderá detectar eventos rapidamente se o tráfego de https for filtrado por proxy.