Firewall Aware de Conteúdo e Conteúdo Criptografado

4

Existem firewalls por aí que analisam o tráfego que passa e o bloqueiam caso não seja desejado. Até que ponto esses firewalls funcionam com tráfego criptografado? HTTPS ou IMAP por SSL?

Um exemplo: um firewall pode distinguir entre o tráfego HTTPS na porta 443 e, digamos, o tráfego seguro da Área de Trabalho Remota por 443?

    
por Heinrich 23.11.2011 / 11:59

2 respostas

11

No seu exemplo específico, sim, é possível.

O HTTPS inicia uma sessão TLS com o controle remoto.

TLSv1  Client Hello

O Secure RDP inicia uma sessão RDP que negocia uma conexão segura TLS entre as duas extremidades da sessão.

X.224  Connection Request (0xe0)

Como os protocolos de início de sessão são diferentes, um firewall com monitoração de estado deve ser capaz de discriminar entre uma conexão HTTPS sendo iniciada e outra coisa.

Para o caso genérico, um firewall não será capaz de detectar algo como SSH-over-HTTPS vez que o tráfego SSH está escondido dentro do tráfego HTTPS. A única maneira de detectá-lo é através da análise heurística dos padrões de tráfego, mas não sei de nada que faça isso.

Para o IMAP, existem dois modos de protegê-lo. Um é via SSL, outro é via TLS. O método SSL se parece com uma conexão HTTPS apenas em uma porta diferente e, se a porta remota for a mesma, não há muito o que fazer a respeito. O TLS, por outro lado, é negociado entre os dois extremos da conversa, de modo que a inicialização da sessão é marcadamente diferente e facilmente detectável.

A principal coisa a ter em mente é que o SSL cria um wrapper TCP através do qual o tráfego é passado. Muitos protocolos incluem um método de segurança negociada dentro do próprio protocolo que aproveita muito as mesmas tecnologias o wrapper usa, mas utiliza um método de inicialização de sessão diferente, que faz com que seja diferenciável.

    
por 28.11.2011 / 17:41
6

Alguns produtos de firewall / proxy podem executar um “ataque man-in-the-middle autorizado” em conexões TLS; por exemplo, o Squid chama esse recurso de " SSL Bump ". Um servidor proxy que faz isso terá acesso total aos dados de texto simples transmitidos dentro da sessão TLS. No entanto, um cliente por trás desse proxy obterá um certificado de servidor diferente (fornecido pelo próprio proxy em vez do servidor real), que causará erros ou avisos de TLS, a menos que o cliente esteja configurado para esperar esses certificados (adicionando o certificado CA de proxy para a lista de certificados raiz confiáveis).

    
por 28.11.2011 / 19:15