Saltar para o conteudo
Avanet

Implementar corretamente a inspeção TLS no Sophos Firewall

Com a inspeção TLS, o Sophos Firewall encerra a conexão criptografada do cliente e estabelece uma segunda conexão com o servidor de destino. Ele pode inspecionar o texto simples entre os dois. O firewall assina novamente o certificado do servidor apresentado ao cliente com sua própria CA (Autoridade de Certificação). Se o cliente não confiar nesta CA, ele exibirá um aviso de certificado ou encerrará a conexão.

Isso torna possível inspecionar o conteúdo descriptografado, incluindo verificação de malware e de conteúdo. Sem descriptografia, os recursos de proteção podem ser limitados, dependendo do módulo, a informações como endereço IP, domínio, SNI, certificado ou metadados de protocolo. Isso não justifica uma implementação inicial ampla: a fixação de certificados, a privacidade, a compatibilidade de aplicativos e a carga adicional do firewall devem ser abordadas antes da implementação.

A versão resumida e segura é: determinar se deve usar o caminho DPI ou Web Proxy, distribuir a CA de nova assinatura para um pequeno grupo, documentar o estado atual, criar uma regra de descriptografia com escopo restrito, executar um teste positivo e um negativo e só então expandir o escopo.

Decida antes do piloto

Licença, CA e responsabilidades

As regras de inspeção SSL/TLS e os grupos de URL usados ​​nelas são aplicados com o Base License. Web Protection não é um pré-requisito geral para inspeção TLS. É necessário quando categorias da web são usadas como critérios de regra ou quando os recursos de proteção da web correspondentes são necessários. Malware, Zero-Day e outras inspeções exigem a assinatura relevante. Quais pacotes do Sophos Firewall estão disponíveis? e Compreendendo a licença básica do Sophos Firewall explicam as diferenças.

Esclareça o seguinte antes de criar a primeira regra:

  • Documentar a versão do SFOS em uso, a licença disponível e o caminho de inspeção pretendido.
  • Definir um grupo piloto gerenciado e uma janela de tempo clara. O exemplo abaixo usa o cliente 10.20.30.50 da rede de teste 10.20.30.0/24; substitua esses valores por seus próprios objetos.
  • Obtenha a aprovação das partes interessadas responsáveis ​​pela privacidade para o escopo, registro, retenção e notificação do usuário.
  • Faça backup do estado inicial exato da regra de firewall, regras TLS, perfil de descriptografia, CA e quaisquer configurações globais.
  • Nomeie o proprietário, critérios de anulação, processo de exceção e caminho de reversão.

A CA de nova assinatura deve estar no armazenamento confiável dos sistemas operacionais ou navegadores afetados. Como alternativa, use uma autoridade de certificação corporativa subordinada. Uma CA publicamente confiável não está disponível para essa finalidade porque o firewall assina novamente certificados para domínios de terceiros. Com uma CA externa, tanto a CA raiz quanto a subordinada devem ser importadas; se a CA de assinatura contiver uma seção EKU, ela deverá permitir TLS Web Server Authentication. Instalar certificado CA do Sophos Firewall para verificação HTTPS descreve a distribuição, enquanto Configurar uma CA subordinada para inspeção TLS do Sophos Firewall cobre o método CA corporativo.

⚠️ Não comece com todos os usuários. Dispositivos sem armazenamento confiável gerenciável, BYOD e aplicativos que usam fixação de certificado devem inicialmente permanecer em um escopo separado. Uma exceção restaura a conexão, mas remove seu conteúdo da descriptografia.

Mantenha o DPI e o Web Proxy separados

SFOS usa DPI engine por padrão. Nesse caminho, o firewall processa primeiro a Regra de Firewall e depois as Regras de Inspeção SSL/TLS. A Regra de Inspeção por si só não permite tráfego: mesmo Services: Any significa apenas que o tráfego TLS já permitido pela Regra de Firewall em qualquer porta TCP é elegível para esta Regra de Inspeção.

Para o caminho DPI, abra Rules and policies > Firewall rules, edite a regra LAN para WAN relevante e verifique Security features > Web filtering:

  1. Deixe Use web proxy instead of DPI engine desativado.
  2. Selecione uma Política Web somente se a proteção planejada assim o exigir; não é um pré-requisito para a regra de descriptografia.
  3. Scan HTTP and decrypted HTTPS permite a verificação de malware para HTTP e HTTPS que já foram descriptografados. A opção por si só não permite a descriptografia HTTPS.

Em Web Proxy Mode, o proxy lida com a descriptografia HTTPS. Decrypt HTTPS during web proxy filtering é a configuração relevante no caminho do proxy. As regras de DPI em Rules and policies > SSL/TLS inspection rules não se aplicam a conexões descriptografadas pelo Web Proxy. Com o proxy transparente, as portas 80 e 443 passam pelo proxy enquanto o SSL/TLS em outras portas ainda pode ser tratado pelo caminho DPI; com o Proxy Explícito, o Web Proxy executa a descriptografia.

As CAs também são separadas: o DPI usa a CA das configurações SSL/TLS ou do perfil de descriptografia selecionado. O Web Proxy usa a CA de Web > General settings. Ao mudar de modo, verifique não só as regras, mas também a CA efetivamente apresentada. Escolha o mecanismo DPI ou o proxy da Web corretamente explica as diferenças com mais detalhes.

Este caminho de inspeção de saída não se destina a servidores Web publicados na Internet. Web Server Protection/WAF ou um proxy reverso geralmente é a arquitetura mais adequada. As regras de inspeção SSL/TLS se aplicam ao tráfego de saída, portanto, apenas zonas internas podem ser selecionadas como Source zones. Elas detectam TLS em qualquer porta TCP, mas não são aplicadas em UDP.

Incluir QUIC no percurso de inspeção

QUIC, ou HTTP/3, usa UDP. Block QUIC protocol em uma regra de firewall descarta pacotes UDP de saída para as portas 80 e 443 dentro do escopo dessa regra, forçando os clientes a recorrer a um caminho TCP inspecionável. O SFOS seleciona a opção por padrão assim que uma Política da Web é selecionada na regra ou Scan HTTP and decrypted HTTPS é habilitado. Isso é por regra, não global, portanto verifique a regra de firewall que realmente corresponde.

Este filtro da web não pode verificar o QUIC. Isso não significa que todos os outros controles de firewall sejam ignorados, mas o TCP TLS esperado e o caminho do filtro da web não se aplicam. Bloqueando corretamente QUIC e HTTP/3 no Sophos Firewall mostra o teste de regra; Criando uma Política de Proteção Web do Sophos Firewall abrange a Política Web.

Selecione o escopo por propósito e risco

O ponto de partida usual é o tráfego de usuário gerenciado de LAN para WAN. Uma rede sem fio corporativa separada pode seguir como Wi-Fi > WAN. Para acesso remoto, VPN > WAN só é relevante quando o tráfego de Internet dos usuários realmente atravessa o firewall através de um túnel completo. Inclua conexões internas de LAN para DMZ somente quando a inspeção de conteúdo tiver um benefício claro e ambos os lados confiarem na CA de nova assinatura.

A compatibilidade técnica e a permissão para descriptografar são decisões separadas. Portais bancários, de saúde e governamentais, gerenciadores de senhas, provedores de identidade, atualizações de sistemas operacionais e de fornecedores e serviços de voz, vídeo e colaboração exigem uma avaliação funcional e de privacidade antes da inclusão. A fixação ou uma falha piloto não justifica uma exceção geral para uma categoria inteira: primeiro identifique a origem, o domínio e a aplicação realmente necessários.

Configure um piloto completo

Para um piloto que pode ser testado diretamente, usamos estes valores de exemplo:

  • Cliente piloto: 10.20.30.50 da rede de teste documentada 10.20.30.0/24
  • Regra de firewall: LAN to WAN - TLS pilot
  • Regra de inspeção SSL/TLS: TLS decrypt pilot client
  • Zona de origem: LAN, Zona de destino: WAN
  • Redes e serviços de destino: Any
  • Ação: Decrypt
  • Perfil de descriptografia: inicialmente Block insecure SSL ou um perfil piloto derivado dele
  • Registro: Log connections habilitado para o piloto

10.20.30.0/24, o IP do host e os nomes dos objetos são exemplos. A fonte de produção deve ser estreita o suficiente para identificar um cliente de forma inequívoca. Any para Destino e Serviço facilita a observação de TLS fora do TCP 443 durante o piloto; ela não amplia o que a regra de firewall anterior permite. Se a inspeção for permitida apenas para um grupo de destino específico, adicione um grupo de URLs ou outro critério de destino apropriado.

Selecione um perfil de descriptografia

Em Profiles > Decryption profiles, três perfis padrão não editáveis ​​estão disponíveis:

  • Maximum compatibility maximiza a compatibilidade e não restringe cifras.
  • Block insecure SSL bloqueia cifras fracas e permite tráfego que não pode ser descriptografado.
  • Strict compliance aplica requisitos rigorosos, incluindo requisitos baseados em PCI DSS.

Maximum compatibility pode ajudar a isolar temporariamente um cliente problemático, mas suas verificações relaxadas o tornam inadequado como critério de aceitação de produção. Para o piloto, Block insecure SSL ou um perfil deliberadamente derivado dele é o ponto de partida mais transparente. Tolerar versões TLS antigas ou chaves RSA com menos de 2048 bits apenas para um servidor legado nomeado e em uma regra com escopo restrito.

Um perfil personalizado pode substituir as configurações globais de SSL/TLS. As opções de nova assinatura da CA são Use CAs defined in SSL/TLS settings, Re-sign RSA with e Re-sign EC with. Para tráfego que não pode ser descriptografado, as opções são Use SSL/TLS settings default, Allow without decryption, Drop e Reject. A referência padrão global não se aplica a Unrecognized cipher suites; este caso deve ser avaliado explicitamente no perfil. Dependendo da configuração, erros de certificado, tamanho mínimo de RSA, versões TLS e cifras bloqueadas usam Drop, Reject ou Reject and notify como Block action.

A inspeção não torna confiável um certificado de servidor autoassinado ou com uma cadeia incompleta. Em vez de excluí-lo apressadamente, primeiro verifique o nome do host, o certificado original e a cadeia completa.

Com o TLS 1.3, erros de certificado, o tamanho mínimo do RSA, um downgrade global e Reject and notify se comportam conforme documentado apenas com Action: Decrypt. Com Don’t decrypt ou Deny, Reject é usado para esse tratamento de perfil. Um downgrade global para o TLS 1.2 apresenta um risco de segurança e não é uma correção geral de compatibilidade.

Crie a regra e verifique sua ordem

Em Rules and policies > SSL/TLS inspection rules > Add, configure os campos conforme a seguir:

  1. Rule name: TLS decrypt pilot client
  2. Rule position: Top, portanto, a regra piloto precede as regras gerais de descriptografia personalizadas
  3. Action: Decrypt
  4. Log connections: habilitado para monitoramento piloto
  5. Decryption profile: o perfil piloto selecionado
  6. Source zones: LAN
  7. Objeto de host Source networks and devices: para 10.20.30.50
  8. Destination zones: WAN
  9. Destination networks: Any
  10. Services: Any
  11. Categories and websites: vazio ou limitado ao escopo de destino aprovado

Log connections é opcional e não é necessário para que a regra funcione. No entanto, é útil para um piloto com tempo limitado porque o handshake e o fechamento da conexão podem ser rastreados. A retenção deve seguir a política de privacidade e operações acordada.

A tabela é avaliada de cima para baixo e o processamento é interrompido na primeira correspondência. Todos os critérios configurados devem corresponder simultaneamente. A regra padrão fixa Exclusions by website or category permanece na parte superior e não pode ser precedida pela seleção de Rule position: Top. Coloque exceções Don't decrypt personalizadas imediatamente abaixo dele, seguidas por regras piloto específicas e, finalmente, regras de descriptografia mais amplas.

Os critérios de usuário e grupo serão confiáveis ​​somente se o SFOS conhecer o contexto do usuário para a conexão. Se isso não for garantido, comece com um host ou objeto de rede inequívoco e adicione critérios de identidade somente após um teste de correspondência separado.

Mantenha as exceções restritas

A regra padrão Exclusions by website or category utiliza Don’t decrypt com Maximum compatibility e permanece na primeira posição. A Local TLS exclusion list está vazia por padrão; a Managed TLS exclusion list contém sites incompatíveis conhecidos e é mantida por meio de atualizações de firmware.

Edite a lista local em:

Web > URL groups > Local TLS exclusion list

Grupos de URL ou correspondências SNI são mais eficientes para exceções de domínio do que muitos hosts FQDN. De acordo com a Sophos, por exemplo, os hosts FQDN 200 causam pesquisas 200 para cada nova conexão SSL/TLS. As exceções de origem e destino também não podem ser combinadas. Criar e usar grupos de URL com segurança explica o escopo do domínio, curingas e testes negativos.

Uma regra de inspeção SSL/TLS personalizada com Action: Don’t decrypt deve registrar o domínio, a fonte afetada, o motivo, o ticket, o proprietário e a data de revisão. Don’t decrypt não é um desvio incondicional: as restrições do perfil de descriptografia selecionado ainda se aplicam. Para permitir SSL 2/3, compactação ou cifras desconhecidas para um caso legado explicitamente aprovado, use um perfil com Allow without decryption junto com Action: Don’t decrypt. Esta combinação não pertence a uma regra ampla da Internet.

Exclusões SSL/TLS e exceções da Web resolvem problemas diferentes. Uma exceção TLS controla a descriptografia em qualquer porta TCP no modo DPI. Uma exceção da Web altera as verificações selecionadas da política da Web; no modo proxy, afeta o caminho do proxy relevante. Antes de fazer uma alteração, determine se a descriptografia ou apenas uma verificação da web deve ser excluída. Criar e testar exceções da Web com segurança mostra o fluxo de trabalho de seleção e regex.

Compatibilidade com Android num âmbito restrito

Algumas conexões Android usam fixação de certificado. A verificação de conectividade, Play Store ou atualizações podem falhar na descriptografia. O fluxo de trabalho documentado pela Sophos usa uma VLAN isolada ou rede sem fio e um grupo de hosts FQDN contendo:

  • *.play.googlezip.net
  • *.gvt1.com
  • *.app-measurement.com
  • o domínio local do Google, por exemplo *.google.ch na Suíça

Acima da regra geral de descriptografia, adicione uma regra de inspeção SSL/TLS com Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone: Wi-Fi, a rede do dispositivo móvel como Source networks and devices, WAN como Destination zone e o grupo do Google como Destination networks. Fica abaixo da exclusão padrão fixa, mas acima da regra geral de descriptografia. Mantenha a rede móvel isolada de recursos internos confidenciais.

Aceite a alteração usando um dispositivo piloto Android: execute a verificação de conectividade, teste o navegador e faça um download e uma atualização pela Play Store. No Log viewer, apenas os destinos esperados do Google podem corresponder à exceção; outro destino HTTPS da mesma VLAN ainda deve usar a regra de descriptografia pretendida. Este teste negativo impede a aceitação de uma exceção que funciona, mas é muito ampla. Criar exceções da Web e exclusões de TLS com segurança aborda outros métodos e limitações de SNI.

Comprovar o funcionamento

Uma simulação de política, um cliente real e os logs respondem a diferentes questões. Combine-os para obter um teste de aceitação confiável.

Em Diagnostics > Tools > Pop-out tools > Policy tester, selecione Firewall, SSL/TLS, and web e defina o IP de origem, destino ou URL, protocolo e, se necessário, a porta. Sem um protocolo, a ferramenta testa o HTTP usando a porta padrão específica do protocolo. O testador de políticas simula tráfego transparente da web; ele não modela rotas SD-WAN e as regras com endereços MAC em Source networks and devices não correspondem lá. Web policy only testa apenas a Política da Web. O resultado é, portanto, uma previsão, não uma prova do caminho real dos dados.

Execute quatro testes direcionados no cliente:

  1. Antes da mudança, registre o domínio de destino, o emissor do certificado, o tempo de resposta e se o aplicativo de negócios funciona.
  2. Abra um destino positivo aprovado. O navegador deve mostrar a CA de nova assinatura selecionada para DPI como emissor, e Log viewer deve corresponder à regra de descriptografia e ao perfil de descriptografia esperados.
  3. Abra um destino deliberadamente excluído. Deve corresponder à regra Don't decrypt esperada; o navegador não deve mostrar um certificado assinado novamente pelo firewall.
  4. Um segundo destino não excluído do mesmo escopo de cliente ainda deve ser descriptografado. Este é o teste negativo da exceção.

Se uma Política da Web fizer parte do design, bloqueie também uma categoria de teste ou URL de teste especificamente aprovado para essa finalidade. Execute um teste de malware apenas com um objeto de teste de fornecedor documentado e inofensivo e um resultado esperado predefinido; este artigo não reivindica um teste de laboratório. Antes e depois do piloto, compare a carga de CPU e memória, o tempo de resposta e os erros do usuário na mesma janela de tempo.

Interpretar corretamente Control Center e Log viewer

O widget do Centro de Controle é denominado SSL/TLS connections. Seus detalhes são atualizados a cada cinco minutos. As sessões cobrem as últimas 24 horas e os erros os últimos 7 dias; Failed é redefinido à meia-noite. Os dados detalhados não incluem conexões Web Proxy. Decryption peak aparece apenas próximo ou acima do pico e Decryption limit apenas próximo ao limite específico do dispositivo. Portanto, não existe um limite universal para todos os aparelhos.

Sophos Firewall - widget SSL/TLS connections com sessões descriptografadas e não descriptografadas
Sophos Firewall - Control Center > SSL/TLS connections

Abra Log viewer no canto superior direito e selecione o módulo SSL/TLS inspection. Uma conexão TLS é registrada após a conclusão do handshake e quando ele é fechado. Ação, regra, perfil de descriptografia, origem, destino, domínio e o motivo do erro são importantes; as cores por si só não são um critério de aceitação confiável. Em Manage > Exclude, você pode adicionar domínios ou subdomínios à lista de exclusão TLS local e categorias à exclusão padrão. Exclude não está disponível para IDs de erro 19004 e 19005.

Sophos Firewall - Visualizador de logs com eventos de inspeção SSL/TLS
Sophos Firewall - Log viewer > SSL/TLS inspection

Um evento Don't decrypt prova apenas que a conexão não foi descriptografada. Somente a Regra, a correspondência de lista e o teste negativo mostram se a exceção é justificada e suficientemente restrita.

Solucione problemas e reverta com segurança

Quando ocorrer um incidente, limite inicialmente o caso a um cliente, um domínio, um momento específico, uma regra de firewall e uma regra de inspeção SSL/TLS.

  • Se o navegador exibir um aviso de certificado, compare o emissor visível com a CA usada pelo DPI real ou pelo caminho do proxy. Em seguida, verifique o armazenamento confiável do cliente, a cadeia raiz/subordinada e o nome do host.
  • Se faltarem eventos SSL/TLS, verifique primeiro a correspondência da regra de firewall e o modo. Em seguida, confirme se Rules and policies > SSL/TLS inspection rules e Advanced settings > SSL/TLS engine > Enabled estão ativos.
  • Se o tráfego for permitido, mas não descriptografado, pesquise de cima para baixo a exclusão padrão fixa, a lista gerenciada/local ou uma regra Don't decrypt personalizada. Em seguida, repita o teste negativo.
  • Se o filtro da web não se aplicar, verifique a regra de firewall real para sua política da web, Scan HTTP and decrypted HTTPS, Block QUIC protocol e modo DPI/proxy. A presença de uma Política da Web não prova a descriptografia.
  • Se apenas um aplicativo falhar, use o motivo do erro, a versão do TLS, a cifra, a cadeia de certificados e a fixação para orientar a próxima decisão. Mantenha qualquer exceção temporária restrita e estabeleça uma data de revisão.
  • Se a carga aumentar, reduza o escopo do piloto e compare a mesma janela de tempo antes e depois da mudança. Avalie avisos de pico ou limite para o aparelho específico.

Desative o SSL/TLS engine apenas brevemente para solução de problemas. Enquanto desativado, nenhuma regra de inspeção SSL/TLS se aplica e o mecanismo DPI não aplica a política da Web do firewall a HTTPS; A descriptografia HTTPS do proxy da Web permanece inalterada. Desabilitá-la não é, portanto, um substituto equivalente e de baixo risco para desabilitar especificamente a regra piloto.

Teste IPS independente de porta apenas com um estado inicial conhecido

Por padrão, o SFOS verifica o tráfego descriptografado em relação às assinaturas IPS em cada porta TCP. Para um falso positivo reproduzível, documente o ID da assinatura, a origem, o destino, a porta TCP, a regra de firewall, a regra de inspeção e a build do SFOS. Prefira uma exceção de assinatura restrita com Action: Allow packet na Política IPS realmente em uso; Configurar e testar o Sophos Firewall IPS descreve esse método.

Um possível sintoma de um problema com a inspeção independente da porta são as correspondências repetidas da mesma assinatura IPS no mesmo sítio Web. A repetição, por si só, não prova um falso positivo. Verifica-se a correspondência exata da Signature ID e do destino nos registos, confirma-se o fluxo de trabalho legítimo afetado e avalia-se o risco antes de aprovar uma exceção de assinatura de âmbito restrito e reversível.

A inspeção mais abrangente de potenciais ameaças pode aumentar a carga e reduzir ligeiramente o débito do tráfego HTTPS decifrado em comparação com versões anteriores do Sophos Firewall. Trata-se de um possível efeito associado à versão, não de uma redução garantida nem de uma prova de regressão da build atualmente utilizada. Para contextualizar os resultados, comparam-se o débito, a carga de CPU e memória e o tempo de resposta sob uma carga de tráfego comparável na mesma janela temporal; uma única comparação não substitui a análise das causas.

Uma comparação global no Console do dispositivo será permitida somente se o valor atual exato, on ou off, já for conhecido do registro de alteração ou de uma configuração com backup confiável. A documentação oficial do SFOS 22 não oferece pré-verificação somente leitura para esta opção. Se o estado inicial for desconhecido, não realize o teste.

Somente com um estado inicial documentado de on você pode definir o seguinte para uma comparação preparada:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

O segundo comando aqui restaura apenas o estado inicial conhecido de on. Se o estado inicial for off, não o habilite cegamente; retenha off ou restaure-o exatamente após qualquer alteração autorizada. Essa configuração global afeta todo o firewall e pode reduzir ligeiramente o rendimento ou, com off, restringir o escopo da inspeção. Documente o resultado e o intervalo de tempo sem tratar isso apenas como prova de uma causa geral.

Executar o rollback numa ordem definida

Uma reversão restaura o estado inicial documentado em vez de introduzir uma nova arquitetura:

  1. Desative a regra piloto TLS decrypt pilot client. Não altere o perfil, a Política da Web e as exceções ao mesmo tempo.
  2. Usando o cliente piloto, confirme se esta Regra não corresponde mais e se o caminho documentado anteriormente é usado novamente. Não presuma que as sessões existentes serão reavaliadas imediatamente; estabeleça uma nova conexão para o teste.
  3. Se apenas um destino for afetado e as operações exigirem isso, crie uma exceção Don't decrypt com limite de tempo e execute seu teste negativo.
  4. Após a aprovação, remova as exceções temporárias, objetos de teste e configurações de CA distribuídas apenas para o piloto de forma controlada. Não remova CAs compartilhadas sem verificar.
  5. Registre o ID da regra, o cliente, o destino, a CA visível, o evento de log, a hora e as configurações restauradas no registro de alteração.

A Política da Web pode permanecer configurada, mas sem a Descriptografia ela não poderá verificar a carga HTTPS criptografada. Reverter para Web Proxy somente se esse for o estado inicial verificado. Não desative todo o mecanismo SSL/TLS como reversão padrão porque isso interrompe todas as regras DPI TLS e a aplicação da Política Web DPI para HTTPS.

Interrompa a implementação assim que um aplicativo crítico para os negócios falhar, avisos de certificado aparecerem fora do grupo piloto, o escopo corresponder de forma mais ampla do que o esperado ou a carga e os erros excederem os limites predefinidos. Expanda o grupo Origem gradualmente somente depois que o teste positivo, o teste negativo de exceção, os aplicativos de negócios, os logs, o feedback do usuário e o perfil de carga atenderem aos critérios acordados durante o período acordado.

Durante a operação, revise exclusões, erros de TLS, novos aplicativos, carga e feedback do usuário em um cronograma definido. Mantenha as exceções temporárias apenas enquanto o proprietário, o motivo e a data da revisão permanecerem válidos; caso contrário, remova-os após um novo teste positivo e negativo.

PERGUNTAS FREQUENTES

A inspeção TLS deve ser habilitada imediatamente para todos os usuários?

Não. Comece com um grupo pequeno e gerenciado. Antes de expandir, verifique a distribuição da CA, o DPI real ou o caminho do proxy, as correspondências de regras, os aplicativos, a carga e a reversão.

Por que a inspeção TLS não funciona apesar de um certificado CA instalado?

O certificado apenas estabelece confiança na CA de nova assinatura. A regra de firewall anterior, o modo DPI ou proxy, a regra de inspeção SSL/TLS, sua ordem e o perfil de descriptografia também devem corresponder ao tráfego real.

Quando é necessária uma exceção TLS?

Quando um destino aprovado não pode ser descriptografado devido a fixação ou incompatibilidade técnica. Limite a exceção à origem e ao destino, registre-a e execute um teste negativo com outro destino do mesmo escopo de origem.

O QUIC deve ser bloqueado para inspeção TLS?

Sim, para o filtro da web baseado em TCP e o caminho de inspeção TLS descritos aqui. No entanto, Block QUIC protocol se aplica à Regra de Firewall relevante e deve ser verificado na regra que realmente corresponde; não é uma opção global.