Implementación correcta de la inspección TLS en Sophos Firewall

Una gran parte del tráfico web actual está cifrado. Sin inspección TLS, el firewall a menudo solo ve la IP de destino, SNI, información del certificado y metadatos, pero no el contenido real de la conexión.

Esto es un problema de seguridad: muchas funciones de protección no pueden examinar la carga útil cifrada o solo de manera muy limitada. El escaneo de malware, la protección web, el análisis de día cero, el escaneo de contenido y partes de la detección de aplicaciones o amenazas solo son realmente efectivos cuando el firewall puede descifrar, examinar y luego volver a cifrar el tráfico TLS. IPS y NDR también se benefician de una mayor visibilidad en texto claro. Sin descifrado, muchas señales se limitan a metadatos, certificados, IPs, dominios o información de protocolo.

Sin embargo, la inspección TLS no es una función que deba activarse sin preparación para todos los usuarios. Puede interferir con aplicaciones, tocar cuestiones de privacidad y aumentar la carga del firewall. Por lo tanto, la inspección TLS debe implementarse de manera planificada, gradual y con una estrategia clara de excepciones.

Orientación

Primero conviene elegir el método de protección o configuración adecuado para el caso real. Así se evitan reglas demasiado amplias y diagnósticos duplicados.

Licencia y requisitos previos

Para la inspección TLS y la evaluación efectiva del tráfico descifrado, se necesitan las licencias de protección adecuadas.

Son especialmente importantes:

• Protección web: Incluye seguridad web, control web, control de aplicaciones y protección contra malware web.
• Protección de red: Incluye, entre otros, IPS, Security Heartbeat y otras funciones de protección de red.
• Protección de día cero: Es importante cuando se desea analizar archivos o descargas adicionalmente mediante aprendizaje automático o sandbox.

La protección web está incluida en el paquete de licencias Protección estándar. Protección Xstream y Protección épica también incluyen protección web y otros módulos de protección. Para la clasificación de los paquetes, consulte ¿Qué paquetes de Sophos Firewall existen?; para la licencia base, estado de soporte y suscripciones, consulte Entender la licencia base de Sophos Firewall.

Importante para la planificación: las SSL/TLS Inspection Rules y los URL groups también pueden ser relevantes con una Base License. Las web categories pueden configurarse, pero sin Web Protection no se aplican como criterio de categoría web. Quien quiera usar categorías, Web Policies, malware scanning o funciones Zero-Day de forma seria necesita la licencia de protección adecuada y no debería descubrirlo solo durante el piloto.

Antes del despliegue, se debe verificar:

• Está instalada la versión actual del firmware de Sophos Firewall.
• La protección web está licenciada.
• El certificado CA del firewall está distribuido en los clientes.
• Se ha definido un grupo de prueba o una red de prueba.
• El retroceso está documentado.
• El proceso de excepciones está aclarado.
• El registro está activado.

Si el certificado CA aún no está distribuido, el artículo Instalar el certificado CA de Sophos Firewall para escaneo HTTPS puede ser útil.

⚠️ La inspección TLS puede interferir con aplicaciones que utilizan fijación de certificados o realizan sus propias verificaciones de certificados. El despliegue siempre debe comenzar con un grupo de prueba y no directamente con todos los usuarios.

La CA de re-firma debe ser de confianza para los endpoints. En la práctica, esto significa distribuir el certificado al trust store del sistema operativo o del navegador, o usar una CA empresarial subordinada. No se puede obtener simplemente una CA pública de confianza para esto, porque la firewall firma nuevos certificados de servidor para dominios ajenos durante el descifrado.

¿DPI o Web Proxy?

Sophos Firewall puede implementar el descifrado HTTPS en dos modos de operación:

• Modo DPI: La regla del firewall utiliza el motor DPI. Las reglas de inspección SSL/TLS bajo Rules and policies > SSL/TLS inspection rules deciden qué se descifra.
• Modo Web Proxy: La regla del firewall utiliza el proxy web. El descifrado HTTPS se controla entonces a través de la configuración del proxy web y las políticas web.

En configuraciones modernas se usa a menudo DPI Mode. Sophos Firewall evalúa primero la regla firewall y después las SSL/TLS Inspection Rules. Si una regla firewall fuerza Web Proxy, las reglas SSL/TLS Inspection basadas en DPI no se aplican como se esperaría en una regla Direct Mode.

1. Abrir Rules and policies > Firewall rules.
2. Editar la regla LAN-to-WAN afectada.
3. Abrir Security features > Web filtering.
4. Activar la política web adecuada.
5. Activar Scan HTTP and decrypted HTTPS.
6. Dejar Use web proxy instead of DPI engine desactivado si deben aplicarse las SSL/TLS Inspection Rules.

Scan HTTP and decrypted HTTPS es importante, pero no activa por sí solo el descifrado HTTPS. En DPI Mode se necesitan además SSL/TLS Inspection Rules adecuadas. En Web Proxy Mode, el descifrado HTTPS debe activarse mediante las opciones del proxy. Si Use web proxy instead of DPI engine está activado, el proxy filtra el tráfico web clásico en los puertos 80 y 443, mientras que DPI engine puede seguir tratando tráfico HTTP y SSL/TLS en otros puertos. Antes del rollout debe quedar claro si el entorno usa Web Proxy o DPI, de lo contrario las excepciones se buscarán más tarde en el lugar equivocado.

¿Qué tráfico se debe descifrar?

No se debe descifrar todo a ciegas. Una buena inspección TLS comienza con objetivos claros.

Objetivos iniciales razonables:

• LAN > WAN: tráfico web clásico de usuarios hacia Internet.
• Wi-Fi > WAN: clientes gestionados en la red Wi-Fi de la empresa.
• VPN > WAN: usuarios de acceso remoto, si su tráfico de Internet pasa por el firewall.
• LAN > DMZ: accesos internos a servidores propios, si se desea una revisión de seguridad allí y los certificados están distribuidos correctamente.

Tratar con precaución:

• Banca, salud, autoridades y portales altamente sensibles.
• Gestores de contraseñas y proveedores de identidad.
• Servicios de actualización de sistemas operativos y fabricantes.
• Aplicaciones móviles y dispositivos Android.
• Aplicaciones con fijación de certificados.
• Servicios de voz, video y colaboración, si se vuelven inestables debido al descifrado.
• Dispositivos Android, especialmente si están afectados Google services, Play Store o connectivity checks.

Para publicaciones de servidores desde Internet hacia la DMZ, la inspección TLS no es automáticamente la mejor solución. En servidores web, a menudo es más adecuado Protección de servidores web / WAF o un proxy inverso.

Considerar QUIC y la política web

Si el tráfico web no se examina como se esperaba a pesar de la inspección TLS, también se debe verificar QUIC o HTTP/3. Muchos navegadores pueden establecer conexiones HTTPS a través de UDP 443. Dependiendo del diseño de la regla y la política web, el tráfico puede no pasar por la ruta HTTPS clásica esperada a través de TCP 443.

En las reglas de Internet del cliente, se debe verificar conscientemente:

• ¿Está activa la política web adecuada?
• ¿Está activo Block QUIC protocol en la regla del firewall que realmente coincide?
• ¿Está configurado Scan HTTP and decrypted HTTPS de acuerdo con la estrategia de descifrado?
• ¿La regla utiliza DPI o Web Proxy?
• ¿Se ven en el Log Viewer UDP 443, TCP 443, eventos de política web y eventos de inspección SSL/TLS de manera consistente?

El procedimiento para bloquear QUIC está en Bloquear correctamente QUIC y HTTP/3 en Sophos Firewall. Para la política web en sí, consulte Crear política de protección web en Sophos Firewall.

QUIC es especialmente engañoso porque Block QUIC protocol se activa automáticamente en algunos escenarios de web filtering, pero en reglas crecidas no necesariamente está activo en la regla que realmente hace match. En un piloto, por tanto, no basta con mirar la regla prevista; hay que comprobar el hit real en Log Viewer.

Planificar el rollout

TLS Inspection debe introducirse gradualmente para mantener controlables las excepciones, certificados de cliente y casos de soporte.

Estrategia de despliegue

Un enfoque escalonado ha demostrado ser efectivo:

1. Distribuir el certificado CA.
2. Preparar la política web y la regla del firewall.
3. Seleccionar el perfil de descifrado.
4. Definir un pequeño grupo de prueba.
5. Activar la regla de inspección SSL/TLS solo para este grupo.
6. Observar el Centro de Control y el Log Viewer.
7. Analizar errores y documentar excepciones claramente.
8. Ampliar gradualmente a otros grupos de usuarios.

De esta manera, se puede identificar temprano qué aplicaciones causan problemas sin afectar a toda la operación.

Planificar fases de despliegue

Un despliegue de inspección TLS debe planificarse en fases. Esto lo mantiene controlable y permite separar problemas técnicos de problemas de aceptación o aplicaciones.

• Preparación: CA, política web, regla del firewall y grupo de prueba están listos. Distribución de CA, licencia, registro, retroceso
• Piloto: pocos clientes gestionados prueban el día a día productivo. Log Viewer, widget del panel, retroalimentación de usuarios
• Ampliación: incluir otros grupos de usuarios o redes. Documentar excepciones, observar rendimiento
• Operación: La inspección TLS se revisa regularmente. Revisión de exclusiones, informes, errores y nuevas aplicaciones

Es importante que cada fase tenga un punto de interrupción claro. Si una aplicación crítica para el negocio falla en el piloto, no se debe establecer inmediatamente una excepción global amplia. Es mejor un análisis limpio: ¿Qué dominio, qué cliente, qué regla, qué perfil de descifrado y qué error en el Log Viewer están afectados?

Establecer piloto, propietario y proceso de excepciones

Antes del primer despliegue productivo, debe estar claro quién supervisa el grupo de prueba, quién aprueba las excepciones y cómo se informan los errores. De lo contrario, la inspección TLS genera rápidamente excepciones desordenadas: se establecen dominios individuales en Don't decrypt apresuradamente, sin que luego quede claro por qué existe la excepción.

Para la operación, estos puntos deben estar documentados:

• Grupo piloto, redes afectadas y período.
• Propietario de la política web, perfil de descifrado y reglas de inspección SSL/TLS.
• Proceso para nuevas excepciones con motivo, ticket y fecha de revisión.
• Criterios para cuándo se excluye una aplicación y cuándo se examina primero la causa.
• Lugar donde se recopilan el Log Viewer, el widget del panel y la retroalimentación de los usuarios.
• Retroceso, si se interrumpen aplicaciones críticas para el negocio.

Es especialmente importante la separación entre excepción técnica y decisión de seguridad permanente. Una excepción temporal puede ser útil para que un servicio vuelva a funcionar. Sin embargo, esta excepción debe reevaluarse más tarde, una vez que se comprendan la causa, el riesgo y la alternativa.

Probar el rollback antes del rollout

El rollback no debe improvisarse en caso de incidencia. Antes del piloto debe estar claro cómo retirar TLS Inspection para el grupo de prueba sin desordenar otras reglas, Web Policies o excepciones.

Comprobación práctica del rollback:

• Eliminar el grupo de prueba: comprobar que la SSL/TLS Inspection Rule ya no haga match para el cliente piloto.
• Desactivar la regla: controlar que el tráfico vuelva al camino esperado sin decryption.
• Probar la excepción: una regla específica Don't decrypt debe estar por encima de la regla general Decrypt y verse en el Log Viewer.
• Mantener la Web Policy: el rollback del descifrado no debe eliminar por accidente web filtering, malware scanning o logging.
• Documentar la prueba: registrar cliente de prueba, dominio de destino, nombre de regla, evento de log y hora.

Esta prueba es especialmente importante cuando varios administradores trabajan en Web Policies, reglas de firewall y SSL/TLS Inspection Rules. Un rollback limpio solo retira el scope afectado y no deja ciega toda la cadena de Web Protection.

Configuración

La configuración debe ser precisa, comprobable y fácil de revisar más adelante.

Entender los perfiles de descifrado

Un perfil de descifrado define cuán estrictamente maneja el firewall las conexiones TLS. Los perfiles se encuentran en Profiles > Decryption profiles.

Un perfil de descifrado responde, entre otras, a estas preguntas:

• ¿Qué sucede con los certificados no válidos o no confiables?
• ¿Se bloquean las versiones antiguas de TLS?
• ¿Se bloquean las suites de cifrado inseguras?
• ¿Qué sucede con la compresión SSL?
• ¿Qué sucede con las suites de cifrado no reconocidas?
• ¿Qué sucede si el firewall no puede descifrar una conexión?
• ¿Qué CA se utiliza para la nueva firma?

Para un primer despliegue, es recomendable un perfil más compatible, como Maximum compatibility o un perfil conservador propio. Para reglas de seguridad productivas, se puede utilizar más tarde un perfil más estricto como Block insecure SSL.

Importante: El perfil de descifrado se selecciona directamente en la regla de inspección SSL/TLS. El perfil puede anular la configuración global de inspección SSL/TLS para esta regla. Por lo tanto, al solucionar problemas, siempre se debe verificar la regla concreta y no solo la configuración global.

Con TLS 1.3, la acción de la SSL/TLS Inspection Rule es especialmente importante. Algunas comprobaciones como detección de TLS downgrade, bloqueo de errores de certificado o requisitos mínimos para claves RSA solo tienen sentido si la regla realmente trabaja con Action > Decrypt. Una excepción Don't decrypt no es una forma más suave de inspección, sino que excluye deliberadamente el tráfico del descifrado.

Crear regla de inspección SSL/TLS

La ruta del menú es Rules and policies > SSL/TLS inspection rules.

Las SSL/TLS Inspection Rules normalmente están activas en instalaciones nuevas, pero pueden desactivarse manualmente. Si están apagadas, no se muestran detalles de SSL/TLS inspection en Control Center ni en Log Viewer. Esto es importante en troubleshooting: un Log Viewer vacío también puede significar que el engine o el procesamiento de reglas no está activo.

Una primera regla debe ser lo más específica posible:

• Acción: Decrypt
• Perfil de descifrado: perfil de prueba conservador
• Zonas de origen: LAN o red de prueba
• Redes y dispositivos de origen: grupo de prueba o subred de prueba
• Zonas de destino: generalmente WAN
• Redes de destino: inicialmente Any
• Servicios: para comenzar, a menudo Any, ya que SSL/TLS también puede reconocerse en otros puertos TCP
• Sitios web / Categorías: opcionalmente restringir
• Log connections: activar para que el piloto y el análisis de errores sean trazables

La regla solo se aplica si todos los criterios configurados coinciden. Source, destination, usuarios o grupos, service y websites o categories no son por tanto un OR libre. Cuantos más criterios se definan, más preciso será el alcance, pero también será más fácil que un piloto parezca “no funcionar” porque un único criterio no coincide con el tráfico real.

Las SSL/TLS Inspection Rules pueden reconocer conexiones TLS también fuera del puerto HTTPS clásico, pero no pueden imponerlo sobre UDP. Las reglas se procesan de arriba abajo. Las excepciones específicas y reglas piloto deben estar por encima de reglas generales Decrypt; si no, después será difícil entender por qué una conexión fue descifrada o exceptuada.

Para reglas nuevas, la lógica básica es:

1. Abrir Rules and policies > SSL/TLS inspection rules.
2. Seleccionar Add.
3. Definir un Rule name claro, por ejemplo TLS decrypt pilot clients.
4. Elegir Rule position para que las excepciones queden por encima de reglas generales Decrypt.
5. Elegir Action: Decrypt, Don’t decrypt o Deny.
6. Activar Log connections.
7. Definir Source, Destination, Services y Websites o Categories según el piloto.
8. Seleccionar Decryption Profile.
9. Guardar y probar directamente con un cliente de prueba.

Listas de exclusión

No todo el tráfico TLS debe descifrarse. Sophos trabaja con reglas de exclusión y listas de exclusión TLS.

Lista de exclusión TLS local

La lista de exclusión TLS local es la lista de excepciones local del firewall. Esta lista está vacía por defecto y puede llenarse mediante la solución de problemas en el Centro de Control o el Log Viewer.

También se puede editar manualmente:

Web > URL groups > Local TLS exclusion list

Esta lista es útil para dominios que causan problemas en el propio entorno, por ejemplo, debido a la fijación de certificados o aplicaciones cliente especiales.

Lista de exclusión TLS gestionada

La lista de exclusión TLS gestionada contiene excepciones mantenidas por Sophos para servicios problemáticos conocidos. Esta lista se actualiza mediante actualizaciones de firmware.

Ejemplos típicos son servicios donde la inspección TLS causa problemas o no es técnicamente viable.

Reglas de exclusión propias

Además, se pueden crear reglas de inspección SSL/TLS propias con Action > Don’t decrypt. Estas deben estar directamente debajo de la regla de exclusión estándar y solo contener tráfico que realmente no debe descifrarse.

Criterios posibles:

• Categorías web
• Grupos de URL
• Usuarios y grupos
• Redes de origen y destino
• Direcciones IP
• Servicios

Las excepciones deben documentarse: dominio, motivo, usuarios afectados, fecha y fecha de revisión.

Las SSL/TLS Exclusions y las Web Exceptions no son la misma herramienta. Una SSL/TLS Exclusion decide si una conexión TLS se descifra y puede aplicarse en DPI Mode a conexiones SSL/TLS en cualquier puerto TCP. Una Web Exception está más vinculada al contexto de Web Policy, por ejemplo HTTPS decryption, certificate validation, malware o content scanning, Zero-Day Protection o Web Policy checks. En la práctica conviene aclarar primero si realmente debe excluirse el descifrado o si basta con una excepción de Web Policy.

Para conexiones antiguas no descifrables pero de confianza, puede ser útil un Decryption Profile propio que trate ciertos casos como versiones SSL antiguas, SSL compression o unrecognized cipher suites como Allow without decryption. No es una best practice general para navegación normal, sino una decisión de compatibilidad dirigida para destinos claramente nombrados. En reglas de internet productivas, estas excepciones deben limitarse de forma estricta y revisarse regularmente.

Control y evaluación

Después de la activación, conviene observar dashboard, Log Viewer y clientes de prueba en conjunto. Solo así se ve si el tráfico se descifra realmente o si excepciones, errores o QUIC cambian el camino esperado.

Observar el widget del panel

En el Centro de Control hay un widget para inspección SSL/TLS. Este widget es muy útil para supervisar el despliegue y los errores.

Muestra, entre otros:

• Porcentaje de sesiones SSL/TLS descifradas.
• Porcentaje de sesiones SSL/TLS no descifradas.
• Otro tráfico.
• Errores de los últimos días.
• Principales sitios web o usuarios con problemas.
• Pico de descifrado y límite de descifrado.

Si aparecen muchos errores en el widget, no se debe desactivar inmediatamente toda la inspección TLS. Es mejor, a través de Fix errors, verificar específicamente los objetivos afectados y, si es necesario, crear excepciones limpias.

Evaluar el Log Viewer

En el Log Viewer se puede seleccionar el filtro inspección SSL/TLS. Allí se puede ver qué sucedió con conexiones individuales.

Los colores ayudan en la primera evaluación:

• Rojo: Error. La conexión no pudo descifrarse o procesarse correctamente. Aquí se deben verificar errores de certificado, suites de cifrado, versiones TLS o aplicaciones incompatibles.
• Verde: No descifrar. La conexión no se descifró intencionadamente, por ejemplo, debido a una regla de exclusión o una lista de exclusión TLS.
• Azul: Descifrar. La conexión fue descifrada y luego reenviada cifrada nuevamente.

En el registro también se ven el perfil de descifrado, IP de origen, IP de destino, usuario, categoría y dominio de destino. Esto permite verificar si la regla correcta coincide y si una excepción realmente se aplica.

Pruebas

Después de activar la inspección TLS, se debe verificar:

• ¿Se utiliza el certificado CA de Sophos en el navegador?
• ¿Funcionan las aplicaciones empresariales importantes?
• ¿Hay errores TLS en el Log Viewer?
• ¿Se reconocen correctamente los eventos de malware o de política web?
• ¿Se muestra el tráfico como descifrado en el widget del Centro de Control?
• ¿Se mantiene el rendimiento del firewall dentro del rango esperado?
• ¿Hay quejas de los usuarios de prueba?

Para la resolución de problemas, son especialmente útiles el Log Viewer, Policy Test, la vista de certificados del navegador, Packet Capture y el widget de inspección SSL/TLS.

Troubleshooting y operación

Los problemas de TLS Inspection suelen resolverse con excepciones claras, rollback controlado y revisiones periódicas.

Errores típicos

• El navegador muestra advertencia de certificado: Falta CA en el almacén de confianza o se utiliza CA incorrecta. Distribución de CA, cadena de certificados en el navegador, reinicio del cliente
• Log Viewer no muestra eventos de inspección SSL/TLS: modo incorrecto, regla no coincidente o motor SSL/TLS no activo. Regla del firewall, DPI/Web Proxy, regla de inspección SSL/TLS
• El tráfico se permite, pero no se descifra: Regla Don't decrypt, exclusión gestionada o orden de reglas incorrecta. Verificar reglas de inspección SSL/TLS de arriba a abajo
• El filtro web no funciona como se esperaba: Falta política web, QUIC activo o Scan HTTP and decrypted HTTPS mal entendido. Regla del firewall coincidente, QUIC, registro de política web
• Clientes Android pierden internet o acceso a Play Store: a menudo interviene Certificate Pinning. Revisar red de dispositivos móviles, destinos de Google y regla Don't decrypt específica.
• Aplicaciones individuales fallan: Fijación de certificados, versión TLS antigua, suite de cifrado incompatible o verificación de certificados propia. Log Viewer, perfil de descifrado, excepción específica
• Muchos errores en el widget del panel: despliegue demasiado amplio o perfil de descifrado inadecuado. Reducir grupo piloto, clasificar errores por dominio y categoría
• El rendimiento cae después de la activación: alcance demasiado amplio, descargas grandes o demasiadas sesiones simultáneas. Verificar alcance de descifrado, carga del firewall y principales usuarios
• La excepción no funciona: La excepción está debajo de una regla de descifrado más general. Verificar orden de reglas y criterios coincidentes

En casos poco claros, no se deben cambiar varias cosas a la vez. Es mejor un caso de prueba estrecho: un cliente, un dominio de destino, una regla del firewall, un perfil de descifrado y un momento claro en el Log Viewer.

Retroceso

Si ocurren interrupciones, debe ser posible un retroceso claro:

• Desactivar la regla de inspección SSL/TLS.
• Eliminar el grupo de prueba de la regla.
• Suavizar el perfil de descifrado.
• Agregar excepción para el dominio o aplicación afectada.
• Volver a configurar la regla del firewall para usar Web Proxy si se desea conscientemente.

Las reglas de inspección SSL/TLS y el motor SSL/TLS deben estar visiblemente activos para que el Centro de Control y el Log Viewer muestren los detalles. Si se desactiva la inspección SSL/TLS con fines de solución de problemas, se debe volver a activar después y documentar brevemente el estado.

Recomendaciones operativas

La inspección TLS no es un proyecto de un solo clic. Sin embargo, correctamente implementada, proporciona una visibilidad significativamente mayor y mejora la efectividad de la protección web, el escaneo de malware, IPS, NDR y las funciones de día cero.

Para entornos productivos, recomendamos:

• Comenzar con LAN-to-WAN para un pequeño grupo de prueba.
• Distribuir correctamente el certificado CA.
• Elegir conscientemente el modo DPI/Web Proxy.
• No comenzar con un perfil de descifrado demasiado agresivo.
• Observar diariamente el Log Viewer y el panel.
• Documentar y revisar regularmente las excepciones.
• Ampliar solo después de pruebas exitosas.

Preguntas frecuentes