Como lidar com domínios cujos nomes não deveriam ser publicados por transparência de certificados?

Como lidar com domínios cujos nomes não deveriam ser publicados por transparência de certificados?

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 (pois isso daria ao invasor conhecimento avançado do layout da rede interna). DadoTransparência do certificadoparece que está ganhando força, qual é o consenso geral sobre a melhor maneira de ter nomes de domínio privados? Certificados autoassinados? Certificados curinga? Algo mais?

Responder1

Tenho um conjunto de nomes de domínio que são usados ​​internamente

Para usos somente internos, você pode definir uma CA privada, instalar seu certificado em sistemas internos e emitir você mesmo certificados internos.

Se seuuso internoSe os servidores forem de alguma forma 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 CA interno ou autoassinado incomodará os usuários externos e não fará nada para protegê-lo contra invasores (como a maioria dos esquemas DRM).

Responder2

Se o vazamento de nomes de host faz parte do seu modelo de ameaça, então a CT provavelmente não é a única fonte desse vazamento. Pense em cabeçalhos de e-mail, logs, monitoramento, compiladores, .. muitas ferramentas poderiam eventualmente espalhar nomes de sistemas (sejam nomes de host ou apenas parte de certificados) em espaços acessíveis ao público. Em vez disso, trabalhe nas razões subjacentes para querer que eles permaneçam confidenciais.

Você não terá que escondê-los se não houver nada de segredo sobre eles. Se eles revelarem alguma informação, geralmente é porque você está usando os nomes para

  1. ajudar os administradores a navegar em sua própria rede ou
  2. ajude os colegas de trabalho a lembrar qual URL digitar.
  3. testar 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 dos sistemas geralmente acabam não correspondendo às funções do sistema após uma série de alterações. O principal problema com 2. é que seus colegas de trabalho nunca deveriam digitar URLs manualmente - pense em golpes do tipo domínio com erros ortográficos. Os nomes de código resolvem 3.

Recomendação: Nomeie seus servidores internos com um esquema consistente, mas aleatório.Transmita relacionamentos de sistema <> função por meios totalmente diferentes. Você geralmente se dirige a seus colegas de trabalho pelos nomes, não pelas funções - faça o mesmo com os servidores internos.

Nosso wiki interno está hospedado em lake.example.org. Lago não significa nada, é apenas suficientemente diferente de cube.example.org(a coleção de logs). Mas o malvado invasor sabe apenas que existem 8 domínios internos, o que não é surpreendente para o tamanho da organização. Se ele quiser saber mais, terá que vir nos visitar e ler os crachás.

Responder3

Esta parece ser uma decisão bastante simples, a menos que esteja faltando alguma coisa.

Se você decidir que a privacidade dos dados que seriam expostos por meio da Transparência de Certificados é mais valiosa do que a conveniência de ter certificados assinados por uma CA publicamente confiável, você:

  • Não use certificados (imprudente e inviável com software moderno)

ou

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

informação relacionada