Como lidar com domínios cujos nomes não devem ser publicados pela transparência do certificado?

Question

Eu tenho um conjunto de nomes de domínio que são usados internamente e não desejo que eles vazem para o mundo externo (já que isso daria ao invasor um conhecimento avançado do layout da rede interna). Dada a Transparência do certificado parece que está ganhando força, qual é o consenso geral sobre a melhor maneira de ter nomes de domínio privado? Certificados auto-assinados? Certs de cartão selvagem? Algo mais?

    

Answer 1

I have a set of domain names that are used internally

Para usos internos, você pode definir uma autoridade de certificação privada, instalar seu certificado em sistemas internos e emitir certificados internos por conta própria.

Se seus servidores uso interno forem usados externamente, eles não funcionarão, a menos que os clientes externos adicionem uma exceção ao seu certificado. Isso não impedirá que invasores externos descubram os domínios internos e os ataquem. Nesse caso, use um certificado curinga. Usar um certificado de CA interno ou auto-assinado irá incomodar os usuários externos e não fará nada para protegê-lo contra invasores (como a maioria dos esquemas de DRM).

    

Answer 2

Se o vazamento de nomes de host fizer parte de seu modelo de ameaça, a CT provavelmente não é a única fonte desse vazamento. Pense em cabeçalhos de e-mail, logs, monitoramento, compiladores, .. muitas ferramentas podem, eventualmente, derramar nomes de sistema (seja nomes de host ou apenas parte de certificados) em espaços publicamente acessíveis. Em vez disso, trabalhe com os motivos subjacentes para que eles permaneçam confidenciais.

Você não precisará ocultá-los se não houver nada de secreto neles. Se eles revelarem alguma informação, geralmente é porque você está usando os nomes para

1. ajude os administradores a navegar na sua própria rede ou
2. ajude os colegas de trabalho a lembrar qual URL digitar.
3. teste um sistema internamente antes da operação comercial

Para todos os 3 problemas, existem soluções melhores. O principal problema de 1. é que os nomes de sistemas geralmente acabam não correspondendo às funções do sistema após várias mudanças. O principal problema com o 2. é que seus colegas de trabalho não devem digitar URLs à mão de qualquer maneira - pense em golpes do tipo com erros de ortografia. Os nomes de código resolvem 3.

Recomendação: nomeie seus servidores internos com um esquema consistente, porém aleatório. Sistema de transporte < > relações de papel através de meios inteiramente diferentes. Você costuma abordar seus colegas de trabalho pelos seus nomes, não por suas funções - faça isso para seus servidores internos de maneira semelhante.

Nossa wiki interna está hospedada em lake.example.org . Lake não significa nada, é apenas suficientemente diferente de cube.example.org (a coleção de log). Mas o atacante mal sabe apenas que existem 8 domínios internos, o que não é surpreendente para o tamanho da organização. Se ele quiser saber mais, ele terá que vir nos visitar & leia as tags de nome.

    

Answer 3

Esta parece ser uma decisão bem simples, a menos que eu esteja perdendo alguma coisa.

Se você decidir que a privacidade dos dados que seriam expostos pela Transparência do certificado é mais valiosa do que a conveniência de ter certificados assinados por uma autoridade de certificação confiável, você:

• Não use certificados (insensatos e impraticáveis com software moderno)

ou

• Execute sua própria CA e lide com a inconveniência de configurar clientes para confiar nela.