# Análisis del tráfico cifrado sin descifrarlo

> Cómo un NDR detecta amenazas en el tráfico cifrado con TLS sin descifrarlo: qué sigue siendo visible, qué se pierde y qué lee NetSenX de cada conexión.

Source page: https://netsenx.com/es/encrypted-traffic-analysis

Última revisión: 6 de noviembre de 2026

El análisis del tráfico cifrado detecta amenazas en el tráfico de red cifrado con TLS sin descifrarlo, a partir de lo que sigue siendo visible: quién se comunica con quién, cuándo, con qué frecuencia, cuántos datos se mueven y qué parámetros tiene el handshake TLS. Permite encontrar el beaconing C2 y las transferencias inusuales; no permite ver el contenido de una sesión.

## El dato que conviene tener presente

TLS 1.3 (RFC 8446, IETF, agosto de 2018) cifra todos los mensajes del handshake posteriores al ServerHello, incluido el certificado del servidor, y elimina el intercambio de claves RSA estático. Un sensor pasivo con una copia de la clave privada del servidor ya no puede descifrar la sesión; para ello hace falta un proxy de interceptación o claves de sesión exportadas desde los equipos.

Fuente: [RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)](https://www.rfc-editor.org/rfc/rfc8446)

## Qué hace NetSenX hoy

- Nunca descifra el tráfico: no hay que operar un proxy de interceptación ni instalar un certificado de interceptación en sus dispositivos.
- Detecta el beaconing C2 y las transferencias salientes inusuales en el tráfico cifrado a partir del ritmo, el volumen y los destinos, y desde el plan Starter también del handshake TLS. El handshake solo es visible donde el agente captura paquetes: en Linux o como sensor en un puerto SPAN o TAP, no en el modo básico que se usa en macOS.
- En el host supervisado, el agente lee el nombre del servidor y los parámetros del handshake TLS, así como las respuestas a las consultas DNS, para identificar cada conexión con el servicio al que llega. No lee el contenido cifrado de una sesión.
- Explica cada alerta en lenguaje claro, indicando las características de red que determinaron su puntuación, en todos los planes.

## Qué no hace NetSenX

Sin descifrado, NetSenX no ve lo que hay dentro de una sesión: un archivo malicioso descargado por HTTPS, el texto de un correo o el contenido de una subida. La protección de endpoints (EDR) y la seguridad del correo cubren ese terreno. Si la inspección del contenido es un requisito, elija una herramienta que descifre el tráfico y planifique cómo tratará el contenido descifrado.

## Preguntas de los compradores

### ¿Puede un NDR detectar amenazas en el tráfico cifrado sin descifrarlo?

Sí, a partir de metadatos. El ritmo, el volumen, los destinos y el handshake TLS siguen siendo visibles cuando el contenido está cifrado, de modo que el beaconing hacia un servidor C2 y las transferencias inusuales pueden detectarse sin romper el cifrado. Lo que sigue siendo invisible es el contenido de la sesión.

### ¿Qué lee NetSenX de una conexión cifrada?

Los metadatos del flujo (quién se conecta con quién, cuándo, con qué frecuencia y cuántos datos se mueven) y algunos campos de protocolo: el nombre del servidor y los parámetros del handshake TLS, y las respuestas a las consultas DNS. Nunca descifra la sesión y no lee su contenido cifrado.

### ¿Por qué no descifrar el tráfico TLS para inspeccionarlo?

El descifrado da visibilidad del contenido, pero obliga a mantener un punto de interceptación que guarda claves, a instalar un certificado de interceptación en cada dispositivo y a tratar contenido descifrado que puede incluir datos personales. Desde TLS 1.3, un sensor pasivo ya no puede descifrar sesiones con una copia de la clave privada del servidor.

### ¿Son datos personales los metadatos de red según el RGPD?

Pueden serlo. El Tribunal de Justicia de la UE declaró en el asunto Breyer (C-582/14, 19 de octubre de 2016) que una dirección IP dinámica puede constituir un dato personal. NetSenX publica un contrato de encargo del tratamiento (artículo 28 del RGPD) y conserva los datos de los clientes en la UE.

## Fuentes

- [RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018 (section 1.2)](https://www.rfc-editor.org/rfc/rfc8446)
- [Court of Justice of the EU, Case C-582/14 (Breyer), judgment of 19 October 2016 — EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62014CJ0582)

Esta página es información general y no constituye asesoramiento jurídico. Compruebe sus obligaciones con su autoridad nacional o con su asesor jurídico.

## Páginas relacionadas

- [Guía de criptografía poscuántica](https://netsenx.com/es/blog/2026-11-12_post-quantum-readiness-guide)
- [NetSenX como alternativa a ExtraHop](https://netsenx.com/es/compare/extrahop-alternative)
- [Funciones](https://netsenx.com/es/features)
- [Residencia de datos en la UE](https://netsenx.com/es/eu-data-residency)
- [Monitorización de red NIS2](https://netsenx.com/es/nis2-network-monitoring)
- [Cómo detectar el movimiento lateral y el beaconing C2](https://netsenx.com/es/detect-lateral-movement-c2-beaconing)