Existen firewalls que analizan el tráfico que pasa y lo bloquean si no es necesario. ¿Qué tan bien funcionan estos firewalls con tráfico cifrado, por ejemplo, HTTPS o IMAP sobre SSL?
Un ejemplo: ¿Puede un firewall distinguir entre el tráfico HTTPS en el puerto 443 y, digamos, el tráfico de Escritorio remoto seguro a través del 443?
Respuesta1
En su ejemplo específico, sí, es posible.
HTTPS inicia una sesión TLS con el control remoto.
TLSv1 Client Hello
Secure RDP inicia una sesión RDP que negocia una conexión segura TLS entre los dos extremos de la sesión.
X.224 Connection Request (0xe0)
Debido a que los protocolos de inicio de sesión son diferentes, un firewall con estado debería poder discriminar entre el inicio de una conexión HTTPS y otra cosa.
Para el caso genérico, un firewall no podrá detectar algo como SSH sobre HTTPS ya que el tráfico SSH está oculto dentro del tráfico HTTPS. La única forma de detectarlo es mediante un análisis heurístico de los patrones de tráfico, pero no conozco nada que haga eso.
Para IMAP, hay dos modos de protegerlo. Uno es vía SSL, otro es vía TLS. El método SSL se parece a una conexión HTTPS solo que en un puerto diferente, y si el puerto remoto es el mismo, entonces no hay mucho que pueda hacer al respecto. TLS, por otro lado, se negocia entre ambos extremos de la conversación, por lo que el inicio de la sesión es marcadamente diferente y se detecta fácilmente.
La clave a tener en cuenta es que SSL crea un contenedor TCP a través del cual pasa el tráfico. Muchos protocolos incluyen un método de seguridad negociada dentro del propio protocolo que aprovecha prácticamente las mismas tecnologías que utiliza el contenedor, pero utiliza un método de inicio de sesión diferente que lo hace diferenciable.
Respuesta2
Algunos productos de firewall/proxy pueden realizar un “ataque de intermediario autorizado” en conexiones TLS; por ejemplo, Squid llama a esta característica “Mejora SSL”. Un servidor proxy que haga esto tendrá acceso completo a los datos de texto sin formato transmitidos dentro de la sesión TLS. Sin embargo, un cliente detrás de dicho proxy obtendrá un certificado de servidor diferente (proporcionado por el propio proxy en lugar del servidor real), lo que provocará errores o advertencias de TLS a menos que el cliente esté configurado para esperar dichos certificados (agregando el certificado de CA del proxy). a la lista de certificados raíz confiables).