Fortigate y TLS 1.3: Parte 1

Llevaba unos meses con un expediente X y la semana pasada no tuve más remedio que ponerme manos a la obra para intentar solucionarlo. Un cliente se quejaba de que en la versión 6.2 de Fortigate, con políticas en modo flow y con inspección de certificado y webfilter activado, cuando navegaba por páginas HTTPS le salta un mensaje el navegador indicando que el FW se estaba haciendo man-in-the-midle, es decir, estaba haciendo deep-inspection.

Este es el mensaje de error que daba en Firefox:

Con la progresiva implantación de TLS 1.3, un protocolo más rápido y más seguro, en el cual todos los datos del certificado están cifrados había que cambiar la forma en que Fortigate con solo la inspección del certificado puede bloquear aquellas páginas que el cliente quiere bloquear a sus usuarios.

Hasta TLS 1.2 cuando se utiliza la inspección de certificados SSL, el protocolo de enlace SSL no se interrumpe, pero Fortigate lee el campo CN del certificado. Esta campo CN tiene la URL para la que se firmó el certificado. De esta manera, FortiGate utiliza esta URL para verificar en su base de datos la categoría a la que pertenece. Porque una vez que se establece la sesión SSL/TLS, no hay forma de leer su contenido.

Como he dicho en la nueva versión del protocolo TLS 1.3, el certificado del servidor está encriptado en el saludo del servidor y FGT no puede compararlo con el SNI en el saludo del cliente. Entonces, Fortigate intentará conectarse al mismo servidor con una sesión auto-generada y ver el certificado del servidor para verificar si el certificado del servidor presentado corresponde a lo que el cliente ha solicitado, si esa sesión falla por alguna razón, volverá a solicitar el certificado en la sesión del cliente, y parecerá que esta actuando como si estaría inspección profunda o deep inspection.

Resumen de TLS 1.3:

1- Consulta del SNI en el mensaje de hello de la negociación de la conexión cifrada
2- Consulta los campos de  CN o SAN en el certificado devuelto debido al cifrado TLS, con una sesión auto-generada que el propio FGT intentara realizar contra e mismo servidor

Continuando con mi caso, en un primer momento decidí pasar la política a modo proxy con eso ya no le salían mensajes al cliente y estaba solucionado, pero necesito una plataforma con el mejor rendimiento por lo que prefiero que las políticas sean en modo flow. Continuando con la investigación y viendo como funciona Fortigate con TLS 1.3, vi que dentro de los perfiles de ssh-ssh para certificado inspection tenemos la siguiente opción:

config firewall ssl-ssh-profile
     edit <name>
        config https
             set sni-server-cert-check enable/disable/strict                 
        end

Check the SNI in the client hello message with the CN or SAN fields in the returned server certificate.

enable:  Check the SNI in the client hello message with the CN or SAN fields in  the returned server certificate. If mismatched, use the CN in the server  certificate to do URL filtering.
strict: Check the SNI in  the client hello message with the CN or SAN fields in the returned  server certificate. If mismatched, close the connection.
disable: Do not check the SNI in the client hello message with the CN or SAN fields in the returned server certificate.

Por defecto viene en enable, decidí ponerlo en disable y ver si funcionaba bien, y efectivamente al ponerlo en disable, seguía bloqueando aquellas páginas cuyas categorias estaban bloquedo su acceso y ya no me salía en mensaje de error en el resto de páginas permitidas. Si se deshabilita, verificará el SNI en el saludo del cliente para el filtro de URL, pero NO podrá verificar CN o SAN en el certificado devuelto debido al cifrado TLS.

Estas opciones NO dependen tanto de versión del FortiOS sino de la versión del motor de ips:

6.0
IPS Engine 	Version 4.00061
No tengo este problemas

6.2
IPS Engine 	Version 5.00229
Tengo este problemas

Por lo tanto, en mi caso parece que estaba fallando la opciones de verificar el CN o SAN en la sesión auto-generada por el propio Fortigate para poder leer esos campos del certificado. Me imaginaba que era un problema de comunicación.

El entorno que tengo es con VDOMs y BGP en cada vdom, por lo que pensé que tenia que ver alguna cosa más para que desde el vdom root (managment vdom) de la plataforma NO pudiera generar esta conexión.

Descubri que esta nueva funcionalidad de autogenerar una sesión para verificar el certificado, Fortigate la llama TLS Active Probing: con ella el propio FortiGate genera sus propias conexiones hacia los servidores destino, estas son independientes de las peticiones de los usuarios, y así para poder analizar en detalle los certificados. Fortigate las hace para liberar a la CPU von el motor de IPS.

 config ips global
    config tls-active-probe
       set interface-selection-method <auto|sdwan|specify>
       set interface <intf name>            
       set vdom <vdom name>                 
       set source-ip <source_ipv4>          
     end
end

Configurando el vdom, interface y source ip del vdom root para generar esta conexiones, se solucionaron los problemas.

Espero que con este post haya solucione algún quebradero de cabeza a alguna persona que tenga este mismo problema.

¡¡¡¡¡ Hasta el próximo BLOG !!!!!!.