SonicWall DPI-SSL: cómo inspeccionar HTTPS sin romper aplicaciones ni degradar la red
La mayor parte de las aplicaciones empresariales actuales utiliza conexiones cifradas.
Microsoft 365, Google Workspace, banca electrónica, CRM, ERP cloud, almacenamiento en línea, portales empresariales y prácticamente toda la navegación moderna funcionan mediante HTTPS y TLS.
Eso es bueno para proteger la privacidad y confidencialidad de la información.
Pero también genera un problema para el firewall:
si el contenido está cifrado, ¿cómo puede inspeccionarlo realmente?
SonicWall dispone de una tecnología llamada DPI-SSL o Deep Packet Inspection of Secure Socket Layer, diseñada para permitir la inspección de conexiones SSL/TLS cifradas.
Pero activarla correctamente implica mucho más que habilitar una casilla.
Debemos considerar:
- Certificados
- Endpoints
- Aplicaciones
- Rendimiento
- Exclusiones
- Privacidad
- Compatibilidad
- Servicios de seguridad
En esta guía de la Biblioteca Virtual Sistro 2.0 explicamos cómo funciona SonicWall DPI-SSL, cuándo conviene utilizarlo y qué debemos revisar antes de desplegarlo en producción.
Consulta Firewalls SonicWall disponibles en Sistro
¿Qué es SonicWall DPI-SSL?
DPI-SSL permite que un firewall SonicWall compatible pueda inspeccionar determinadas conexiones SSL/TLS cifradas.
En términos sencillos, el firewall actúa como un punto intermedio entre el cliente y el destino.
El flujo puede visualizarse de esta forma:
Usuario → SonicWall → inspección TLS → Internet
El tráfico se descifra temporalmente para que los motores de seguridad puedan analizarlo.
Después se establece nuevamente una conexión cifrada hacia el destino.
¿Por qué es necesario inspeccionar HTTPS?
Porque HTTPS protege tanto tráfico legítimo como tráfico malicioso.
Un atacante también puede utilizar TLS para:
- Descargar malware
- Transportar documentos maliciosos
- Comunicar un equipo infectado con servidores externos
- Descargar payloads adicionales
- Ocultar determinadas actividades
- Evitar controles que no puedan ver dentro de la sesión
Si el firewall solamente observa que existe una conexión HTTPS pero no puede acceder al contenido, determinados motores de seguridad pueden tener visibilidad limitada.
¿Qué servicios pueden aprovechar DPI-SSL?
Cuando SonicWall descifra el tráfico, diferentes servicios de seguridad pueden analizarlo.
Dependiendo de SonicOS, configuración y licenciamiento, pueden participar funciones como:
- Intrusion Prevention
- Gateway Anti-Virus
- Gateway Anti-Spyware
- Application Control
- Content Filtering
- Otros servicios compatibles
Esto permite que las mismas políticas de seguridad que trabajan sobre tráfico visible puedan aplicarse también a determinados flujos HTTPS.
DPI-SSL Client vs DPI-SSL Server
SonicWall distingue dos escenarios principales.
DPI-SSL Client
Se utiliza normalmente cuando usuarios de la LAN navegan hacia servicios ubicados en Internet.
Por ejemplo:
PC corporativa → SonicWall → Microsoft 365
PC corporativa → SonicWall → sitio HTTPS
PC corporativa → SonicWall → aplicación SaaS
Este es probablemente el escenario más habitual en una empresa.
DPI-SSL Server
Se utiliza cuando queremos inspeccionar tráfico SSL/TLS que llega desde Internet hacia un servidor protegido dentro de nuestra infraestructura.
Por ejemplo:
Internet → SonicWall → servidor web corporativo
En este escenario el firewall puede asociar objetos de dirección con certificados específicos para inspeccionar tráfico entrante.
El certificado es la pieza crítica
Cuando SonicWall realiza DPI-SSL Client, necesita presentar al dispositivo cliente un certificado generado para la conexión inspeccionada.
Ese certificado debe estar firmado por una autoridad certificadora que el endpoint considere confiable.
Si el dispositivo no confía en esa CA pueden aparecer:
- Advertencias de seguridad
- Errores de certificado
- Sitios que no cargan
- Aplicaciones que rechazan la conexión
Por eso una implementación correcta necesita una estrategia de distribución de certificados.
¿Cómo distribuir el certificado DPI-SSL?
En empresas con dispositivos administrados podemos distribuir la CA mediante herramientas como:
- Active Directory Group Policy
- Microsoft Intune
- MDM
- Herramientas RMM
- Administración centralizada de endpoints
El objetivo es que los navegadores y aplicaciones confíen correctamente en la autoridad que utiliza SonicWall.
Ejemplo con Active Directory
Supongamos una empresa con 100 computadoras Windows unidas al dominio.
En lugar de instalar manualmente el certificado en cada equipo podemos distribuirlo mediante Group Policy.
Una vez que los endpoints confían en la CA, DPI-SSL puede desplegarse de manera mucho más controlada.
¿Qué pasa con BYOD?
BYOD cambia completamente el problema.
Podemos tener:
- iPhone personales
- Android
- Tablets
- Laptops externas
- Equipos de proveedores
- Visitantes
La empresa no necesariamente tiene control administrativo sobre estos dispositivos.
En ese escenario puede ser más conveniente utilizar una política diferente.
Por ejemplo:
LAN corporativa → DPI-SSL
WiFi invitados → sin interceptación profunda o con controles alternativos
Esto evita obligar a todos los visitantes a instalar certificados corporativos.
DPI-SSL debe aplicarse por zonas
SonicOS permite habilitar DPI-SSL Client en las zonas donde realmente sea necesario.
Eso significa que podemos diseñar políticas distintas para:
- LAN corporativa
- WiFi corporativo
- Invitados
- Servidores
- IoT
- Sucursales
No es necesario tratar todos los segmentos exactamente igual.
Una política por tipo de dispositivo suele ser mejor
Por ejemplo:
Computadoras corporativas
DPI-SSL completo con CA administrada.
Invitados
Política más sencilla sin instalar certificados corporativos.
IoT
Evaluar compatibilidad antes de interceptar TLS.
Servidores
Políticas específicas según aplicaciones y tráfico.
Este enfoque reduce problemas operativos.
¿Por qué algunas aplicaciones dejan de funcionar?
Algunas aplicaciones realizan validaciones adicionales sobre sus conexiones TLS.
Pueden verificar:
- Certificado
- Autoridad certificadora
- Nombre del servidor
- Cadena de confianza
- Clave pública
Cuando SonicWall intercepta la sesión, la aplicación puede interpretar que el certificado no corresponde al esperado.
El resultado puede ser una conexión rechazada.
Certificate Pinning
Una causa frecuente de incompatibilidad es Certificate Pinning.
Una aplicación con certificate pinning puede esperar un certificado, autoridad o clave determinados.
Si SonicWall presenta un certificado resignado durante DPI-SSL, la aplicación puede detectar la diferencia.
Esto puede ocurrir en:
- Aplicaciones móviles
- Servicios financieros
- Aplicaciones propietarias
- Software empresarial
- Determinados servicios cloud
Las exclusiones son normales
Una implementación profesional de DPI-SSL no consiste necesariamente en descifrar absolutamente todo.
SonicWall permite definir exclusiones e inclusiones.
Podemos utilizar criterios relacionados con:
- Objetos de dirección
- Grupos
- Usuarios
- Servicios
- Common Name
- Categorías de contenido
Esto permite crear excepciones específicas cuando existe una razón técnica o de negocio.
No excluyas categorías completas sin entender el problema
Supongamos que una aplicación financiera deja de funcionar.
Una solución rápida sería excluir toda la categoría financiera.
Pero eso puede ser demasiado amplio.
Antes conviene identificar:
- Dominio exacto
- Aplicación
- Certificado
- Dirección de destino
- Error generado
- Motivo de incompatibilidad
Después podemos construir una exclusión mucho más específica.
Trust but verify
SonicOS también permite autenticar el servidor antes de aplicar determinadas exclusiones.
Esto ayuda a evitar que una exclusión se convierta automáticamente en una zona completamente confiable.
Es especialmente relevante cuando se crean exclusiones para sitios sensibles.
DPI-SSL y Content Filtering
DPI-SSL puede trabajar junto con Content Filtering.
Cuando la sesión HTTPS es descifrada, el motor de filtrado puede obtener mayor visibilidad del tráfico.
Esto puede permitir controles más específicos que los disponibles únicamente observando información externa de la conexión.
DPI-SSL y Application Control
También puede integrarse con Application Control.
Esto ayuda cuando una aplicación utiliza HTTPS como transporte y necesitamos aplicar políticas de mayor profundidad.
DPI-SSL y Gateway Anti-Virus
Un archivo puede viajar dentro de una sesión HTTPS.
Sin capacidad de descifrar la conexión, el firewall puede no tener acceso suficiente al contenido para realizar determinados análisis.
DPI-SSL permite entregar ese contenido descifrado temporalmente a motores como Gateway Anti-Virus cuando la arquitectura y licencia lo permiten.
DPI-SSL y Capture ATP
Este punto conecta directamente con nuestro artículo anterior.
Capture ATP puede analizar archivos sospechosos mediante sandboxing y RTDMI.
Pero si esos archivos viajan cifrados mediante HTTPS, necesitamos considerar cómo obtendrá el firewall acceso al contenido.
DPI-SSL puede formar parte de esa estrategia.
Consulta nuestra guía SonicWall Capture ATP y RTDMI
Arquitectura por capas
Podemos visualizar un flujo de seguridad como:
Internet
↓
SonicWall DPI-SSL
↓
IPS
↓
Gateway Anti-Virus
↓
Application Control
↓
Capture ATP
↓
Endpoint
El objetivo es utilizar varias capas y no depender de un solo mecanismo.
DPI-SSL también tiene un costo de rendimiento
Descifrar tráfico no es gratuito desde el punto de vista computacional.
El firewall debe:
- Recibir la sesión TLS
- Descifrarla
- Analizarla
- Aplicar perfiles de seguridad
- Volver a cifrarla
- Enviar el tráfico
Todo esto requiere recursos.
Por eso el dimensionamiento de un SonicWall no debe realizarse utilizando solamente la cifra de Firewall Throughput.
Internet de 1 Gbps no significa automáticamente firewall de 1 Gbps
Supongamos que una empresa tiene:
- 1 Gbps de internet
- DPI-SSL
- IPS
- Gateway Anti-Virus
- Application Control
- Capture ATP
El firewall está realizando mucho más trabajo que simplemente reenviar paquetes.
Por eso debemos revisar el rendimiento publicado bajo cargas de seguridad más representativas.
El porcentaje de tráfico HTTPS importa
Una empresa donde casi todo el tráfico es HTTPS puede generar una carga DPI-SSL considerablemente mayor que otra donde solamente una parte del tráfico requiere inspección.
Debemos entender:
- Volumen total
- Porcentaje HTTPS
- Usuarios
- Sesiones
- Aplicaciones
- Archivos
- Servicios de seguridad activos
¿Qué SonicWall necesito?
No existe un único modelo para DPI-SSL.
La selección debe considerar:
- Velocidad de internet
- Número de usuarios
- Número de dispositivos
- Sesiones
- DPI-SSL
- VPN
- IPS
- Gateway Anti-Virus
- Capture ATP
- Crecimiento
Consulta nuestra guía SonicWall TZ vs NSa
DPI-SSL en SonicWall TZ
Los modelos TZ pueden ser adecuados para pequeñas empresas, PyMES y sucursales dependiendo de la carga.
Sin embargo, si utilizaremos inspección TLS intensiva debemos revisar con cuidado la capacidad del modelo seleccionado.
Consulta SonicWall TZ para PyMES: Gen 7 vs Gen 8
DPI-SSL en SonicWall NSa
Cuando aumenta considerablemente:
- Tráfico
- Número de usuarios
- Sesiones
- DPI-SSL
- VPN
- Servicios críticos
puede ser necesario evaluar plataformas NSa.
La transición entre TZ y NSa debe surgir del workload y no solamente del tamaño de la empresa.
DPI-SSL Client para navegación de usuarios
Este es el escenario más habitual.
Tenemos:
Usuarios internos → SonicWall → Internet
El firewall inspecciona las conexiones que cumplen con las políticas definidas.
DPI-SSL Server para servidores publicados
Existe también el escenario inverso.
Tenemos:
Internet → SonicWall → servidor interno
En este caso DPI-SSL Server puede utilizarse para inspeccionar conexiones dirigidas hacia determinados servidores protegidos.
La configuración necesita considerar certificados y objetos específicos.
¿DPI-SSL reemplaza un WAF?
No necesariamente.
DPI-SSL permite inspeccionar tráfico cifrado.
Un Web Application Firewall está diseñado específicamente para proteger aplicaciones web frente a diferentes ataques de capa de aplicación.
Son tecnologías diferentes que pueden complementarse.
¿DPI-SSL reemplaza EDR?
No.
EDR observa lo que sucede directamente dentro del endpoint.
DPI-SSL proporciona visibilidad de tráfico cifrado en el firewall.
La seguridad moderna funciona mejor por capas.
¿DPI-SSL afecta privacidad?
Sí, es una consideración importante.
Deep inspection implica que la organización puede inspeccionar contenido que originalmente viajaba cifrado.
Por eso debe existir una política clara respecto a:
- Privacidad
- Usuarios
- Información personal
- Categorías excluidas
- Regulación
- Políticas internas
La capacidad técnica de inspeccionar tráfico no significa que debamos inspeccionar absolutamente todo.
¿Conviene excluir banca y salud?
Muchas organizaciones deciden excluir determinadas categorías sensibles.
Pero esta decisión debe tomarse según:
- Política corporativa
- Regulación
- Riesgo
- Privacidad
- Requerimientos técnicos
No existe una política universal para todas las empresas.
Implementación recomendada: no empieces con toda la compañía
Una implementación gradual reduce riesgos.
Fase 1 — Inventario
Identificar endpoints, aplicaciones y zonas.
Fase 2 — Certificados
Definir la CA y el mecanismo de distribución.
Fase 3 — Grupo piloto
Elegir algunos usuarios representativos.
Fase 4 — Habilitar DPI-SSL
Aplicar inspección únicamente al grupo piloto.
Fase 5 — Revisar errores
Identificar aplicaciones incompatibles.
Fase 6 — Crear excepciones
Documentarlas y hacerlas lo más específicas posible.
Fase 7 — Revisar rendimiento
Medir CPU, sesiones, throughput y experiencia del usuario.
Fase 8 — Ampliación
Agregar usuarios o departamentos gradualmente.
Escenario 1: pequeña empresa con Active Directory
Supongamos:
- 40 empleados
- Computadoras Windows
- Active Directory
- Microsoft 365
- SonicWall TZ
Aquí podemos distribuir la CA mediante Group Policy y comenzar con un pequeño grupo piloto.
Escenario 2: empresa con BYOD
Tenemos:
- Equipos corporativos
- Celulares personales
- Visitantes
- WiFi de invitados
No intentaría aplicar exactamente la misma política a todos.
Podemos separar:
Corporate → DPI-SSL
Guest → política independiente
Escenario 3: aplicación bancaria que falla
La empresa activa DPI-SSL.
Una aplicación financiera deja de conectarse.
No debemos desactivar toda la inspección.
Primero identificamos la aplicación y causa.
Después creamos la exclusión mínima necesaria.
Escenario 4: empresa activa Capture ATP
La organización quiere analizar archivos sospechosos descargados mediante HTTPS.
Aquí DPI-SSL y Capture ATP pueden formar parte de una estrategia conjunta.
Uno proporciona acceso al contenido cifrado.
El otro proporciona análisis avanzado de archivos sospechosos.
Escenario 5: servidor publicado
Una empresa tiene un servidor HTTPS accesible desde Internet.
DPI-SSL Server puede entrar en la conversación para inspeccionar conexiones entrantes hacia ese servidor.
Pero debemos revisar certificados, NAT, arquitectura y aplicaciones antes de implementarlo.
Errores comunes con SonicWall DPI-SSL
1. Activarlo sin distribuir la CA
Generará problemas de confianza.
2. Activarlo para todos el primer día
Un piloto es mucho más seguro.
3. No revisar rendimiento
Descifrar TLS consume recursos.
4. Ignorar aplicaciones con certificate pinning
Pueden dejar de funcionar.
5. Crear exclusiones demasiado amplias
Reduce innecesariamente la visibilidad.
6. Inspeccionar invitados igual que endpoints corporativos
Los dispositivos no administrados requieren otra estrategia.
7. No documentar excepciones
Con el tiempo nadie sabrá por qué una aplicación fue excluida.
8. No revisar privacidad
La inspección profunda debe alinearse con las políticas de la organización.
9. Dimensionar solamente por velocidad WAN
DPI-SSL y servicios de seguridad cambian la carga.
10. Confundir inspección TLS con protección total
Seguimos necesitando endpoints, backup, segmentación y otras capas.
Checklist antes de implementar DPI-SSL
Antes de activarlo deberíamos conocer:
- Modelo SonicWall
- Versión SonicOS
- Licencias
- Velocidad WAN
- Número de usuarios
- Número de dispositivos
- Porcentaje de tráfico HTTPS
- Sistemas operativos
- Navegadores
- Aplicaciones críticas
- Active Directory
- MDM
- BYOD
- Red de invitados
- Aplicaciones móviles
- IPS
- Gateway Anti-Virus
- Application Control
- Content Filtering
- Capture ATP
- Política de privacidad
- Exclusiones requeridas
Preguntas que Sistro debería hacer antes de habilitar DPI-SSL
- ¿Qué SonicWall utilizas?
- ¿Qué versión de SonicOS tienes?
- ¿Cuántos usuarios inspeccionaremos?
- ¿Los endpoints son administrados?
- ¿Existe Active Directory o MDM?
- ¿Hay BYOD?
- ¿Qué aplicaciones son críticas?
- ¿Usas Capture ATP?
- ¿Necesitas Content Filtering HTTPS?
- ¿Tienes aplicaciones financieras o propietarias?
- ¿Qué política de privacidad aplica?
- ¿Qué capacidad tiene actualmente el firewall?
Después podemos diseñar la implementación.
SonicWall DPI-SSL y Biblioteca Virtual Sistro 2.0
Este tema se relaciona directamente con otras capas de seguridad que ya hemos analizado.
SonicWall TZ Gen 7 vs Gen 8 para PyMES
SonicWall para oficinas remotas
Productos SonicWall en Sistro
Firewalls SonicWall
https://sistro.net/firewalls-sonicwall
Recomendación final
SonicWall DPI-SSL puede mejorar considerablemente la visibilidad sobre tráfico HTTPS.
Pero no es una función que debamos habilitar indiscriminadamente.
Una implementación correcta debe combinar:
Certificados + endpoints + aplicaciones + exclusiones + privacidad + rendimiento + servicios de seguridad.
En equipos corporativos administrados, DPI-SSL puede ser una herramienta especialmente poderosa.
En BYOD, invitados y aplicaciones con certificate pinning probablemente necesitaremos políticas diferentes.
La pregunta correcta no es:
“¿Podemos descifrar todo el tráfico HTTPS?”
La pregunta correcta es:
“¿Qué tráfico necesitamos inspeccionar para mejorar seguridad sin afectar innecesariamente operación y privacidad?”
¿Quieres implementar DPI-SSL en tu SonicWall?
En Sistro Networks podemos ayudarte a revisar el modelo de firewall, licencias, capacidad, endpoints, certificados y aplicaciones antes de habilitar inspección HTTPS.
Podemos comenzar con un piloto, identificar incompatibilidades, configurar exclusiones y validar rendimiento antes de ampliar la política al resto de la organización.
Consulta soluciones SonicWall en Sistro Networks
Preguntas frecuentes
¿Qué es SonicWall DPI-SSL?
Es una tecnología que permite inspeccionar determinadas conexiones SSL/TLS cifradas para proporcionar mayor visibilidad a los servicios de seguridad del firewall.
¿Qué diferencia existe entre DPI-SSL Client y Server?
DPI-SSL Client inspecciona normalmente tráfico generado por usuarios internos hacia Internet. DPI-SSL Server se utiliza para determinados servicios HTTPS publicados hacia Internet.
¿Necesito instalar un certificado?
Para DPI-SSL Client los endpoints deben confiar en la autoridad certificadora utilizada por SonicWall para evitar errores de certificado.
¿DPI-SSL puede afectar rendimiento?
Sí. Descifrar, inspeccionar y volver a cifrar conexiones TLS requiere recursos del firewall.
¿DPI-SSL puede romper aplicaciones?
Sí. Algunas aplicaciones utilizan certificate pinning u otras validaciones que pueden rechazar una conexión interceptada.
¿Puedo crear excepciones?
Sí. SonicOS permite configurar exclusiones e inclusiones mediante diferentes criterios.
¿DPI-SSL sirve con Capture ATP?
Puede formar parte de la misma arquitectura para permitir que archivos transportados mediante conexiones HTTPS sean accesibles para diferentes servicios de seguridad según la configuración.
¿Debo inspeccionar el WiFi de invitados?
No necesariamente. Los dispositivos no administrados pueden requerir una estrategia diferente.
Deja un Comentario