Existem firewalls que analisam o tráfego que passa e o bloqueiam se não for desejado. Quão bem esses firewalls funcionam com tráfego criptografado, por exemplo, HTTPS ou IMAP sobre 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 na porta 443?
Responder1
No seu exemplo específico, sim, é possível.
HTTPS inicia uma sessão TLS com o controle remoto.
TLSv1 Client Hello
O RDP seguro 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 estado deve ser capaz de discriminar entre uma conexão HTTPS iniciada e outra coisa.
Para o caso genérico, um Firewall não será capaz de detectar algo como SSH sobre HTTPS, pois o tráfego SSH está oculto 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 conheço nada que faça isso.
Para IMAP, existem dois modos de proteção. 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 que possa ser feito a respeito. O TLS, por outro lado, é negociado entre ambas as extremidades da conversa, de modo que a inicialização da sessão é marcadamente diferente e facilmente detectada.
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 praticamente as mesmas tecnologias que o wrapper usa, mas usa um método de inicialização de sessão diferente que o torna diferenciável.
Responder2
Alguns produtos de firewall/proxy podem realizar um “ataque man-in-the-middle autorizado” em conexões TLS; por exemplo, o Squid chama esse recurso de “Aumento de SSL”. Um servidor proxy que faça isso terá acesso total aos dados de texto simples transmitidos dentro da sessão TLS. No entanto, um cliente por trás de tal proxy obterá um certificado de servidor diferente (fornecido pelo próprio proxy em vez do servidor real), o que causará erros ou avisos de TLS, a menos que o cliente esteja configurado para esperar tais certificados (adicionando o certificado CA do proxy à lista de certificados raiz confiáveis).