Cadeia de confiança. CC BY-SA 4.0
A inspeção de tráfego SSL (descriptografia SSL/TLS, análise SSL ou DPI) está se tornando um tema de discussão cada vez mais quente no setor corporativo. A ideia de descriptografar o tráfego parece contradizer o próprio conceito de criptografia. No entanto, o facto é um facto: cada vez mais empresas estão a utilizar tecnologias DPI, explicando isto pela necessidade de verificar conteúdo em busca de malware, fugas de dados, etc.
Bem, se aceitarmos o facto de que tal tecnologia precisa de ser implementada, então deveríamos pelo menos considerar formas de o fazer da forma mais segura e bem gerida possível. Pelo menos não confie nesses certificados, por exemplo, que o fornecedor do sistema DPI lhe fornece.
Há um aspecto da implementação que nem todos conhecem. Na verdade, muitas pessoas ficam realmente surpresas quando ouvem falar disso. Esta é uma autoridade de certificação privada (CA). Ele gera certificados para descriptografar e criptografar novamente o tráfego.
Em vez de confiar em certificados autoassinados ou certificados de dispositivos DPI, você pode usar uma CA dedicada de uma autoridade de certificação terceirizada, como a GlobalSign. Mas primeiro, vamos fazer uma pequena visão geral do problema em si.
O que é inspeção SSL e por que ela é usada?
Cada vez mais sites públicos estão migrando para HTTPS. Por exemplo, de acordo com , no início de setembro de 2019, a parcela do tráfego criptografado na Rússia atingiu 83%.
Infelizmente, a criptografia de tráfego está sendo cada vez mais usada por invasores, especialmente porque o Let's Encrypt distribui milhares de certificados SSL gratuitos de maneira automatizada. Assim, o HTTPS é usado em todos os lugares – e o cadeado na barra de endereços do navegador deixou de servir como um indicador confiável de segurança.
Os fabricantes de soluções DPI promovem seus produtos nessas posições. Eles são integrados entre os usuários finais (ou seja, seus funcionários que navegam na web) e a Internet, filtrando o tráfego malicioso. Existem vários desses produtos no mercado hoje, mas os processos são essencialmente os mesmos. O tráfego HTTPS passa por um dispositivo de inspeção onde é descriptografado e verificado em busca de malware.
Assim que a verificação for concluída, o dispositivo cria uma nova sessão SSL com o cliente final para descriptografar e criptografar novamente o conteúdo.
Como funciona o processo de descriptografia/recriptografia
Para que o dispositivo de inspeção SSL descriptografe e criptografe novamente os pacotes antes de enviá-los aos usuários finais, ele deve ser capaz de emitir certificados SSL dinamicamente. Isso significa que deve ter um certificado CA instalado.
É importante para a empresa (ou para quem quer que esteja no meio) que esses certificados SSL sejam confiáveis para os navegadores (ou seja, não acionem mensagens de aviso assustadoras como a abaixo). Portanto, a cadeia (ou hierarquia) de CA deve estar no armazenamento confiável do navegador. Como esses certificados não são emitidos por autoridades de certificação publicamente confiáveis, você deve distribuir manualmente a hierarquia de CA para todos os clientes finais.
Mensagem de aviso para certificado autoassinado no Chrome. Fonte:
Em computadores Windows, você pode usar o Active Directory e Políticas de Grupo, mas para dispositivos móveis o procedimento é mais complicado.
A situação fica ainda mais complicada se você precisar oferecer suporte a outros certificados raiz em um ambiente corporativo, por exemplo, da Microsoft, ou baseado em OpenSSL. Além da proteção e gerenciamento de chaves privadas para que nenhuma das chaves expire inesperadamente.
Melhor opção: certificado raiz privado e dedicado de uma CA de terceiros
Se o gerenciamento de múltiplas raízes ou certificados autoassinados não for atraente, há outra opção: contar com uma CA de terceiros. Neste caso, os certificados são emitidos de particular uma CA vinculada por uma cadeia de confiança a uma CA raiz privada e dedicada, criada especificamente para a empresa.
Arquitetura simplificada para certificados raiz de clientes dedicados
Esta configuração elimina alguns dos problemas mencionados anteriormente: pelo menos reduz o número de raízes que precisam ser gerenciadas. Aqui você pode usar apenas uma autoridade raiz privada para todas as necessidades internas de PKI, com qualquer número de CAs intermediárias. Por exemplo, o diagrama acima mostra uma hierarquia multinível onde uma das CAs intermediárias é usada para verificação/descriptografia SSL e a outra é usada para computadores internos (laptops, servidores, desktops, etc.).
Neste design, não há necessidade de hospedar uma CA em todos os clientes porque a CA de nível superior é hospedada pela GlobalSign, o que resolve problemas de proteção e expiração de chave privada.
Outra vantagem desta abordagem é a capacidade de revogar a autoridade de inspeção SSL por qualquer motivo. Em vez disso, um novo é simplesmente criado, vinculado à sua raiz privada original, e você pode usá-lo imediatamente.
Apesar de toda a controvérsia, as empresas estão cada vez mais implementando a inspeção de tráfego SSL como parte da sua infraestrutura PKI interna ou privada. Outros usos para PKI privada incluem a emissão de certificados para autenticação de dispositivo ou usuário, SSL para servidores internos e várias configurações que não são permitidas em certificados públicos confiáveis, conforme exigido pelo CA/Browser Forum.
Os navegadores estão reagindo
Deve-se notar que os desenvolvedores de navegadores estão tentando contrariar essa tendência e proteger os usuários finais do MiTM. Por exemplo, há alguns dias Mozilla Habilite o protocolo DoH (DNS sobre HTTPS) por padrão em uma das próximas versões do navegador Firefox. O protocolo DoH oculta as consultas DNS do sistema DPI, dificultando a inspeção SSL.
Sobre planos semelhantes 10 de setembro de 2019 Google para o navegador Chrome.
Apenas usuários registrados podem participar da pesquisa. por favor
Você acha que uma empresa tem o direito de fiscalizar o tráfego SSL de seus funcionários?
-
Sim, com o seu consentimento
-
Não, pedir esse consentimento é ilegal e/ou antiético
122 usuários votaram. 15 usuários se abstiveram.
Fonte: habr.com