Nome alternativo do assunto SSL e ataques Homem no meio

Question

Minha empresa "nossaempresa" possui um nome de domínio DNS de segundo nível: ourcompany.org . Atualmente, usamos esse domínio, bem como www.ourcompany.org e feature1.ourcompany.org , e geramos um certificado SSL para esses dois domínios de nível.

Em seguida, assinamos um serviço hospedado por terceiros, hospedado em ourcompany.thirdparty.org . Eles lidam com SSL e têm um certificado cujo assunto é thirdparty.org e têm o nome alternativo de assunto *.thirdparty.org .

Esta empresa de terceiros também fornece uma funcionalidade para adicionar um domínio personalizado. Por isso, adicionamos um registro CNAME em nossa configuração de DNS e agora temos feature2.ourcompany.org apontando para ourcompany.thirdparty.org . Obviamente, neste ponto, o SSL não está funcionando ao acessar feature2.ourcompany.org .

Em seguida, a empresa terceirizada também solicitou entradas de DNS de anúncios TXT para provar que somos proprietários do domínio, e eles conseguiram atualizar seu certificado SSL e adicionar os seguintes nomes alternativos de assunto: ourcompany.org e *.ourcompany.org .

• Como isso não é uma fonte potencial de ataque do Homem no Meio? (a empresa terceirizada agora pode se passar por qualquer um de nossos domínios)
• Como uma empresa arbitrária de terceiros pode gerar certificados SSL válidos, incluindo SAN apontando para um domínio que eles não possuem? (a SAN deles inclui muito mais coisas do que o registro de domínio CNAME que adicionamos)
• A autoridade de certificação permitiu nossos domínios como SAN devido ao registro CNAME apontando para seu domínio (neste caso, como a SAN incluiu muito mais domínios do que apenas feature2.ourcompany.org ) ou devido à entrada TXT (neste caso, caso, alguém poderia me indicar um recurso explicando esse processo)?

Answer 1

Depois de analisar nossa configuração de DNS, parece que a autoridade de certificação validou as entradas SAN no certificado da empresa terceirizada devido a uma das entradas TXT que nos pediram para adicionar: globalsign-domain-verification=XXXXXXX , onde XXXXXXX é uma chave fornecida pela GlobalSign para a empresa de terceiros (a documentação sobre este recurso GlobalSign é difícil de encontrar, mas eu poderia encontrar algo aqui ). Isso responde às questões 2 e 3.

Em relação ao primeiro, parece que a entrada TXT está definida para o domínio de segundo nível, a empresa terceirizada está agora autorizada a incluir o domínio de segundo nível, bem como qualquer domínio de terceiro nível sob ele nas entradas SAN seu certificado.

    

Answer 2

a empresa terceirizada provavelmente precisa de uma verificação para provar que você tem acesso ao domínio (assim como godaddy verifica em certificados ssl simples)

isso faz não significa que eles têm acesso ao seu nome de domínio e / ou podem assumir seus domínios. isso também não significa que eles possam fazer um mitm em conexões estabelecidas por meio de seu próprio certificado. é apenas um certificado separado e quando você aponta com um registro dns correspondente para seus servidores, ele distribuirá o certificado. lidar com muitos certs em um único host / endereço é bastante commin desde sni (indicação do nome do servidor) é bastante bem suportado hoje.