# Cifrado y tráfico cifrado (FAQ)

> 40 preguntas sobre Cifrado y tráfico cifrado, en lenguaje claro: qué comprobar, qué muestra NetSenX y qué no ve un sensor.

Source page: https://netsenx.com/es/faq/encryption

## ¿Detecta NetSenX amenazas en tráfico cifrado?

Sí, a partir de metadatos: el tráfico cifrado nunca se descifra. NetSenX examina los metadatos de los flujos y algunos campos de protocolo —ritmo, volumen, destinos y el handshake TLS—, de forma que el beaconing y las transferencias inusuales siguen siendo visibles sin romper el cifrado ni leer el contenido.

https://netsenx.com/es/faq/can-netsenx-detect-threats-in-encrypted-traffic

## ¿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.

https://netsenx.com/es/faq/can-ndr-detect-threats-in-encrypted-traffic-without-decrypting-it

## ¿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.

https://netsenx.com/es/faq/what-does-netsenx-read-from-an-encrypted-connection

## ¿Necesito descifrar TLS para detectar amenazas?

Para muchas de ellas, no. Quién habla con quién, cuándo, con qué frecuencia y cuánto, junto con el handshake TLS sin cifrar y las respuestas DNS, sigue siendo visible sin descifrar. Eso basta para ver beaconing hacia un servidor de mando y control, escaneos, movimiento lateral entre equipos internos y subidas inusuales, que son pasos que dan la mayoría de las intrusiones antes de causar daños. Descifrar hace falta para ver el contenido, como un fichero malicioso dentro de una descarga o el texto de una orden, y tiene costes: un proxy de interceptación que guarda claves y datos descifrados, un certificado corporativo en cada equipo gestionado, aplicaciones que dejan de funcionar, cuestiones de privacidad y de representación de los trabajadores y puntos ciegos en los equipos no gestionados. Muchas empresas sacan más partido de la protección de endpoints para ficheros y procesos en cada equipo, junto con detección de red para el comportamiento de todos los dispositivos. NetSenX nunca descifra el tráfico: sus detecciones básicas funcionan en todos los planes, y las huellas TLS desde el plan Starter allí donde el agente captura paquetes.

https://netsenx.com/es/faq/do-i-need-tls-decryption-to-detect-threats

## ¿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.

https://netsenx.com/es/faq/why-not-decrypt-tls-traffic-for-inspection

## ¿Qué rompe la inspección TLS en un cortafuegos?

Más de lo que se suele pensar. Para inspeccionar HTTPS, el cortafuegos o el proxy termina cada conexión, la descifra, la inspecciona y abre una nueva conexión cifrada con el servidor real, presentando su propio certificado firmado por una raíz corporativa instalada en cada equipo gestionado. Efectos secundarios: las aplicaciones con fijación de certificados, muchos actualizadores, algunas apps bancarias y de salud y partes de servicios en la nube rechazan el certificado sustituto, así que las listas de excepciones no paran de crecer; los equipos no gestionados, los invitados y las máquinas no se pueden inspeccionar; el proxy se convierte en un único punto que guarda tráfico descifrado, incluidos datos personales, lo que plantea cuestiones de RGPD y de representación de los trabajadores; los proxies antiguos pueden no admitir funciones recientes de TLS ni los nuevos grupos poscuánticos híbridos y debilitar las conexiones sin avisar; y la inspección cuesta rendimiento. Sigue teniendo su lugar, por ejemplo para analizar descargas en portátiles gestionados. Pero muchas amenazas se ven sin ella. Es el enfoque de NetSenX: nunca descifra y trabaja con metadatos y el handshake sin cifrar.

https://netsenx.com/es/faq/what-does-tls-inspection-on-a-firewall-break

## ¿Funciona la inspección profunda de paquetes con tráfico cifrado?

Solo en las partes que no están cifradas, salvo que descifre. La inspección profunda de paquetes (DPI) consiste en leer más allá de las cabeceras, en el contenido. Con TLS el contenido va cifrado, así que las firmas clásicas que buscan un fichero o una orden maliciosa dentro del flujo dejan de coincidir. Siguen siendo legibles los mensajes del handshake sin cifrar, con la versión de TLS, la elección de cifrado e intercambio de claves, una huella del cliente y normalmente el nombre del servidor, y las respuestas DNS previas a la conexión. Junto con los metadatos de flujo, es decir, quién, cuándo, con qué frecuencia y cuánto, eso basta para muchas detecciones: beaconing hacia un servidor de mando y control, escaneos, movimiento lateral y subidas inusuales. Para ver el contenido necesita un proxy de interceptación que descifre y vuelva a cifrar el tráfico, con sus propios costes y riesgos. NetSenX lee los campos del handshake allí donde su agente captura paquetes, en Linux o como sensor SPAN/TAP, no en el modo básico de macOS, y nunca descifra el tráfico.

https://netsenx.com/es/faq/can-deep-packet-inspection-work-on-encrypted-traffic

## ¿Se puede detectar malware solo con estadísticas de flujo?

A menudo sí, porque el malware tiene que comportarse de cierta manera para ser útil, y ese comportamiento se ve en los flujos. Los registros de flujo describen cada conexión: origen y destino, puertos, hora de inicio, duración, y bytes y paquetes en cada sentido. Un equipo comprometido que contacta con su servidor de control a intervalos regulares produce un ritmo reconocible, el beaconing; uno que explora la red toca muchos equipos y puertos internos en poco tiempo, que es escaneo y movimiento lateral; uno que roba datos envía mucho más de lo normal, a menudo de noche. Nada de esto requiere descifrar, y la investigación sobre análisis de tráfico cifrado lleva años mostrando que los patrones de tiempo y tamaño contienen mucha información. Los límites: una sola conexión a un servicio en la nube conocido puede parecer inocente, y los atacantes pacientes intentan pasar desapercibidos. Por eso el análisis de flujos funciona mejor frente a una referencia de lo que es normal para cada equipo. NetSenX detecta beaconing, escaneos, movimiento lateral y volumen saliente inusual en todos los planes, incluido Free.

https://netsenx.com/es/faq/can-malware-be-detected-from-flow-statistics

## ¿Puede el tráfico cifrado revelar lo que contiene?

El contenido no, pero sí más cosas sobre él de lo que se suele pensar. El cifrado oculta palabras, ficheros y pulsaciones, pero el tamaño, el momento y el sentido de los paquetes dejan escapar patrones: una videollamada, una subida grande, una sesión de escritorio remoto y una actualización de software tienen cada una una forma reconocible. Los investigadores llevan años mostrando que este análisis de tráfico puede identificar, con precisión variable, las webs visitadas o las aplicaciones usadas, incluso a través de una VPN. Para la defensa es útil: así un sensor de red distingue una sesión interactiva de un aviso automático, o detecta un servidor que de repente envía gigabytes, sin descifrar nada. Para la privacidad es un recordatorio de que cifrado no significa invisibilidad. Lo que el análisis de tráfico no puede hacer es leer un mensaje, ver qué fichero se subió o saber qué escribió alguien en un chatbot de IA. NetSenX usa metadatos de flujo y el handshake sin cifrar, nunca descifra sesiones y no reconstruye contenido.

https://netsenx.com/es/faq/can-encrypted-traffic-reveal-what-is-inside

## ¿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.

https://netsenx.com/es/faq/is-network-metadata-personal-data-under-gdpr

## ¿Se puede coger malware de una web HTTPS?

Sí. HTTPS significa que la conexión va cifrada y que el servidor tiene un certificado válido para el nombre de la barra de direcciones; no dice nada sobre si el sitio o sus descargas son seguros. Los atacantes usan HTTPS con la misma normalidad que todo el mundo, porque los certificados son gratuitos y automáticos, y buena parte del phishing y de la distribución de malware va por HTTPS. El candado le protege de quien lea o altere el tráfico por el camino, no del contenido del otro extremo. La protección frente a descargas maliciosas viene de la protección del endpoint en el equipo, el filtrado en navegador y correo, el software actualizado y limitar quién puede instalar programas. En la red, el cifrado oculta el fichero, pero no el comportamiento que suele seguir a una infección: un equipo que de pronto contacta con un destino nuevo a intervalos regulares, escanea equipos internos o envía volúmenes de datos inusuales. NetSenX detecta esos patrones en todos los planes, a partir de metadatos de flujo y sin descifrar el tráfico.

https://netsenx.com/es/faq/can-you-get-malware-from-an-https-website

## ¿Se puede interceptar el tráfico HTTPS con un ataque de intermediario?

Solo si se consigue que el cliente confíe en el interceptor. Un ataque de intermediario (man in the middle) contra HTTPS necesita un certificado que el cliente acepte para el nombre de destino, un usuario que ignore el aviso o una aplicación que no compruebe bien los certificados. Las empresas lo hacen a propósito con proxies de inspección TLS, instalando su propio certificado raíz en los equipos gestionados. Los atacantes intentan lo mismo colando un certificado raíz falso mediante malware, convenciendo a los usuarios de aceptar avisos o aprovechando aplicaciones con comprobaciones de certificado defectuosas. Defensas: no acostumbre nunca al personal a saltarse los avisos de certificado, controle qué certificados raíz están instalados en los equipos de la empresa, mantenga las aplicaciones al día y use HTTP Strict Transport Security (HSTS) en sus webs para que los navegadores rechacen las conexiones sin cifrar. La fijación de certificados en algunas aplicaciones rechaza cualquier interceptor, incluido su propio proxy. En TLS 1.3 el certificado del servidor va cifrado, así que un sensor de red pasivo no puede comprobar quién lo emitió; esa comprobación corresponde al equipo o a los registros del proxy.

https://netsenx.com/es/faq/can-https-traffic-be-intercepted

## ¿Qué es la huella TLS JA4?

Cuando un programa abre una conexión TLS, su primer mensaje enumera las versiones, cifrados y extensiones que admite, en un orden característico. Una huella como JA4 condensa ese mensaje en una cadena corta, de modo que el mismo software cliente se puede reconocer en distintas conexiones sin descifrar nada. Ayuda a detectar clientes inusuales, como un script que se hace pasar por un navegador. NetSenX calcula huellas TLS a partir del handshake desde el plan Starter, con implementación propia. 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.

https://netsenx.com/es/faq/what-is-ja4-tls-fingerprinting

## ¿Qué diferencia hay entre JA3 y JA4?

Ambos crean una huella del lado cliente de un handshake TLS, pero JA4 se adapta al comportamiento de los navegadores modernos. JA3, publicado en 2017, calcula un hash de los campos del ClientHello en el orden en que aparecen. Desde principios de 2023 Chrome empezó a barajar el orden de las extensiones TLS en cada conexión, lo que cambia el valor JA3 cada vez y lo hace mucho menos útil para reconocer navegadores. JA4, publicado en 2023, ordena los campos antes del hash, añade la versión de TLS, el transporte (TCP o QUIC) y el primer protocolo de aplicación ofrecido, y produce una cadena legible cuyas partes se comparan por separado. Ninguno demuestra por sí solo una intención maliciosa: muchos programas comparten huella y el malware puede imitar a un navegador. Sirven para detectar un cliente que no encaja con el equipo, como un script que se hace pasar por navegador en un servidor. NetSenX calcula huellas TLS desde el plan Starter, con implementación propia, allí donde su agente captura paquetes: en Linux o como sensor SPAN/TAP, no en el modo básico de macOS.

https://netsenx.com/es/faq/what-is-the-difference-between-ja3-and-ja4

## ¿Qué es SNI y por qué importa para la supervisión?

Server Name Indication (SNI) es un campo del ClientHello de TLS en el que el cliente nombra el sitio al que quiere llegar, como login.example.com, porque muchos sitios comparten una dirección IP y el servidor debe saber qué certificado presentar. Se envía antes de que empiece el cifrado, así que cualquiera en el camino puede leerlo. Para la supervisión es uno de los campos más útiles del tráfico cifrado: nombra el servicio que hay detrás de una IP, lo que ayuda a distinguir un asistente de IA, un servicio para compartir ficheros o una aplicación de negocio conocida de un servidor desconocido, sin leer contenido. La mayoría de los filtros web y muchos cortafuegos también se basan en él. Dos cosas reducen su valor: las conexiones directas a una dirección IP no llevan un nombre útil, y Encrypted Client Hello (ECH) oculta el nombre real tras un nombre público de fachada. Entonces importan más las respuestas DNS y el historial de cada destino. NetSenX lee el nombre del servidor en el handshake allí donde su agente captura paquetes, en Linux o como sensor SPAN/TAP.

https://netsenx.com/es/faq/what-is-sni-and-why-does-it-matter-for-monitoring

## ¿Qué es Encrypted Client Hello (ECH)?

ECH es una extensión de TLS que cifra la parte sensible del ClientHello, incluido el nombre real del servidor, con una clave pública que el sitio publica en el DNS. En la red, un observador solo ve un ClientHello exterior con un nombre público compartido, normalmente el de la red de distribución de contenidos que aloja el sitio, en lugar del sitio real. Se diseñó para la privacidad: impedir que cualquiera en el camino, desde la wifi de una cafetería hasta un proveedor de internet, sepa qué sitio visita. Los principales navegadores lo admiten y algunas grandes redes de distribución de contenidos lo ofrecen, así que una parte del tráfico web ya lo usa, mientras que la mayoría de los servidores corporativos e internos no. ECH suele ir de la mano del DNS cifrado, porque si no el nombre se filtraría igualmente por la consulta DNS. El certificado y el contenido de la sesión ya iban cifrados en TLS 1.3; ECH cierra uno de los últimos campos legibles. Para los equipos de seguridad significa menos nombres y más dependencia del comportamiento.

https://netsenx.com/es/faq/what-is-encrypted-client-hello

## ¿Deja ciega Encrypted Client Hello a la supervisión de red?

En parte. Con ECH, un sensor ya no ve el nombre real del servidor en el handshake, así que las reglas basadas en nombres, los filtros web y las listas sencillas de shadow IT pierden precisión con los sitios que lo usan. Queda mucho: la dirección IP de destino y quién la opera, el nombre público exterior, normalmente de una gran red de distribución de contenidos, las respuestas DNS cuando el DNS no va cifrado de extremo a extremo, el momento, el volumen y el sentido de cada flujo, y la huella del cliente. Las detecciones de comportamiento, como beaconing, escaneos, movimiento lateral y subidas inusuales, no dependen del nombre del servidor y siguen funcionando. El tráfico interno rara vez se ve afectado, porque los servidores internos casi nunca publican claves ECH. En los equipos gestionados puede influir: haga que usen su propio resolutor DNS y aplique las políticas corporativas del navegador, que permiten controlar ECH y el DNS cifrado. La visibilidad por nombre de servicios de IA o de intercambio de ficheros se vuelve menos completa para los sitios tras ECH en cualquier sensor de red, NetSenX incluido.

https://netsenx.com/es/faq/does-encrypted-client-hello-blind-network-monitoring

## ¿Dejan QUIC y HTTP/3 ciegos a los cortafuegos?

Reducen lo que ven los cortafuegos antiguos, pero no hacen invisible el tráfico. QUIC (RFC 9000, 2021) es el transporte sobre el que funciona HTTP/3. Usa el puerto UDP 443 y cifra casi todo, incluido mucho de lo que TCP dejaba legible, como los números de paquete y los acuses de recibo. Sus primeros paquetes llevan un ClientHello de TLS 1.3 protegido solo con claves que cualquiera puede derivar, así que un sensor que entienda QUIC aún puede leer el nombre del servidor y los parámetros del handshake. Los cortafuegos y proxies pensados para TCP a menudo no pueden inspeccionar QUIC. Lo habitual en empresas que dependen de la inspección TLS o del filtrado web es bloquear el puerto UDP 443, con lo que los navegadores vuelven a HTTP/2 sobre TCP sin que los usuarios lo noten. Sin esa política, QUIC aparece simplemente como flujos UDP con momento y volumen como cualquier otro tráfico, y las detecciones basadas en flujos, como el beaconing y el volumen de subida inusual, siguen aplicándose. Compruebe si su cortafuegos informa de QUIC antes de dar por hecho que está cubierto.

https://netsenx.com/es/faq/do-quic-and-http3-blind-firewalls

## ¿Puede DNS over HTTPS ocultar tráfico a la supervisión de seguridad?

Puede ocultar las consultas DNS, no las conexiones que vienen después. DNS over HTTPS (DoH, RFC 8484) y DNS over TLS (DoT, RFC 7858) cifran las preguntas que un equipo hace a su resolutor. Si navegadores o aplicaciones usan un resolutor DoH externo, su servidor DNS corporativo y sus registros dejan de ver qué nombres se consultan, lo que debilita el filtrado basado en DNS y las investigaciones. El malware puede usar DoH por el mismo motivo. Las conexiones a los destinos reales siguen cruzando la red con sus direcciones IP, momento y volumen, y a menudo con el nombre del servidor en el handshake TLS. Pasos prácticos: tenga su propio resolutor, o use el de un proveedor, que admita DNS cifrado y haga que los equipos gestionados lo usen; impida con políticas del navegador y del sistema operativo que usen otros resolutores; y busque equipos que hablen directamente con servicios DoH públicos. DoT es fácil de ver porque usa el puerto 853; DoH parece HTTPS normal. NetSenX alerta de la tunelización DNS; no filtra ni bloquea el DNS.

https://netsenx.com/es/faq/can-dns-over-https-hide-traffic-from-security-monitoring

## ¿Cómo descifro tráfico TLS para resolver problemas?

En un equipo que controla, lo más sencillo es hacer que el cliente escriba sus claves de sesión en un fichero y cargarlo en Wireshark. Los navegadores y muchas herramientas de línea de comandos basadas en OpenSSL o NSS respetan la variable de entorno SSLKEYLOGFILE: defínala, reproduzca el problema mientras captura con Wireshark o tcpdump y después indique el registro de claves en los ajustes TLS de Wireshark. También funciona con TLS 1.3, donde la clave privada del servidor ya no basta. En un servidor propio, algunos servidores web y proxies también pueden registrar claves, o puede probar contra una copia de pruebas con el registro activado. Trate los registros de claves como contraseñas: quien tenga el fichero y la captura puede leer el tráfico, así que borre ambos después y nunca los recoja de equipos ajenos sin una base clara y sin que sus usuarios lo sepan. En la supervisión diaria rara vez hace falta descifrar: los metadatos de flujo y el handshake sin cifrar responden a la mayoría de las preguntas sobre quién habla con quién y cómo.

https://netsenx.com/es/faq/how-to-decrypt-tls-for-troubleshooting

## ¿Cómo funciona un handshake TLS?

En TLS 1.3 hace falta un viaje de ida y vuelta antes de que fluyan los datos. El cliente envía un ClientHello con las versiones de TLS, conjuntos de cifrado y grupos de intercambio de claves que admite, una parte de clave para su grupo preferido y normalmente el nombre del servidor al que quiere llegar (SNI). El servidor responde con un ServerHello que elige versión, cifrado y grupo, y su propia parte de clave. De las dos partes, ambos lados derivan el mismo secreto, y desde ese momento todo va cifrado, incluido el certificado del servidor y la prueba de que tiene la clave privada correspondiente. El cliente comprueba el certificado frente a las autoridades en las que confía y empiezan los datos de la aplicación. El ClientHello y el ServerHello viajan sin cifrar, y por eso un sensor pasivo puede ver la versión de TLS, el grupo de intercambio de claves elegido, por ejemplo X25519 clásico o X25519MLKEM768 híbrido, y una huella del cliente sin descifrar nada. Con Encrypted Client Hello, parte del ClientHello, incluido el nombre del servidor, también queda oculta.

https://netsenx.com/es/faq/how-does-a-tls-handshake-work

## ¿Qué cambió entre TLS 1.2 y TLS 1.3?

TLS 1.3 (RFC 8446, 2018) es más rápido y elimina las opciones débiles que estaban detrás de la mayoría de los ataques pasados a TLS. Completa el handshake en un viaje de ida y vuelta en lugar de dos. Solo conserva intercambios de claves con secreto perfecto hacia adelante (forward secrecy), así que grabar tráfico y robar después la clave privada del servidor ya no descifra sesiones anteriores. Abandona cifrados y modos antiguos como RC4, 3DES, los conjuntos en modo CBC y el intercambio de claves RSA estático, y deja una lista corta de cifrados autenticados modernos. Y cifra una parte mayor del handshake, incluido el certificado del servidor. Para la supervisión hay dos consecuencias. Un dispositivo pasivo ya no puede descifrar sesiones con una copia de la clave privada del servidor, de modo que la inspección requiere ahora un proxy de interceptación activo. Y se ve menos en claro: el certificado está oculto, mientras que los mensajes hello, el grupo elegido y el nombre del servidor, salvo que se use Encrypted Client Hello, siguen siendo visibles. Prefiera TLS 1.3 en todas partes y mantenga TLS 1.2 solo con conjuntos de cifrado robustos para clientes antiguos.

https://netsenx.com/es/faq/what-changed-between-tls-1-2-and-tls-1-3

## ¿Deberíamos desactivar TLS 1.0 y 1.1?

Sí. Ambos están formalmente declarados obsoletos por el IETF desde la RFC 8996 (marzo de 2021), los principales navegadores ya no los aceptan y se basan en funciones hash y construcciones de cifrado antiguas con debilidades conocidas. Si siguen activos en un servidor, el riesgo no es tanto un ataque directo como una vía de degradación, y una señal de dejadez que auditores, aseguradoras y escáneres señalarán. Antes de desactivarlos, averigüe quién los usa todavía: impresoras antiguas, escáneres, equipos industriales, aplicaciones heredadas y clientes embebidos son los sospechosos habituales, y desactivarlos sin comprobar puede parar una línea de producción o un terminal de pago. Revise los registros de los servidores que anotan la versión de TLS, pase un escáner externo a los servicios públicos y, dentro de la red, mire las versiones de TLS en los handshakes. Después desactívelos, o aísle en su propio segmento lo que no pueda actualizarse, con un plan para sustituirlo. El mismo inventario le servirá más adelante para el trabajo poscuántico.

https://netsenx.com/es/faq/should-we-disable-tls-1-0-and-1-1

## ¿Qué cifrados TLS deberíamos desactivar?

Todo lo que no tenga secreto hacia adelante o cifrado autenticado, y todo lo de las listas antiguas. En la práctica: desactive RC4, que la RFC 7465 prohíbe en TLS, 3DES y otros cifrados de bloque de 64 bits, los cifrados de exportación y NULL, el intercambio de claves RSA estático y los conjuntos en modo CBC con SHA-1 si sus clientes lo permiten. Mantenga los conjuntos de TLS 1.3, AES-GCM y ChaCha20-Poly1305, y para TLS 1.2 use intercambio ECDHE con AES-GCM o ChaCha20-Poly1305. Use guías de configuración publicadas en lugar de inventar la suya: las recomendaciones de TLS del lado del servidor de Mozilla y las guías del CCN o las directrices técnicas de la BSI alemana ofrecen perfiles probados para clientes modernos y antiguos. Antes de cambiar un servidor de producción, compruebe qué clientes se conectan y qué ofrecen, con los registros del servidor o una vista de los handshakes, para no dejar fuera un equipo antiguo. Después vuelva a probar desde fuera con un escáner TLS y active el grupo híbrido X25519MLKEM768 donde su software lo admita.

https://netsenx.com/es/faq/which-tls-ciphers-should-we-turn-off

## ¿Qué es el secreto hacia adelante (forward secrecy)?

El secreto hacia adelante significa que cada sesión usa una clave nueva y temporal que luego se descarta, de modo que robar más tarde la clave privada a largo plazo de un servidor no descifra las sesiones grabadas antes. Lo proporcionan los intercambios de claves efímeros como ECDHE o X25519: la clave a largo plazo solo demuestra la identidad del servidor, mientras que la clave de sesión sale de valores desechables elegidos por ambos lados. Las configuraciones TLS antiguas con intercambio de claves RSA estático no lo tenían, así que una sola clave robada podía abrir años de tráfico grabado. TLS 1.3 lo hace obligatorio, y los servidores TLS 1.2 bien configurados también lo ofrecen. También explica por qué «harvest now, decrypt later» va del intercambio de claves: el secreto hacia adelante protege frente a un robo futuro de la clave, pero no frente a un futuro ordenador cuántico capaz de romper el propio intercambio efímero de curva elíptica. El intercambio de claves poscuántico híbrido mantiene el secreto hacia adelante y añade la protección que falta. Compruebe sus servidores con un escáner TLS: cada conjunto que ofrezcan debería tenerlo.

https://netsenx.com/es/faq/what-is-forward-secrecy

## ¿Qué es el cifrado, en pocas palabras?

El cifrado convierte datos legibles en datos revueltos que solo alguien con la clave correcta puede volver a leer. El método, llamado algoritmo, es público; el secreto es la clave. Un buen cifrado significa que, sin la clave, ni siquiera un ordenador potente puede recuperar los datos en un tiempo útil. Lo usa a diario: HTTPS en las webs, la VPN a la oficina, las apps de mensajería, el cifrado de disco en portátiles y teléfonos, y las copias de seguridad. Protege los datos en tránsito frente a cualquiera que pueda escuchar la red, y los datos almacenados frente a quien robe el disco. No protege los datos de alguien que ya tiene la clave o que controla un equipo donde se descifran, como un malware en un portátil con la sesión iniciada. Por eso el cifrado va junto al control de accesos, los parches y la supervisión, sin sustituirlos. Un sensor de red ve que se producen conexiones cifradas, con sus metadatos, pero no su contenido.

https://netsenx.com/es/faq/what-is-encryption-in-plain-terms

## ¿Qué diferencia hay entre cifrado simétrico y asimétrico?

El cifrado simétrico usa una sola clave compartida para cerrar y abrir; el asimétrico, o de clave pública, usa un par: una clave pública que cualquiera puede conocer y una clave privada que solo tiene su propietario. Los algoritmos simétricos como AES son rápidos y cifran casi todos los datos reales. Su punto débil es compartir la clave de forma segura. Los métodos de clave pública como RSA, Diffie-Hellman de curva elíptica y sus sucesores poscuánticos lo resuelven: dos partes que nunca se han visto pueden acordar una clave simétrica nueva por una red abierta, y una clave privada puede firmar datos para que cualquiera con la clave pública lo compruebe. Los protocolos reales combinan ambos. Una conexión TLS usa criptografía de clave pública en el handshake para acordar una clave y demostrar la identidad del servidor, y luego pasa a AES o ChaCha20 para los datos. Ese reparto explica también la cuestión cuántica: el algoritmo de Shor amenaza la parte de clave pública, mientras que el cifrado simétrico con claves de 256 bits sigue siendo sólido.

https://netsenx.com/es/faq/what-is-the-difference-between-symmetric-and-asymmetric-encryption

## ¿Qué longitud debe tener una clave de cifrado?

Depende del tipo de algoritmo, porque las longitudes no son comparables entre tipos. En cifrado simétrico, AES-128 se sigue considerando sólido y AES-256 da margen adicional, también frente a futuros ordenadores cuánticos; use 256 bits para datos que deban seguir siendo secretos muchos años. En RSA, 2048 bits es hoy el mínimo habitual, y agencias como la BSI alemana recomiendan al menos 3000 bits para una protección más larga. Las claves de curva elíptica son mucho más cortas con la misma fortaleza: una curva de 256 bits como P-256 o X25519 equivale aproximadamente a un RSA de unos 3000 bits. Para hash, use SHA-256 o superior. Dos matices importan más que las cifras. La longitud no sirve si la clave se ha generado mal, está guardada en un script o nunca se cambia. Y RSA y las curvas elípticas de cualquier longitud caen ante un gran ordenador cuántico, por lo que su sustituto a largo plazo son los algoritmos poscuánticos, no claves más largas. Para los valores exactos, siga las guías vigentes de su agencia nacional, como el CCN.

https://netsenx.com/es/faq/how-long-should-an-encryption-key-be

## ¿Qué es una función hash?

Una función hash convierte cualquier cantidad de datos en una huella corta de longitud fija, como la salida de 256 bits de SHA-256. La misma entrada da siempre el mismo hash, un cambio mínimo da uno completamente distinto, y nadie puede volver del hash a la entrada ni encontrar dos entradas con el mismo hash. Por eso los hashes sirven para comprobar que una descarga o una copia de seguridad no ha cambiado, para las firmas digitales, que firman el hash de un documento, para guardar contraseñas de forma segura y para los controles de integridad dentro de TLS. Funciones antiguas han caído: MD5 y SHA-1 están rotas para usos de seguridad, y en 2017 se demostró públicamente una colisión de SHA-1, así que trátelas como heredadas allí donde aún aparezcan, por ejemplo en certificados antiguos o comprobaciones de ficheros. SHA-256, SHA-384 y SHA-3 son las opciones actuales. Un hash no es cifrado: no hay clave ni nada que descifrar. Los ordenadores cuánticos debilitan las funciones hash solo de forma moderada.

https://netsenx.com/es/faq/what-is-a-hash-function

## ¿Es lo mismo aplicar hash a las contraseñas que cifrarlas?

No, y para contraseñas lo correcto es el hash. El cifrado se puede revertir con una clave, así que quien robe las contraseñas cifradas y la clave recupera todas las contraseñas. Un hash no se puede revertir, de modo que el sistema solo guarda el hash y lo compara al iniciar sesión. Los hashes rápidos normales como SHA-256 siguen siendo una mala elección para contraseñas, porque un atacante que robe una base de datos puede probar cantidades enormes de intentos por segundo con tarjetas gráficas. Use una función pensada para contraseñas, lenta a propósito y con una sal aleatoria por usuario: Argon2id, scrypt o bcrypt, como recomienda la guía de OWASP sobre almacenamiento de contraseñas. Si un proveedor o una aplicación antigua guarda las contraseñas cifradas, o con un hash simple MD5 o SHA-1, trátelo como un hallazgo que corregir. Para su propio personal, las mayores ganancias están en otra parte: la autenticación multifactor (MFA), un gestor de contraseñas y bloquear las contraseñas reutilizadas. Un sensor de red no ve cómo guarda un servidor las contraseñas; eso se revisa en la aplicación.

https://netsenx.com/es/faq/is-hashing-the-same-as-encryption-for-passwords

## ¿Qué es una firma digital?

Una firma digital es un valor calculado a partir de unos datos con una clave privada, que cualquiera con la clave pública correspondiente puede comprobar. Si la comprobación es correcta, quedan demostradas dos cosas: los datos proceden del titular de esa clave privada y no han cambiado desde que se firmaron. Las firmas protegen mucho de aquello en lo que confía sin darse cuenta: actualizaciones de software y controladores, los certificados TLS que demuestran la identidad de una web, PDF firmados y facturas electrónicas, correo firmado con S/MIME y el código que publican sus desarrolladores. En la UE, las firmas electrónicas cualificadas según el Reglamento eIDAS tienen además efectos jurídicos. Una firma es tan fiable como su clave privada: si la roban, un atacante puede firmar malware que parezca legítimo, por eso las claves de firma deben estar en módulos de seguridad hardware o almacenes protegidos de forma similar, y pocas personas deberían poder usarlas. Las firmas actuales usan RSA o curvas elípticas, que un gran ordenador cuántico rompería; sus sustitutos poscuánticos son ML-DSA y SLH-DSA.

https://netsenx.com/es/faq/what-is-a-digital-signature

## ¿Qué es un certificado TLS?

Un certificado TLS es un documento firmado que vincula una clave pública a un nombre, como www.example.com, para que un navegador o cliente pueda comprobar que habla con el servidor real y no con un impostor. La firma procede de una autoridad de certificación (CA) en la que el cliente ya confía, normalmente a través de una cadena: una CA raíz, una CA intermedia y luego el certificado del propio servidor. Durante el handshake, el servidor presenta su certificado y demuestra que tiene la clave privada correspondiente. Los certificados caducan y pueden revocarse. Lo que un certificado no demuestra es que el sitio sea seguro u honrado: una web de phishing puede tener un certificado perfectamente válido, porque las CA comprueban sobre todo el control del dominio, no la empresa que hay detrás. En las empresas, una CA interna suele emitir certificados para servidores, VPN y dispositivos. Mantenga un inventario de todos los certificados con responsables y fechas de caducidad; los olvidados provocan caídas y esconden claves débiles.

https://netsenx.com/es/faq/what-is-a-tls-certificate

## ¿Qué pasa cuando caduca un certificado TLS?

Los clientes dejan de confiar en el servidor: los navegadores muestran un aviso a pantalla completa, y las aplicaciones, API, clientes VPN y dispositivos suelen negarse a conectar. Para los usuarios parece una caída, y en la práctica lo es: páginas de pago, portales de clientes, servidores de correo y enlaces entre máquinas pueden dejar de funcionar en el momento de la caducidad, a menudo de noche o en fin de semana. Los certificados caducados también acostumbran al personal a saltarse los avisos, justo lo que querría un atacante que intercepte el tráfico. La solución es un proceso, no heroicidades: un inventario de cada certificado con su responsable y su fecha de caducidad, alertas con mucha antelación y renovación automática mediante el protocolo ACME (RFC 8555) allí donde la plataforma lo admita. No olvide los certificados dentro de appliances, impresoras, servicios internos y firma de código, que los escáneres externos nunca ven. Observar los handshakes TLS en la red interna ayuda a encontrar servidores que nadie había listado, aunque en TLS 1.3 el certificado en sí va cifrado y hay que comprobarlo en el servidor.

https://netsenx.com/es/faq/what-happens-when-a-tls-certificate-expires

## ¿Por qué se acorta la vida útil de los certificados TLS?

Porque una vida más corta limita el daño de una clave robada o de un certificado emitido por error, y obliga a todos a automatizar la renovación. En abril de 2025, el CA/Browser Forum, el organismo de autoridades de certificación y fabricantes de navegadores que fija las reglas de los certificados TLS públicos, aprobó la votación SC-081: la vida máxima baja de 398 a 200 días a partir del 15 de marzo de 2026, a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. Las reglas se aplican a los certificados de confianza pública, no a los que emite su propia CA interna. Para una empresa que aún renueva certificados a mano una vez al año, cambia la carga de trabajo: las renovaciones serán frecuentes y los procesos manuales fallarán. La respuesta es automatizar con ACME (RFC 8555) o las herramientas de su proveedor, tener un inventario de cada certificado público y de dónde está instalado, incluidos balanceadores y appliances, y vigilar las caducidades. Tómelo como práctica de agilidad criptográfica: la misma disciplina ayudará en la transición poscuántica.

https://netsenx.com/es/faq/why-are-tls-certificate-lifetimes-getting-shorter

## ¿Son un problema los certificados autofirmados en servidores internos?

No por ser autofirmados, sino por lo que suele venir con ellos. Un certificado autofirmado cifra igual de bien que cualquier otro; el problema es la confianza. Los clientes no pueden comprobarlo frente a una autoridad conocida, así que usuarios y administradores aprenden a saltarse avisos o a desactivar la verificación en scripts, y ese mismo hábito deja pasar una interceptación real. Los certificados autofirmados de los appliances tienen a menudo claves débiles o por defecto, nadie sigue su caducidad y no tienen responsable. Un patrón mejor es una autoridad de certificación interna, que emita de forma automática cuando sea posible, cuya raíz esté distribuida en los equipos gestionados, con un inventario de cada certificado y su caducidad. En dispositivos que solo vienen con certificados autofirmados, como impresoras o controladores, sustituya el certificado si el dispositivo lo permite y mantenga el dispositivo en un segmento con acceso restringido. Los certificados autofirmados también van en su inventario poscuántico: cada uno tiene un tipo y tamaño de clave que algún día habrá que cambiar.

https://netsenx.com/es/faq/are-self-signed-certificates-on-internal-servers-a-problem

## ¿Qué es el TLS mutuo (mTLS)?

El TLS mutuo significa que ambos lados de una conexión presentan certificados: el servidor demuestra su identidad al cliente y el cliente al servidor. En el HTTPS normal solo el servidor tiene certificado, y el usuario demuestra quién es después con una contraseña o un token. Con mTLS el cliente necesita una clave privada y un certificado emitido por una autoridad en la que confía el servidor, algo difícil de robar con phishing y fácil de revocar. Es habitual entre servicios en arquitecturas de microservicios, en API entre empresas, para la identidad de dispositivos en IoT y OT y en algunos productos de acceso remoto zero trust. Los costes son la gestión de certificados a escala, es decir, emitir, rotar y revocar certificados de cliente, y diagnosticar problemas cuando algo caduca. En la red, mTLS parece TLS normal. En TLS 1.3 el certificado del cliente va cifrado, así que un sensor pasivo ve que la conexión existe y sus parámetros de handshake, no qué certificado de cliente se usó.

https://netsenx.com/es/faq/what-is-mutual-tls

## ¿Cifra una VPN todo lo que enviamos?

Cifra el tráfico entre su equipo y la pasarela VPN, no todo el camino hasta el destino. Tras la pasarela, el tráfico sigue hacia la red de la oficina o internet protegido solo por lo que use la propia aplicación, como HTTPS. Una VPN corporativa protege, por tanto, al personal en la wifi de un hotel o una cafetería frente a escuchas locales y le da acceso a sistemas internos; no hace segura una aplicación interna sin cifrar ni oculta nada a la red de la empresa que recibe el tráfico. El túnel dividido (split tunnelling) envía por la VPN solo parte del tráfico y el resto directamente, lo que ayuda al rendimiento pero implica que la supervisión de la empresa solo ve una parte. Un servicio VPN comercial traslada su confianza del proveedor de internet al proveedor de VPN. Las propias pasarelas VPN son un objetivo frecuente y necesitan parches rápidos y autenticación multifactor (MFA). En la red, los túneles VPN se ven como conexiones a la pasarela, con su momento y volumen, no su contenido.

https://netsenx.com/es/faq/does-a-vpn-encrypt-everything-we-send

## ¿Cómo encuentro todos los servidores SSH de la red, también los olvidados?

Combine un escaneo activo con observación pasiva, porque cada uno encuentra lo que se le escapa al otro. Un escaneo autorizado de sus rangos de direcciones en el puerto 22 y otros puertos SSH habituales, con una herramienta como Nmap, lista cada equipo que responde y la versión de software que anuncia. Revise sus consolas en la nube y los registros DNS en busca de servidores fuera de los rangos de la oficina. La observación pasiva añade lo que los escaneos no ven: SSH en puertos inusuales, servidores accesibles solo desde ciertos segmentos y cómo se usa realmente SSH, es decir, qué clientes se conectan a qué servidores y cuándo. Después repase la lista con los responsables: cada servidor necesita una persona designada, una razón para existir y un calendario de parches, y lo que nadie reclame se apaga tras un plazo de aviso. Limite SSH a las redes de administración o a un servidor de salto y use claves en lugar de contraseñas. NetSenX alerta en todos los planes cuando un equipo empieza a conectar con muchos equipos internos en puertos de administración como SSH, porque así se ven el escaneo y el movimiento lateral.

https://netsenx.com/es/faq/how-to-find-all-ssh-servers-on-the-network

## ¿Cómo compruebo qué servidores tienen una versión de OpenSSH afectada por un CVE nuevo?

Empiece por la versión que anuncia cada servidor y confírmela después con el estado de parches del proveedor, porque el anuncio por sí solo puede engañar. Cada servidor SSH envía antes que nada una cadena de identificación como SSH-2.0-OpenSSH_9.6p1, que muestra un escáner o una simple conexión. Compare esa versión con el rango del aviso. Para regreSSHion (CVE-2024-6387), por ejemplo, el aviso que publicó Qualys el 1 de julio de 2024 señalaba OpenSSH desde 8.5p1 hasta 9.8p1 sin incluirla, en Linux basado en glibc. Después compruebe la versión del paquete en cada servidor: las distribuciones Linux suelen trasladar las correcciones de seguridad a un número de versión anterior, así que un servidor que anuncia una versión afectada puede estar ya parcheado, y la referencia es el registro de seguridad de la distribución. Parchee con el gestor de paquetes, reinicie el servicio y vuelva a comprobar. Mantenga una lista de servidores SSH en su inventario para que el próximo aviso le lleve minutos y no días.

https://netsenx.com/es/faq/how-to-check-openssh-versions-against-a-new-cve

## ¿Demuestra un banner de versión SSH que un servidor es vulnerable?

No. Es un indicio sólido, no una prueba, y en ambos sentidos. El banner es el texto que un servidor anuncia sobre su software, como OpenSSH_8.9p1 Ubuntu-3ubuntu0.10. Las distribuciones Linux suelen corregir fallos parcheando la versión antigua en lugar de pasar a la nueva versión upstream, así que un servidor puede anunciar una versión catalogada como afectada y estar a salvo; lo dicen el sufijo del paquete de la distribución y su registro de seguridad. El banner también puede cambiarlo u ocultarlo un administrador, y algunos appliances anuncian cadenas engañosas. A la inversa, un número de versión actual no descarta problemas de configuración, como inicios de sesión con contraseña abiertos a internet o claves de host débiles. Use el banner para separar los servidores que conviene revisar primero de los que probablemente están bien, y confirme después en el equipo con el gestor de paquetes o con un escaneo de vulnerabilidades autenticado. Nunca comunique a la dirección que un servidor está comprometido o es vulnerable solo por su banner.

https://netsenx.com/es/faq/does-an-ssh-version-banner-prove-a-server-is-vulnerable

FAQ: https://netsenx.com/es/faq