O artigo genérico sobre SSL forward proxy explica a interceptação de TLS de saída de forma abstrata. Um FortiGate é um dos lugares mais amplamente implantados onde a interceptação de fato acontece, e a Fortinet a enquadra como dois modos distintos de inspeção SSL com uma linha clara entre eles. Este texto complementa o artigo genérico mapeando a terminologia e os perfis do FortiGate sobre ele, então assume a mecânica de forjar e terminar e foca nas especificidades do FortiGate.
Os dois modos, e a linha entre eles
O FortiOS aplica a inspeção SSL através de um perfil de inspeção SSL/ anexado a uma política de firewall. Ele vem com quatro perfis predefinidos: certificate-inspection, deep-inspection e no-inspection (somente leitura), mais custom-deep-inspection, que é editável; você também pode clonar qualquer um deles. A escolha importante é entre os dois primeiros.
A certificate inspection não descriptografa. Ela inspeciona apenas até o handshake SSL/TLS, lendo o Server Name Indication e os campos no certificado do servidor (o subject e o subject-alternative-name), e então toma uma decisão de segurança apenas a partir dessa metadata em texto claro. Isso é suficiente para fazer filtragem web por nome de host ou categoria, e nada mais: como o payload nunca é descriptografado, a certificate inspection não pode conduzir antivírus, (sistema de prevenção de intrusão, do inglês intrusion prevention system), ou controle de aplicação, todos os quais precisam do conteúdo real. Duas limitações valem notar da documentação da Fortinet: a certificate inspection não valida o certificado (no modo flow, verificações de certificado não confiável e de do certificado do servidor não são realizadas), e o perfil embutido certificate-inspection é somente leitura e escuta apenas na porta 443, então inspecionar HTTPS numa porta não padrão significa criar um perfil customizado. É a opção que preserva a privacidade e de baixo impacto para quando você só precisa controlar quais sites são alcançados.
A deep inspection (também chamada de full SSL inspection) é o man-in-the-middle completo. O FortiGate se faz passar pelo destinatário da sessão TLS do cliente: ele estabelece duas sessões criptografadas, uma cliente-para-FortiGate e uma FortiGate-para-servidor, descriptografa e inspeciona o conteúdo entre elas, então recriptografa e encaminha ao destinatário real. Apenas o FortiGate, no meio, vê texto claro. É isso que destrava a segurança profunda: antivírus, IPS, DLP e controle de aplicação podem todos rodar no fluxo descriptografado, e a deep inspection cobre não só HTTPS mas outros protocolos embrulhados em TLS como SMTPS, POP3S, e .
O certificado que faz a deep inspection funcionar (ou avisar)
A deep inspection é exatamente o modelo genérico de interceptação: para apresentar um certificado para um site que ele não possui, o FortiGate reassina o certificado do servidor com uma armazenada. Por padrão essa CA é a Fortinet_CA_SSL (há também a Fortinet_CA_Untrusted para servidores cujo próprio certificado falhou na validação, e você pode subir sua própria CA). Como a Fortinet_CA_SSL não está nas listas de raízes confiáveis dos navegadores por padrão, um cliente não provisionado mostra um aviso de certificado em todo site com deep inspection, o navegador corretamente detectando um man-in-the-middle não reconhecido. A correção é a mesma do artigo genérico: distribuir o certificado da CA do FortiGate para o armazenamento de Raízes Confiáveis dos clientes (comumente por group policy do em frotas Windows gerenciadas). E como sempre, a deep inspection é derrotada por certificate pinning e , e a Fortinet suporta allowlists de endereço e de categoria web para isentar tráfego sensível ou com pinning (bancário, saúde) da descriptografia.
Flow versus proxy: dois engines, alcance diferente
Um detalhe específico do FortiGate que molda o comportamento: o FortiGate realiza a inspeção com um de dois engines. O engine IPS trata da inspeção baseada em flow, e o daemon (Daemon de Aplicação Web, do inglês Web Application Daemon) trata da inspeção baseada em proxy. Eles miram o mesmo objetivo, descriptografar TLS para outros engines inspecionarem, mas suas capacidades diferem porque um é flow e o outro é um proxy. Duas consequências importam na prática. Primeira, o mapeamento de porta de protocolo (dizer ao FortiGate que o IMAPS está numa porta não padrão, por exemplo) só funciona na inspeção baseada em proxy; a inspeção baseada em flow inspeciona todas as portas independentemente. Segunda, o modo de inspeção é definido tanto no nível da política quanto no do perfil e eles precisam concordar, se o perfil de segurança é baseado em proxy, a política precisa estar em modo proxy. O modo de política padrão é flow; o modo proxy é usado quando você precisa de opções exclusivas de proxy. A divisão de engine também afeta funcionalidades como páginas de bloqueio de mensagem de substituição, que se comportam de forma diferente entre os dois modos.
O resultado espelha o artigo genérico: a certificate inspection é a opção ver-o-rótulo, não-abrir-o-envelope para filtragem web com disrupção mínima e privacidade preservada; a deep inspection é a opção abrir-o-envelope exigida para segurança de conteúdo real, ao custo de gerenciar uma CA confiável em todo cliente e manter exceções para o tráfego que o pinning, o HSTS e a lei colocam fora dos limites.