Você se preocupa com a segurança na comunicação dos microsserviços da sua aplicação? A Netflix sim. Eles possuem uma arquitetura de microsserviços com centenas de aplicações independentes em execução em todo o seu ecossistema. Para garantir a segurança, eles objetivam a comunicação criptografada e autenticada de ponta a ponta entre todos os serviços, sempre que possível, independentemente de viajar ou não pela Internet pública. Na maioria das vezes, isso significa usar TLS, um padrão da indústria implementado em dezenas de linguagens. No entanto, isso significa que cada aplicação no ambiente deles precisa de um certificado TLS.

A inicialização das identidades das aplicações da Netflix é um problema que eles já resolveram, mas a maioria das aplicações da empresa são corrigidas utilizando nomes internos ou diretamente referenciados pelo IP. As Public Certificate Authorities (CAs) estão especificamente impedidas de emitir certificados desse tipo (consulte a seção 7.1.4.2.1 dos requisitos de referência da CA/B). Portanto, fez sentido usar uma CA interna para esse fim. Assim, conforme eles foram convertendo suas aplicações para utilizar TLS (por exemplo, usando HTTPS em vez de HTTP), foi razoavelmente simples configurá-los para usar um truststore que incluísse essa CA interna. No entanto, permaneceu a questão sobre o que fazer com os usuários acessando seus serviços usando um navegador. O problema é que a CA interna deles não é tida como confiável pelos navegadores menos utilizados.

Para resolver esse problema, eles pensaram no óbvio: “adicione a CA aos truststores dos navegadores”. Porém, essa solução não estava agradando muito a eles. Ao forçar seus usuários a confiar em uma CA privada, eles devem crer que essa CA é usada apenas para cunhar certificados para serviços internos e não está sendo usada para interceptar o tráfego para serviços externos (como bancos, sites de mídia social etc). Mesmo que seus usuários de fato acreditassem em seu bom comportamento, o impacto de um possível erro em sua infraestrutura teria grandes proporções; não só um atacante poderia comprometer seus canais de tráfego interno, mas todos os seus funcionários estariam subitamente em risco, mesmo quando estivessem em casa.

Então, eles pensaram na extensão de Restrições de Nome, que fornece uma solução para ambas as preocupações.

A extensão de Restrições de Nome

Um recurso poderoso (mas frequentemente negligenciado) da especificação TLS é a extensão de Restrições de Nome. Essa é uma extensão que pode ser colocada em certificados CA que coloca os domínios e IPs em listas brancas e/ou listas negras para as quais a CA ou quaisquer sub-CAs estão permitidas a criar certificados. Por exemplo, suponha que você confia na CA Raiz da Acme Corp, que delega a várias outras sub-CAs que finalmente assinam certificados para sites. Elas podem ter uma hierarquia de certificado semelhante a esta:

Agora, suponha que a Beta Corp e a Acme Corp se tornem parceiras e precisem começar a confiar nos serviços uma da outra. Semelhante à Acme Corp, a Beta Corp tem uma CA raiz que assinou certificados para todos os seus serviços. Portanto, os serviços dentro da Acme Corp precisam confiar na CA raiz da Beta Corp. Em vez de atualizar todos os serviços da Acme Corp para incluir a nova CA raiz no seu truststore, uma solução mais simples é a Acme Corp certificar-se com a Beta Corp para que a CA raiz da Beta Corp tenha um certificado assinado pela CA Raiz Acme. Para os usuários dentro da Acme Corp, sua hierarquia de confiança agora se parece com isto:

No entanto, isso tem o efeito colateral indesejável de expor os usuários dentro da Acme Corp ao risco de um incidente de segurança dentro da Beta Corp. Se uma CA Beta Corp está mal utilizada ou comprometida, poderia emitir certificados para qualquer domínio, incluindo os da Acme Corp.

É aí que a extensão de Restrições de Nome pode desempenhar sua função. Quando a Acme Corp assina o certificado de CA raiz da Beta Corp, ela pode incluir uma extensão no certificado que declara que só deveria ser confiável para emitir certificados sob o domínio “betacorp.com”. Dessa forma, os usuários da Acme Corp não confiariam em certificados falsos para o domínio “acmecorp.com” de CAs sob a CA raiz da Beta Corp.

Esse exemplo demonstra como as Restrições de Nome podem ser úteis no contexto da certificação cruzada de CA, mas também é aplicável ao problema da Netflix, que era inserir uma CA interna nos truststores dos navegadores. Ao cunhar a CA raiz com Restrições de Nomes, foi possível limitar quais web sites poderiam ser verificados usando essa raiz de confiança, mesmo que a CA ou qualquer de seus intermediários tenham sido mal utilizados.

Pelo menos, é assim que as Restrições de Nome deveriam funcionar.

O problema com Restrições de Nome

A extensão de Restrições de Nome vive no certificado de uma CA, mas não pode realmente restringir o que um ator ruim faz com a chave privada da CA (muito menos controlar o que uma CA subordinada emite). Então, mesmo com a extensão presente, não há nada que impeça o mau ator de assinar um certificado que viola a restrição. Portanto, cabe ao cliente TLS verificar se todas as restrições estão satisfeitas sempre que o cliente verifica uma cadeia de certificados.

Isso significa que, para que a extensão de Restrições de Nome seja útil, os clientes HTTPS (e navegadores em particular) devem aplicar corretamente as restrições.

Antes de confiar nessa solução para proteger seus usuários, era necessário a certificação de que os navegadores estavam realmente implementando a verificação de Restrições de Nome e fazendo isso corretamente. Cada um dos navegadores testados (Chrome, Firefox, Edge e Safari) deram exceções de verificação ao navegar para um site em que uma CA assinava um certificado em violação das restrições, o que foi um ponto positivo.

Entretanto, à medida que eles estenderam seu conjunto de testes para além dos testes básicos, a confiança foi perdida. Foi então criada uma bateria de certificados de teste que moviam o nome do assunto entre o nome comum de assunto do certificado e a extensão de Nome Alternativo de Assunto, que misturou o uso de listas brancas e listas negras de Restrições de Nome e que usava tanto nomes DNS quanto nomes de IP na restrição. O resultado foi que todos os navegadores (exceto o Firefox, que mostrava uma taxa de passagem de 100%) e todos os clientes HTTPS (como Java, Node.JS e Python) permitiam algum tipo de contorno de Restrição de Nome.

Apresentando o BetterTLS

Com isso, a Netflix quis aumentar a conscientização sobre os problemas descobertos e incentivar implementadores TLS a corrigi-los, e para permitir-lhes incluir alguns desses testes em seu próprio conjunto de testes, eles abriram o código do conjunto de testes criado e colocaram on-line. Inspirado pelo badssl.com, eles também criaram o bettertls.com com a esperança de que os testes adicionados a esse site possam ajudar a melhorar a resiliência das implementações TLS.

Antes de tornarem o bettertls.com público, eles entraram em contato com muitos dos vendedores afetados e felizmente, receberam várias respostas positivas. Em especial, a Netflix fez um agradecimento particular a Ryan Sleevi e Adam Langley do Google, que “foram extremamente responsivos e imediatamente tomaram medidas para corrigir alguns dos problemas descobertos e incorporaram alguns desses certificados de teste em seu próprio conjunto de testes”. Além disso, eles também receberam a confirmação da Oracle de que eles estarão endereçando os resultados deste conjunto de testes em Java em uma próxima versão de segurança.

A fonte para bettertls.com está disponível no GitHub. Faça você também a sua parte! Sugira, melhore, corrija e crie novos testes!

***

Fonte: http://techblog.netflix.com/2017/04/bettertls-name-constraints-test-suite.html