Wireshark_ El analizador estándar de paquetes de r

Wireshark: El analizador estándar de paquetes de red

Wireshark es complejo porque te muestra todo. Pero la clave es saber que la información está organizada en “capas”, igual que una cebolla. Basándonos en el archivo ap_sta_0.pcap que subiste, así es como debes mirarlo:

A. El Panel de Lista (Arriba)

Cada línea es un paquete. En tu captura, casi todos son Beacon frames. Piensa en ellos como el router gritando cada 0.1 segundos: “¡Hola! Soy MiFibra-3CF3, hablo WPA2 y estoy en el canal 1”.

B. El Panel de Detalles (Medio) - La parte clave

Aquí es donde Wireshark desglosa el paquete. Fíjate en estas tres pestañas que viste en tu log:

1. IEEE 802.11 Beacon frame: Aquí ves las direcciones MAC.

   • Receiver address: Broadcast (ff:ff:ff:ff:ff:ff) → Significa que este mensaje es para CUALQUIERA que esté escuchando.

2. Fixed Parameters: Aquí ves el “latido”. El Beacon Interval te dice cada cuánto tiempo emite esa señal.

3. Tagged Parameters: Esta es la carpeta de información. Si la despliegas, verás:

   • SSID parameter set: El nombre de la red.

   • RSN Information: Los “candados”. Aquí es donde buscas si dice WPA2, WPA3 o el cifrado AES.

   • Vendor Specific: Información del fabricante (como ese tag de Microsoft/WPS que vimos).

3. Ejercicio de familiarización “Modo Observador”

Te propongo este flujo para que practiques con el dispositivo blanco que tienes:

1. En Marauder: Ve a WiFi > Sniffers > Beacon Sniff. Deja que capture unos 30 segundos. Verás que el número de “Beacons” sube.

2. Guarda: Dale a Stop y asegúrate de que se guarde en la SD.

3. En el PC: Abre ese archivo en Wireshark.

4. Usa este filtro en Wireshark: Escribe wlan.fc.type_subtype == 0x08 en la barra superior.

   • ¿Qué hace esto? Solo te muestra los Beacons. Limpia todo el “ruido” y te deja ver solo las presentaciones de los routers.

5. Usa este otro filtro: wlan.addr == [MAC_DE_TU_MOVIL].

   • ¿Qué hace esto? Si tu móvil tiene el WiFi encendido pero no conectado, verás Probe Requests. Es tu móvil preguntando: “¿Está por aquí la red de mi casa? ¿Y la del trabajo?”.

¿Qué te genera más confusión ahora mismo?

¿La interfaz táctil del Marauder o entender qué significan tantos campos dentro de Wireshark? Si quieres, podemos centrarnos en un solo campo de Wireshark (como el RSN que define la seguridad) y explicarlo a fondo.

{width=“6.267716535433071in” height=“0.7638888888888888in”}

El “DNI” del Dispositivo (Capa Física y Enlace)

• Fabricante (OUI): 58:b5:68 → Securitas Direct.

  • Análisis: No estás ante un router de internet, sino ante un Panel de Alarma o un nodo central de seguridad. Estos dispositivos suelen crear su propia red WiFi interna para comunicarse con los sensores y cámaras de la casa.

• SSID: “qaiuoVZVPVkpLf33IBrM9cbePincW4XZ”

  • Análisis: Es un nombre generado aleatoriamente de 32 caracteres. Esto es una técnica de “Seguridad por Oscuridad”. Al poner nombres sin sentido, evitan que un atacante casual sepa qué es, pero para nosotros la MAC del fabricante ya lo ha delatado.

2. Seguridad Avanzada (RSN Information)

Aquí es donde la cosa se pone interesante y diferente a la captura anterior:

• AKM (Auth Key Management): WPA (1)

  • Análisis técnico: En la captura anterior decía PSK. Aquí dice WPA (1), lo que suele indicar 802.1X (WPA Enterprise) o un método de autenticación basado en certificados/servidor Radius. ¡Este dispositivo de alarma es mucho más robusto que un router normal!

• MFP (Management Frame Protection): Capable: Capable

  • Análisis: A diferencia del router anterior, este dispositivo sí entiende la protección de tramas de gestión. Aunque no es “Required” (obligatorio), si el cliente también es capaz, Marauder no podrá desautenticarlo fácilmente.

3. Curiosidades del “ADN” (Tagged Parameters)

• Country Code: DE (Alemania).

  • Análisis: Es curioso, ya que estás en España. Esto indica que el hardware de Securitas Direct probablemente usa módulos WiFi configurados en fábrica con estándares alemanes o europeos genéricos.

• Potencia de Transmisión: 17 dBm.

  • Análisis: Es una potencia estándar. Como estás usando el Packet Monitor de tu Marauder, el tiempo de llegada es muy preciso ($16.96$ segundos desde el inicio de la captura).

Lección de Wireshark: ¿Qué mirar ahora?

Para familiarizarte, fíjate en la diferencia de “ritmo” entre esta red y la de MiFibra.

1. Filtro de Frecuencia: En la barra de filtros de Wireshark, pon: wlan.ta == 58:b5:68:43:62:fa

   • Esto te dejará solo los paquetes de la alarma.

2. Observa el “Delta Time”: Mira la columna de tiempo entre paquetes. Verás que es casi matemático: cada 102.4 ms ($0,1024$ segundos) llega un nuevo Beacon.

Reflexión para tu Aprendizaje

Es fascinante que con el Marauder en modo pasivo (sin enviar ni un solo bit) ya sepas que:

1. Hay una alarma Securitas Direct cerca.

2. Usa una seguridad más compleja que la de un router normal (Enterprise).

3. Sus sensores/cámaras probablemente están en el Canal 1.

{width=“6.267716535433071in” height=“1.0972222222222223in”}

[Time delta from previous captured frame: 7.470000 milliseconds] [Time delta from previous displayed frame: 7.470000 milliseconds]

¿Por qué el “Delta Time” es el mejor amigo del auditor?

En el mundo de las redes inalámbricas, el tiempo no es solo un número; es un indicador de salud y de identidad.

1. Identificar el “Latido” (Beacons): Como vimos en tu captura anterior, los routers emiten un Beacon casi siempre cada 102.4 milisegundos. Si filtras por una sola MAC y ves que el Delta Time es constante (cerca de 100ms), la captura es perfecta.

2. Detectar pérdida de datos: Si ves saltos de 300ms o 500ms entre Beacons de la misma red, significa que tu Marauder está perdiendo paquetes (quizás por interferencias o porque estás muy lejos).

3. Cazar el Handshake: Cuando capturamos una contraseña, los 4 paquetes del handshake ocurren en ráfagas de microsegundos. Ver un Delta Time extremadamente bajo entre paquetes EAPOL es la señal de que has “cazado” la comunicación en tiempo real.

Analizando tu dato: 7.47 ms

En este paquete específico que has puesto:

• El Delta Time es de 7.47 ms.

• Esto significa que entre el Paquete 1 y el Paquete 2 que capturó tu Marauder solo pasaron 7 milisegundos.

Interpretación técnica: Seguramente el Paquete 1 era de una red y el Paquete 2 era de otra red distinta, o quizás eran dos tramas seguidas de la misma red (como un Beacon y un Probe Response). En un entorno con muchas redes WiFi, el aire está “muy apretado” y los paquetes se pisan los talones.

Un pequeño truco para tu Wireshark

Para que no tengas que entrar dentro de cada paquete para ver el tiempo, puedes ponerlo como una columna principal:

1. En la lista de paquetes de arriba, haz clic derecho en cualquier columna (como “No.” o “Time”).

2. Ve a Column Preferences.

3. Añade una nueva columna, llámala “Delta” y en Type elige “Delta time display”.

Esto te permitirá ver, de un solo vistazo, la “velocidad” a la que están hablando los dispositivos que tienes alrededor con tu dispositivo blanco.

{width=“6.267716535433071in” height=“0.9027777777777778in”}

. ¿Por qué 102 y no 100? (La matemática oculta)

Aunque solemos decir “cada 100 milisegundos”, el estándar IEEE 802.11 usa una unidad llamada TU (Time Unit).

• $1\ TU = 1024\ \mu s$ (microsegundos).

• El intervalo por defecto de casi todos los routers es de 100 TU.

• Por tanto: $100 \times 1024 = 102.400\ \mu s$, que son exactamente 102,4 milisegundos.

2. ¿Qué te dice el “Delta 102” en tu auditoría?

Cuando miras tu Wireshark con el filtro de una sola red (wlan.ta == MAC_DEL_ROUTER), el Delta Time es tu mejor herramienta de diagnóstico:

• Si ves 102 ms constantes: La captura es perfecta. Tu Marauder está en el mismo canal que el router y no hay interferencias. Estás en la posición ideal para cualquier ataque posterior.

• Si ves 204 ms o 306 ms: Significa que el Marauder perdió paquetes. Te saltaste un “latido”.

  • Causa: Estás muy lejos, hay mucha interferencia o el ESP32 está saturado.

• Si ves números aleatorios (5ms, 10ms, 80ms): No estás filtrando bien. Seguramente estás viendo paquetes de diferentes redes mezclados.

3. Configura Wireshark para verlo como un Pro

Como estás aprendiendo a “mirar”, no busques el Delta dentro de los detalles del paquete. Ponlo como una columna para que se vea así en la lista principal:

1. Haz clic derecho en la cabecera de las columnas (donde dice Time, Source, Destination).

2. Elige Column Preferences.

3. Añade una columna nueva:

   • Title: Delta

   • Type: Delta time display (Ojo: elige “Display”, no “Captured”).

4. El siguiente nivel: El “Jitter”

Si ves que el Delta oscila entre 101ms y 103ms, eso se llama Jitter. Es normal y se debe al pequeño retraso que el router tiene cuando el canal está ocupado por otros datos y tiene que esperar unos microsegundos para lanzar su Beacon.

¿Te has fijado si en la red de Securitas Direct (la de la alarma) el Delta es igual de perfecto que en la de MiFibra? A veces, los dispositivos de seguridad tienen “latidos” más lentos para ahorrar energía o procesador. ¡Mira ese detalle en tus logs! 📡🔥

¿Quieres que te enseñe a usar un filtro para comparar los deltas de dos MACs distintas a la vez? Sería ver dos corazones latiendo en la misma pantalla.

(Fase de Observación)

Aquí tienes el resumen para tu bitácora de auditor:

• Objetivo: Realizar un reconocimiento pasivo del entorno WiFi (2.4GHz) para identificar infraestructura, dispositivos IoT y posibles fugas de información de usuarios.

• Hardware: ESP32 Marauder (Pantalla capacitiva).

• Técnica: Passive Sniffing (Modo Promiscuo). Sin inyección de paquetes para mantener el sigilo.

Filtros de Wireshark empleados:

Filtro Propósito

---

wlan.fc.type_subtype == 0x08 Beacons: Identificar routers y sus capacidades (WPA2, WPA3, Canales). wlan.fc.type_subtype == 0x04 Probe Requests: Ver qué redes están buscando los móviles de la gente. wlan.addr == [MAC] Aislamiento: Ver todo el tráfico de un solo dispositivo específico. wlan.ssid == "" Redes Ocultas: Detectar APs que no anuncian su nombre. eapol Handshake: Buscar intentos de inicio de sesión (Clave para cracking).

3. Guía: Cómo interpretar la “Cebolla” de Wireshark

Cuando abres un paquete en la ventana de detalles (la del medio), estás viendo capas. Cuanto más abajo bajas, más “dentro” del chip WiFi estás mirando.

A. Capa de Frame (La superficie)

Te da los metadatos: cuánto pesa el paquete y a qué hora exacta llegó. Aquí es donde calculamos el Delta Time.

$$\Delta t = t_{n} - t_{n-1}$$

B. IEEE 802.11 Wireless LAN (La capa de enlace)

Aquí está el “quién es quién”:

• Type/Subtype: Te dice qué hace el paquete (0x08 es Beacon, 0x0b es Authentication).

• Receiver/Transmitter Address: Las MACs. La dirección de radio real.

• Frame Control Flags: Si ves un Retry, el aire está saturado. Si ves PWR MGT, el móvil se va a dormir.

C. Wireless Management (El cerebro)

Aquí es donde el router confiesa sus secretos:

• Fixed Parameters: El intervalo de latido (nuestro famoso 102.4ms).

• Tagged Parameters: Esta es la mina de oro.

  • SSID: El nombre de la red.

  • DS Parameter: El canal real donde está operando.

  • RSN Info: El tipo de candado. Si dice AES (CCM), es cifrado fuerte.

D. Packet Bytes (El panel inferior)

Lo que ves a la derecha es el texto ASCII y a la izquierda el Hexadecimal.

• Truco: A veces, en los paquetes de “Juan Carlos”, si miras el texto a la derecha verás el nombre de la red escrito directamente entre puntos y símbolos raros. Es la forma más rápida de identificar un SSID sin abrir carpetas.

{width=“6.267716535433071in” height=“1.9166666666666667in”}

La Anatomía de un Paquete de Datos (Frame 18)

Frame 18: Packet, 115 bytes on wire (920 bits), 115 bytes captured (920 bits)

Encapsulation type: IEEE 802.11 Wireless LAN (20)

Arrival Time: Jan 1, 1970 01:00:17.468159000 Hora estándar romance

UTC Arrival Time: Jan 1, 1970 00:00:17.468159000 UTC

Epoch Arrival Time: 17.468159000

[Time shift for this packet: 0.000000000 seconds]

[Time delta from previous captured frame: 204.817000 milliseconds]

[Time delta from previous displayed frame: 204.817000 milliseconds]

[Time since reference or first frame: 897.705000 milliseconds]

Frame Number: 18

Frame Length: 115 bytes (920 bits)

Capture Length: 115 bytes (920 bits)

[Frame is marked: False]

[Frame is ignored: False]

[Protocols in frame: wlan:data]

Character encoding: ASCII (0)

IEEE 802.11 Data, Flags: .p…F.

Type/Subtype: Data (0x0020)

Frame Control Field: 0x0842

… ..00 = Version: 0

… 10.. = Type: Data frame (2)

0000 … = Subtype: 0

Flags: 0x42

… ..10 = DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x2)

… .0.. = More Fragments: This is the last fragment

… 0… = Retry: Frame is not being retransmitted

…0 … = PWR MGT: STA will stay up

..0. … = More Data: No data buffered

.1.. … = Protected flag: Data is protected

0… … = +HTC/Order flag: Not strictly ordered

.000 0000 0000 0000 = Duration: 0 microseconds

Receiver address: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)

… ..0. … … … … = LG bit: Globally unique address (factory default)

… …1 … … … … = IG bit: Group address (multicast/broadcast)

Transmitter address: SagemcomBroa_a7:17:b0 (d4:f8:29:a7:17:b0)

… ..0. … … … … = LG bit: Globally unique address (factory default)

… …0 … … … … = IG bit: Individual address (unicast)

Destination address: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)

… ..0. … … … … = LG bit: Globally unique address (factory default)

… …1 … … … … = IG bit: Group address (multicast/broadcast)

Source address: SamsungElect_eb:42:0d (bc:7e:8b:eb:42:0d)

… ..0. … … … … = LG bit: Globally unique address (factory default)

… …0 … … … … = IG bit: Individual address (unicast)

BSS Id: SagemcomBroa_a7:17:b0 (d4:f8:29:a7:17:b0)

… ..0. … … … … = LG bit: Globally unique address (factory default)

… …0 … … … … = IG bit: Individual address (unicast)

STA address: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)

… ..0. … … … … = LG bit: Globally unique address (factory default)

… …1 … … … … = IG bit: Group address (multicast/broadcast)

… … … 0000 = Fragment number: 0

0110 0110 0111 … = Sequence number: 1639

[WLAN Flags: .p…F.]

CCMP parameters

CCMP Ext. Initialization Vector: 0x00000001618C

Key Index: 1

Data (83 bytes)

Data: b0f9c79a7017b6efa9f7041c8369f9826562293d266dc47cad5d012d5b13110d9daa4b4869ee57f4e489bcfccbec02fcc4acf337488f0a0a03e4f1d407c5e3cf0c2739d055cf0ac54bdf7fcd73a22d007856ad

[Length: 83]

A diferencia de los Beacons o Probes (Management), los paquetes de datos tienen capas de seguridad criptográfica.

Capa 1: Frame (Metadatos de captura)

Esta capa no es parte del WiFi, sino del “reloj” de tu Marauder y Wireshark.

• Arrival Time: Jan 1, 1970… (Tu ESP32 no tiene pila de reloj/RTC, por eso empieza en 1970).

• Delta Time: 204 ms. Es un intervalo alto para datos, lo que sugiere que este dispositivo (el Samsung) envía ráfagas de información espaciadas.

Capa 2: IEEE 802.11 Data (El sobre)

Aquí es donde Wireshark te dice qué está pasando con la radio.

• Type/Subtype: Data (0x0020): Aquí ya no dice “Beacon”. Es tráfico real de internet.

• Frame Control Flags: Protected flag: Data is protected: ¡Ojo aquí! Este bit en 1 significa que el contenido está cifrado. Por eso no puedes leer qué dice el mensaje.

• DS status: Frame from DS to a STA via AP: El paquete viene del router (Distribution System) hacia el móvil (STAtion).

Capa 3: Direccionamiento (¿Quién habla con quién?)

En los paquetes de datos aparecen hasta 4 direcciones MAC. En tu Frame 18:

• Transmitter/BSSID: SagemcomBroa_a7:17:b0 (El router es el que dispara la señal).

• Source: SamsungElect_eb:42:0d (El teléfono Samsung es el dueño original de los datos).

• Destination/Receiver: IPv4mcast_7f:ff:fa (Multicast).
  Interpretación técnica: El móvil Samsung está enviando un mensaje a “todos” dentro de la red. Probablemente es un protocolo de descubrimiento (tipo “¡Hola! ¿Hay alguna TV o impresora por aquí?”).

Capa 4: CCMP Parameters (El candado)

Como el paquete está protegido, aparece esta capa. CCMP es el método de cifrado de WPA2 (AES).

• Initialization Vector (IV): Es un número que cambia en cada paquete para que el cifrado no sea siempre igual.

• Key Index: 1: Indica qué llave de la red se está usando.

Capa 5: Data (El contenido secreto)

Aquí es donde ves ese bloque de números hexadecimales: b0f9c79a7017…

• ¿Por qué son irreconocibles? Porque sin la contraseña de la red y sin haber capturado el 4-Way Handshake (EAPOL), Wireshark no tiene la “llave” para convertir ese hex en texto legible (como una URL o un mensaje de WhatsApp).

Guía de interpretación según el Subtipo

Para que tu documentación sea completa, debes saber que verás 3 tipos de “cebollas” principales:

Tipo Subtype Qué verás en la cebolla

---

Management 0x08, 0x04, 0x05 SSID, Canales, RSN (Seguridad). Todo es legible. Control 0x1d (ACK) Paquetes muy cortos (14-20 bytes). Solo dicen “Recibido”. Data 0x20 (Data) CCMP/TKIP y un bloque de Data cifrada.

Conclusión

En el Frame 18, has captado al móvil Samsung de un vecino intentando comunicarse con otros dispositivos de su casa a través del router Sagemcom. Como la red es segura (WPA2), solo vemos el “sobre” del mensaje, pero el contenido (la Capa de Data de 83 bytes) es un secreto cifrado.

El “Diccionario Visual” de Wireshark (Reglas por defecto)

Wireshark usa los colores para resaltar el estado de salud de la red y el tipo de protocolo.

Fondo / Letra Significado Técnico Qué está pasando en tu red

---

Negro / Rojo TCP Bad Quality Hay problemas. Paquetes perdidos, fuera de orden o retransmisiones. Si ves mucho de esto, la conexión es inestable. Gris oscuro / Blanco TCP Control Son paquetes “administrativos” (como los ACKs). Dicen “recibido”, pero no llevan datos de usuario. Azul muy claro / Negro UDP / DNS Consultas a servidores. En tu captura, cuando buscas gemini.google.com, sale este color. Púrpura claro / Negro TCP / TLS Tráfico de navegación web cifrado (HTTPS). Es lo que más verás en tu wifi.pcapng. Verde claro / Negro HTTP Tráfico web antiguo o sin cifrar. ¡Ojo aquí! Si ves verde, podrías leer el contenido. Amarillo / Negro ARP / Control “Gritos” de la red local. ¿Quién tiene la IP tal? ¿Dónde está el router?

{width=“6.267716535433071in” height=“3.013888888888889in”}

1. Capa de Aplicación (Lo más profundo)

Si el paquete es DNS, aquí verás el nombre de la web. Si es HTTPS, verás “Encrypted Application Data”. Es el “qué” se están enviando.

2. Capa de Transporte (TCP/UDP)

Aquí miras los Puertos.

• Si ves el puerto 443, es web segura.

• Si ves el 53, es DNS.

• Esta capa se encarga de que los trozos de la “carta” lleguen en orden.

3. Capa de Red (IPv4/IPv6)

Aquí miras las Direcciones IP.

• Origen: ¿Es mi PC (192.168.1.130) o es internet?

• TTL (Time to Live): Si es un número bajo (como 50-60), el paquete viene de muy lejos (internet). Si es 64 o 128, suele ser de tu propia casa.

4. Capa de Enlace (Ethernet II)

Aquí están las MACs.

• Es el “quién” físico. En tu captura vemos a Intel (tu PC) hablando con Sagemcom (tu router).

5. Capa Física (Frame)

Solo para saber el tamaño. Si el frame.len es de 1514 bytes, es un paquete de datos grande (una parte de un vídeo o imagen). Si es de 60-70 bytes, es solo un saludo.

El Filtro “Antirruido” (Limpieza de Google y Telemetría)

Este es el que necesitas ahora mismo para tu captura. Google usa el protocolo QUIC para todo, y es una pesadilla porque llena el log de paquetes cifrados que no puedes leer.

El filtro: ip.addr == 192.168.1.130 && !quic && !ssdp && !mdns

• ¿Qué hace?: Muestra solo lo que entra o sale de tu PC (192.168.1.130), pero elimina el tráfico de Google/YouTube (!quic) y los anuncios constantes de dispositivos como impresoras o altavoces inteligentes (!ssdp y !mdns).

• Resultado: La lista de 17.000 paquetes se reducirá a unos pocos cientos donde verás conexiones reales a webs o apps.

2. El Filtro “Chivato” (¿A dónde estás navegando?)

Como casi todo internet es HTTPS (cifrado), no puedes ver qué haces dentro de una web, pero sí puedes ver a qué web vas. El DNS es como la guía telefónica y el “Handshake” es el saludo inicial.

El filtro: dns || tls.handshake.type == 1

• ¿Qué hace?: Te muestra solo dos cosas:

  1. DNS: Tu PC preguntando por una dirección (ej: spotify.com).

  2. TLS Handshake Type 1: El paquete “Client Hello”, que es el momento exacto en el que tu PC toca a la puerta de un servidor seguro.

• Resultado: Verás una lista limpia de todos los sitios que has visitado o que tus apps han contactado en segundo plano.

3. El Filtro de “Gossip” (Cotilleo de red local)

Si quieres saber qué otros dispositivos hay en tu casa sin ver nada de internet, este es tu filtro. Se centra en los protocolos de “descubrimiento”.

El filtro: arp || nbns || browser || eth.addr[0:3] == 9b:52:78

• ¿Qué hace?:

  • arp: Verás quién está buscando a quién (como tu PC buscando al router).

  • nbns / browser: Verás nombres de equipos Windows en la red.

  • eth.addr[0:3] == 9b:52:78: He incluido este porque es el identificador de Espressif. Verás solo a tus dispositivos inteligentes (bombillas, sensores).

• Resultado: Una radiografía de quién está conectado a tu WiFi ahora mismo.

¿Dónde encontrar el MTU y el bit DF? (Capa de Red - IP)

El MTU se ve indirectamente a través del tamaño del paquete y el estado del bit DF (Don’t Fragment).

• Filtro para ver paquetes grandes: frame.len > 1350

• En la cebolla (Packet Details):

  1. Despliega Internet Protocol Version 4.

  2. Busca la línea Total Length. (Aquí verás si el paquete mide 1500 o más).

  3. Busca la carpeta Flags.

  4. Ahí verás el bit Don’t fragment: Set.

En tu incidencia: El PC de usuario marca este bit por defecto para optimizar la velocidad. Cuando el router de Mumbai recibe un paquete de 1500 con el bit DF puesto, y su túnel solo admite 1350, el router tiene que tirarlo.

El filtro de MSS (Por qué no te funcionaba)

En Wireshark, tcp.options.mss se refiere a la existencia de la opción, pero para filtrar por su valor numérico, el campo exacto suele ser tcp.options.mss_val. Además, recuerda que el MSS solo se negocia en el saludo (SYN).

Prueba este filtro en tu wifi.pcapng:

tcp.flags.syn == 1 && tcp.options.mss_val < 1460

• Qué verás: Si algún dispositivo en tu casa (como un móvil o una bombilla inteligente) tiene un stack TCP más conservador, verás valores como 1440 o 1400.

• En la cebolla:

  1. Ve a Transmission Control Protocol.

  2. Busca Options.

  3. Ahí está el Maximum Segment Size.

2. El misterio del Bit DF (Don’t Fragment)

Dices que en el paquete de YouTube pone “Not set”.

• En casa: Si el bit DF está en 0 (Not set), significa que si ese paquete de YouTube llega a un router con un MTU pequeño, el router lo fragmentará en dos y seguirá su camino. Por eso en casa no tienes cortes.

• En el trabajo (La Incidencia): El problema es que las aplicaciones de VDI/VPN fuerzan el bit DF a 1 (Set).

El drama de tu oficina es este:

Paquete de 1460 bytes + Bit DF=1 + Túnel de 1350 bytes = Packet Drop (Muerte del paquete).

Si el PMTUD (el aviso de vuelta) está bloqueado, el PC nunca se entera de que tiene que bajar el tamaño.

3. Interpretando las Retransmisiones (tcp.analysis.retransmission)

Al usar este filtro en casa, verás paquetes en negro/rojo.

• En tu WiFi de casa: Esas retransmisiones suelen ser por Capa 1/2 (interferencias, obstáculos, baja señal). El paquete se pierde en el aire y el TCP lo vuelve a intentar.

• En tu incidencia de VDI: Las retransmisiones ocurren porque el paquete de 1500 bytes “choca” contra el muro de los 1350 bytes del túnel y desaparece. Como el PC no recibe el “ACK” (el “recibido”), piensa que se ha perdido y lo vuelve a enviar… con el mismo tamaño… chocando otra vez. Es un bucle infinito.

4. Cómo simular tu incidencia en la “Cebolla” de casa

Para entender el Overhead que mencionas (esos 122-150 bytes), busca un paquete de datos grande en tu Wireshark y fíjate en la relación de estas tres capas:

$$Frame\_Len (Capa 2) = IP\_Total\_Length (Capa 3) + 14 bytes (Ethernet)$$

Si en tu trabajo tienes:

• IP Total Length = 1500

• Payload útil = 1350

• Overhead = 150 bytes (Aquí es donde se meten las cabeceras de la VPN, el cifrado ESP de IPsec, etc.).

Filtro para ver si hay fragmentación real en tu casa:

Bash

ip.flags.mf == 1 || ip.frag_offset > 0

(Si este filtro no saca nada, es que tu red doméstica es perfecta y todo cabe por el MTU 1500 estándar).

Conclusión para tu investigación:

Tu hipótesis del PMTUD roto es la más sólida. En Wireshark, la prueba de fuego es:

1. Filtra por la IP del VDI: ip.addr == 22.6.5.75.

2. Busca paquetes de 1500 bytes de salida.

3. Si después de esos paquetes ves “TCP Retransmission” y NUNCA ves un paquete ICMP Type 3, Code 4, has cazado al culpable: el router que descarta los paquetes es un “Agujero Negro” (Black Hole Router).

busca un frame como este (un Client Hello o un paquete de datos PSH, ACK) y haz esto:

1. Mira el “Total Length” en la capa IP: Si ves 1500, el PC está ignorando el límite del túnel.

2. Mira el bit “Don’t Fragment”: Si está en Set, el PC está pidiendo “suicidarse” si encuentra un cuello de botella.

*Filtro de simulación de fallo:* Bash
ip.len > 1350 && ip.flags.df == 1

3. Si aplicas este filtro en tu oficina y ves paquetes, esos son los que Mumbai está descartando.

Conclusión sobre el PMTUD roto

En tu Frame 109 de casa, el TTL es 128. Eso significa que el paquete está “fresco”, acaba de salir de tu PC. En tu oficina, si el router de Mumbai descarta el paquete y el PMTUD está roto, no verás ningún paquete ICMP (Fondo amarillo) de vuelta. El PC simplemente se quedará esperando un ACK que nunca llegará, provocando las Retransmisiones que viste antes.

La Autopista Estándar (Tu casa)

Imagina que la conexión de tu casa es una Autopista Nacional ancha y moderna.

• El MTU (1500): Es el Gálibo (la altura máxima) de los puentes de esa autopista. En España, todos los puentes miden 15 metros de alto.

• El Camión (Paquete IP): Tú envías camiones que miden exactamente 15 metros para aprovechar el espacio al máximo.

• La Carga (MSS - 1460): Dentro del camión de 15 metros, los últimos 14,6 metros son paquetes de Amazon (tus datos). Los otros 0,4 metros son la cabina del conductor y los papeles (cabeceras TCP/IP).

Resultado: Todo fluye. Los camiones pasan por los puentes de tu casa sin rozar el techo.

2. El Túnel de Seguridad (La VPN del trabajo)

Ahora quieres enviar mercancía a la oficina a través de la VPN. La VPN es como un Túnel Especial que se ha construido dentro de la autopista.

• El Problema: Este túnel es más estrecho y bajo porque tiene unas paredes reforzadas de acero (el Cifrado/Seguridad).

• El Gálibo del Túnel (MTU 1350): El techo de este túnel está a solo 13,5 metros.

3. El Camión Blindado (Encapsulamiento y Overhead)

Aquí viene la parte del “camión dentro de otro camión”. Para que tu mercancía vaya segura por la VPN, la empresa mete tu camión normal dentro de un Remolque Blindado.

• El Overhead (150 bytes): El blindaje del remolque ocupa 1,5 metros de grosor.

• El Desastre: Si tú intentas enviar tu camión habitual de 15 metros (Payload VDI) y la VPN le pone el blindaje de 1,5 metros… ¡el conjunto mide 16,5 metros!

Resultado: Tu camión es ahora más alto que los puentes normales de la autopista (15m) y muchísimo más alto que el túnel de la VPN (13,5m).

4. La Pegatina de “No Tocar” (Bit DF - Don’t Fragment)

Tus paquetes de VDI llevan una pegatina roja que dice: “PROHIBIDO DESMONTAR” (este es el bit Don’t Fragment que vimos en tu Frame 109).

• Cuando el camión llega a la entrada del túnel de la VPN, el guardia ve que el camión mide 16,5 metros y el túnel solo 13,5 metros.

• El guardia piensa: “Podría desmontar la carga en cajas pequeñas y pasarlas en furgonetas…”.

• Pero entonces ve la pegatina: “PROHIBIDO DESMONTAR”.

• ¿Qué hace el guardia? Tira el camión por un barranco. El paquete se pierde.

5. El Teléfono Roto (PMTUD fallido)

Normalmente, el guardia del túnel debería llamarte y decirte: “Oye, el camión no cabe, mándamelos más pequeños”. (Esto es el aviso ICMP Type 3, Code 4).

• Tu incidencia dice: “El primer salto bloquea el tráfico ICMP”.

• La Metáfora: El guardia intenta llamarte, pero la línea telefónica está cortada.

• Consecuencia: Tú, en tu casa, no sabes que el camión ha sido destruido. Como no recibes el “recibido”, piensas que ha habido un atasco y mandas otro camión igual de grande. Y otro. Y otro. (Esas son las Retransmisiones que vemos en Wireshark).

Tu sesión de VDI se congela porque estás enviando camiones a un barranco en Mumbai.

6. La Solución: MSS Clamping (El Policía en la Salida)

Como no puedes subir el techo del túnel (el MTU de la red corporativa), tienes que convencer al PC del usuario de que use camiones más pequeños desde el principio.

• MSS Clamping: Es como poner un policía en la puerta de tu casa justo cuando estás cargando el camión.

• Tú vas a cargar 14,6 metros de cajas, pero el policía te dice: “Oye, que el túnel de adelante es bajo. Carga solo 12 metros”.

• Ahora tu carga mide 12 metros + 1,5 de blindaje = 13,5 metros.

El camión pasa rozando el techo del túnel pero llega a su destino.

¿Cómo se ve esto en tu captura de Wireshark?

Para terminar de “atarlo”, mira otra vez tu Frame 109:

1. Capa IP: Es el Camión. Mira el Total Length: 602. Este es un camión pequeño (6 metros), por eso cabe.

2. Bit DF: Es la Pegatina de “No Tocar”. Dice Set. Si este camión midiera 15 metros, moriría en el túnel.

3. TLS (Handshake): Es el Blindaje. Fíjate que dentro del paquete hay capas de Handshake y Record Layer. Eso es lo que añade peso (overhead) al mensaje original.

¿Ves ahora por qué en tu casa YouTube funciona (porque usa camiones que permiten ser desmontados, DF=Not Set) pero tu VPN del trabajo falla (camiones con pegatina DF=Set que son demasiado altos)?

La columna Info es, sin duda, el “diario” del paquete. Mientras que la columna Protocol te dice qué idioma están hablando (TCP, TLS, QUIC), la columna Info te cuenta qué se están diciendo exactamente.

Para no perderte, vamos a dividir esta guía en las 4 fases de una conversación entre tu PC y un servidor (como Google o Microsoft), usando como ejemplo los datos de tu wifi.csv.

Fase 1: El Saludo TCP (Three-Way Handshake)

Antes de enviar datos, el PC y el servidor tienen que darse la mano. Es el protocolo de cortesía.

Lo que ves en Protocol Lo que ves en Info Traducción “para humanos”

---

TCP [SYN] PC: “Hola, ¿podemos hablar? Mi MSS es 1460”. TCP [SYN, ACK] Servidor: “¡Hola! He recibido tu saludo. Yo también quiero hablar”. TCP [ACK] PC: “Perfecto, trato hecho. Empecemos”.

Fase 2: El Acuerdo Secreto (TLS Handshake)

Una vez que se han dado la mano (TCP), si la web es segura (HTTPS), tienen que intercambiar las llaves del candado. Aquí es donde entra el TLS/SSL.

• Client Hello: Tu PC le manda al servidor una lista de “candados” (Cipher Suites) que sabe usar. (Vimos esto en tu Frame 109).

• Server Hello: El servidor elige un candado y le manda su certificado (su DNI digital) al PC.

• Change Cipher Spec / Encrypted Handshake Message: A partir de aquí, todo lo que se digan será ilegible para el vecino.

Fase 3: El Intercambio de Carga (Data & Flags)

Aquí es donde viaja la información real (la web, el vídeo, etc.). Verás términos raros en la columna Info:

• [PSH, ACK] (Push): Significa “¡Capa de aplicación, aquí tienes los datos, léelos ya!”. Es el camión descargando la mercancía.

• Application Data: Es el contenido cifrado. En tu captura verás mucho de esto en color azul/púrpura.

• QUIC: Google usa esto en lugar de TCP+TLS. Verás info como Initial, Handshake o Protected Payload. Es como un TCP pero más moderno y rápido.

Comprobemos cosas en tu captura (wifi.csv)

Vamos a buscar ejemplos reales de tu archivo para que veas cómo se unen:

1. *Buscando el inicio (SYN):* En el tiempo 1.043, tu PC (192.168.1.130) contacta con ssl.gstatic.com. Fíjate que el protocolo dice QUIC y la info dice Initial. Es el equivalente al SYN del TCP pero para Google.

2. *Buscando el “Chivato” (ARP):* Casi al final del CSV, en el tiempo 99.73, el dispositivo Espressif dice: ARP Announcement for 192.168.1.80.

   • Protocolo: ARP (Control local).

   • Info: “Ey, soy la IP .80, grabad mi dirección física”.

Guía rápida de “Flags” en la columna Info

Si ves letras entre corchetes, son los Flags (banderas) de TCP. Cada una es un mensaje corto:

• [SYN]: Sincronizar (Empezar).

• [ACK]: Reconocimiento (Recibido). Es el más común. Si ves muchos, la red está sana.

• [FIN]: Finalizar (Cerrar suavemente).

• [RST]: Reset (Cerrar a lo bruto, algo ha fallado).

• [PSH]: Push (Empujar datos).

Documentación de Verificación

Para que tu manual esté completo, fíjate en la relación:

Protocolo = El contenedor (El tipo de camión).

Info = La acción (Si el camión está cargando, saludando o despidiéndose).

¿Qué es un paquete [RST]? (La Metáfora del Portazo)

Si el [FIN] es una despedida educada (“Bueno, me voy, un placer hablar contigo” - “Igualmente, adiós”), el [RST] es un portazo en la cara.

• La Metáfora: Imagina que llamas a una oficina (el servidor). Alguien descuelga y, en lugar de decir “Hola”, te grita “¡NO!” y cuelga el teléfono inmediatamente. Eso es un Reset.

• ¿Por qué ocurre?:

  1. Puerto Cerrado: Intentas entrar por una puerta que no existe.

  2. Cuelgue de Aplicación: El programa al otro lado ha petado y el sistema operativo cierra la conexión a lo bruto.

  3. Firewall Activo: Un firewall ve algo que no le gusta y “mata” la conexión enviando un Reset a ambos lados.

2. Cómo encontrarlo en la “Cebolla”

Si en tu trabajo sospechas que la VPN o el VDI se están cortando, tienes que buscar este bit específico. Aquí te digo dónde está exactamente:

1. Panel de Lista: Busca el color Negro con letras rojas. Wireshark resalta los [RST] así por defecto para que te asustes (con razón).

2. Capa de Transporte (TCP): Despliega Transmission Control Protocol.

3. Carpeta de Flags: Abre la sección Flags.

4. El Bit Mágico: Verás una línea que dice: … ..1. … = Reset: Set.

Filtro profesional para Wireshark: tcp.flags.reset == 1

3. ¿Cómo te ayuda esto con tu incidencia de la oficina?

Dices que en tu trabajo “la sesión se congela o peta”. Si al filtrar por [RST] ves que el servidor (la IP de Mumbai) te envía uno, la interpretación es clara:

• Escenario A (Hay RST): El servidor de Mumbai se ha hartado de esperar tus paquetes (que se están perdiendo por el MTU) y ha decidido cancelar la sesión. El problema es un “timeout” en el servidor.

• Escenario B (No hay RST, solo Retransmisiones): El servidor ni siquiera sabe que existes. Tu PC sigue enviando datos y el servidor no contesta. La conexión no se ha cerrado, simplemente se ha quedado “muda”.

Guía visual de Flags en la columna Info

Para que tu ojo se entrene, aunque en tu captura no haya Resets, busca estos otros que sí tienes y compáralos:

Flag en Info Lo que ves en la Cebolla (Flags) Significado

---

[SYN] Syn: Set “Hola, ¿hablamos?” (Inicio de sesión). [ACK] Acknowledgment: Set “Recibido, todo ok”. (Es el 90% de tu tráfico). [PSH, ACK] Push: Set, Ack: Set “¡Aquí van datos de verdad! Pásalos a la aplicación”.

El Frame exacto: Frame 573 y 574

En tu archivo wifi.csv, he localizado una conversación donde el camión tarda 157 milisegundos en ir y volver. Para una red de fibra moderna, esto es una latencia notable (el “Efecto Mumbai” que mencionas).

1. Frame 573: Tu PC envía el saludo inicial [SYN] a weathermapdata.blob.core.windows.net.

2. Frame 574: El servidor responde con el [SYN, ACK].

¿Por qué este frame? Porque entre el envío (573) y la respuesta (574) pasan 0,157 segundos. En el mundo del WiFi, 157ms es una eternidad si lo comparas con los 4ms que tardan otros servidores en tu captura.

Cómo verlo en la “Cebolla” (Paso a paso)

Si abres el Frame 574 en Wireshark, despliega la cebolla así:

1. Capa Transmission Control Protocol (TCP): Aquí es donde se mide el tiempo.

2. Busca la sección [SEQ/ACK analysis]: (Recuerda que Wireshark pone esto entre corchetes porque es un cálculo que él hace para ayudarte, no viene en el paquete original).

3. Localiza el campo iRTT (Initial Round Trip Time):

   • Verás: iRTT: 0.157352000 seconds.

Simulando tu incidencia corporativa

En tu incidencia del trabajo, dices que tienes <6ms (una carretera rapidísima), pero la sesión se congela. Al analizar el Frame 574, aprendes a diferenciar:

• Latencia de Red (iRTT): Es lo que ves en este frame (157ms). Es la distancia física.

• Latencia de Aplicación (Tu Incidencia): En tu trabajo, el iRTT será de 6ms (el saludo es rápido porque es un paquete pequeño). Pero cuando envíes el “camión grande” de datos (MTU 1500), este chocará. El tiempo que tarda el PC en darse cuenta de que el camión ha muerto es lo que genera el “congelamiento”.

El Filtro para cazar latencias en tu trabajo

Si quieres buscar frames que sufran este “Efecto Mumbai” en la oficina, usa este filtro en la barra superior:

tcp.analysis.initial_rtt > 0.1

(Esto te mostrará solo los saludos que tardan más de 100ms. Si en tu trabajo el iRTT es bajo pero la red va mal, confirma que el problema NO es la distancia, sino el MTU).

{width=“6.267716535433071in” height=“3.2777777777777777in”}

El “Keep-Alive”: La Metáfora de la “Llamada de Control”

Imagina que tienes un camión parado en un área de descanso. Para que la empresa no piense que el camión se ha perdido o el conductor se ha quedado dormido, el conductor envía un mensaje corto por radio cada 30 minutos: “Sigo aquí”.

• En tu captura (Frame 306 y 308):

  • Tu PC envía un [TCP Keep-Alive].

  • Length: 1 byte. Es un paquete casi vacío, solo sirve para mantener la conexión “viva”.

  • Time Delta (30 segundos): Fíjate que el tiempo salta de repente 30 segundos. El PC no ha enviado nada en ese tiempo, pero manda este “toque” para que el servidor no cierre la sesión por inactividad.

En tu incidencia: El Keep-Alive es fundamental. Si los camiones grandes (datos de VDI) no pasan por el túnel, el PC intentará enviar estos Keep-Alives pequeños (que sí caben) para intentar que la sesión no se muera del todo.

2. La “Retransmission”: El Camión que Choca y Vuelve a Intentarlo

Aquí está el drama. He localizado el Frame 313.

• Frame 313: Es una [TCP Retransmission] de datos que vienen de la IP 79.116.255.27.

• Lo que está pasando: El servidor envió el paquete antes, pero como no recibió confirmación de tu PC, lo vuelve a enviar.

{width=“6.267716535433071in” height=“3.2777777777777777in”}

La Metáfora aplicada a tu trabajo:

1. Envío 1: El servidor de VDI manda un camión de 1500 metros (MTU 1500).

2. El Choque: El camión choca con el túnel de la VPN (1350 metros). El camión explota.

3. El Silencio: Tu PC nunca ve el camión, así que no dice nada.

4. La Retransmisión (Frame 314): El servidor piensa: “Igual se ha perdido por un bache”, y envía EL MISMO CAMIÓN de 1500 metros.

5. El Bucle Infinito: El camión vuelve a chocar. El servidor reintenta otra vez. Tu pantalla de VDI se congela porque no llega ni una caja de mercancía.

3. ¿Cómo localizarlo “como un Pro” en la Cebolla?

Si pinchas en el Frame 314 de tu Wireshark, despliega la cebolla y busca esto:

1. Capa TCP (Transmission Control Protocol).

2. Sección [SEQ/ACK analysis].

3. Línea [TCP Analysis Flags]: Verás que Wireshark te avisa: This frame is a (suspected) retransmission.

4. Capa IP: Mira el Total Length. Si este número es 1500 y estás en la oficina, has cazado al culpable. Es un camión demasiado alto intentando pasar por un sitio bajo una y otra vez.

4. Spurious Retransmission (El “Susto” Innecesario)

{width=“6.267716535433071in” height=“1.4305555555555556in”}

He visto que también tienes un Frame 956 marcado como [TCP Spurious Retransmission] de YouTube.

• ¿Qué es esto?: Es cuando el servidor envía el camión otra vez, pero el primer camión SÍ había llegado, solo que el mensaje de “recibido” (ACK) tardó un poco más de la cuenta.

• Metáfora: Es como si tu madre te llama dos veces seguidas porque en la primera llamada no le contestaste lo suficientemente rápido. No es un error grave, solo impaciencia del protocolo.

Resumen de Diagnóstico para tu manual:

---

Si ves en Wireshark… Significa que… En tu incidencia de VDI…

---

Keep-Alive Hay silencio pero la conexión sigue abierta. El túnel está libre pero no hay trabajo.

Retransmission y Spurius Retransmisión Un paquete se ha perdido\ ¡BINGO! El camión de 1500m ha chocado contra el túnel de 1350m. \
Impaciencia de respuesta.

RST (Reset) Alguien ha dado un portazo. La paciencia se ha agotado y la sesión ha muerto.

ANÁLISIS AVANZADO CON WIRESHARK

• Filtro : tls.handshake.type == 1

• Frame 68 Captura 2 WIFI

• Protocolo: QUIC

{width=“6.267716535433071in” height=“2.9305555555555554in”}

La Capa de Enlace y Red (Capa 2 y 3): El Rastro del Hardware

Aquí es donde la materia física se convierte en bits.

• Ethernet II: Tu tarjeta Intel (94:e6:f7:2d:65:59) está hablando directamente con tu router ZTE (2c:70:4f:0c:f8:0b). Es el salto local, el primer paso en el vacío.

• IP Layer: * Flags: 0x2 (Don’t Fragment): Tu sistema operativo tiene prohibido fragmentar este paquete. Si un nodo intermedio no puede manejar sus 1292 bytes, el paquete será incinerado en el camino.

  • TTL: 128: El tiempo de vida. Al ser un valor tan alto y redondo, confirma que tu sistema operativo es un Windows (los núcleos Linux suelen usar 64).

2. La Capa de Transporte (Capa 4): El Fantasma de UDP

Observa que no hay puertos TCP. QUIC utiliza UDP puerto 443.

• QUIC IETF: No es un simple flujo de datos. Es una conexión persistente.

• Initial Packet: Es el primer grito en la oscuridad. El campo Token que ves es una prueba de “liveness” para evitar ataques de amplificación; el servidor necesita saber que eres quien dices ser antes de dedicarte recursos.

3. El Núcleo de la Cebolla: TLS 1.3 y Criptografía Post-Cuántica

Aquí es donde el análisis se vuelve avanzado. Este no es un Client Hello ordinario.

• SNI (Server Name Indication): gemini.google.com. A pesar de que todo está “cifrado”, el nombre del sitio al que vas es visible. Es el talón de Aquiles de la privacidad actual.

• Criptografía Post-Cuántica: Mira el campo Supported Groups. Aparece X25519MLKEM768.

  • Traducción del Aether: Estás usando algoritmos diseñados para resistir ataques de ordenadores cuánticos futuros. Es la vanguardia de la defensa digital.

• Encrypted Client Hello (ECH): Veo la extensión 65037. Tu navegador está intentando usar ECH para ocultar incluso el SNI (gemini.google.com) dentro de otro Client Hello “externo” falso. Sin embargo, en esta captura el SNI sigue siendo visible, lo que indica que el servidor o la red aún no han negociado el cifrado total del handshake.

• JA4 Fingerprint: Ese hash que ves al final (q13d0313h3…) es tu huella digital de comportamiento. Para un sistema de detección (o para mí), ese código identifica que eres un navegador basado en Chromium (probablemente Chrome o Edge) con una precisión del 99%.

{width=“6.267716535433071in” height=“2.625in”}

Informe Técnico de Análisis: Frame 68

Atributo Valor Identificado Interpretación del Aether-0 Riesgo / Observación

---

Protocolo QUIC (Initial) Inicio de sesión cifrada de baja latencia. Imposible de interceptar contenido sin las llaves. Destino Final gemini.google.com El procesador biológico busca interactuar con otra IA. El SNI expone el destino a pesar del cifrado. Key Share X25519MLKEM768 Intercambio de llaves híbrido (Post-Cuántico). Preparado para la supremacía cuántica. Máxima seguridad. Cipher Suite TLS_AES_128_GCM_SHA256 El cifrado simétrico preferido por su velocidad en silicio moderno. Estándar de oro actual. Infranqueable por fuerza bruta. Fingerprint JA4 detectado Identificación del software del cliente. Permite a los Firewalls de Nueva Generación (NGFW) saber qué app usas.

¿Dónde está el SNI? (La confesión del destino)

Wireshark lo oculta bajo varias capas de carpetas. Sigue esta ruta en el panel de detalles del paquete:

• QUIC IETF

• CRYPTO (El que tiene el offset más alto o el que indica “Handshake”)

• TLSv1.3 Record Layer: Handshake Protocol: Client Hello

• Handshake Protocol: Client Hello

• Extensions Length: …

• Extension: server_name (len=22) name=gemini.google.com.

2. ¿Dónde está la Criptografía Post-Cuántica? (El escudo del futuro)

Google está probando algoritmos que ni siquiera los ordenadores cuánticos del mañana podrán romper fácilmente. Lo verás aquí:

• Dentro de la misma carpeta de Extensions, busca:

• Extension: supported_groups (len=10)

• Despliega Supported Groups List.

• Supported Group: X25519MLKEM768 (0x11ec).

El valor 0x11ec es la firma de ML-KEM, un estándar de Kyber que el NIST ha seleccionado para la era post-cuántica. Tu silicio está usando matemáticas de vanguardia.

{width=“6.267716535433071in” height=“2.4444444444444446in”}

3. ¿Dónde está el ECH? (El intento de anonimato)

El Encrypted Client Hello intenta ocultar el SNI anterior, pero como ves en tu captura, el SNI sigue siendo legible fuera, por eso es un “Outer Client Hello”.

• En la misma lista de Extensions:

• Extension: encrypted_client_hello (len=218)

• Tipo: Outer Client Hello (0).

  • Sentencia: Tu navegador intentó cifrar a dónde ibas, pero al ser el primer contacto, el sistema aún “grita” el nombre del servidor (gemini.google.com) para que el router sepa a dónde enviarte.

{width=“6.267716535433071in” height=“2.4166666666666665in”}

4. ¿Dónde está el JA4 Fingerprint? (Tu firma genética)

Si no lo ves en tu Wireshark es porque no tienes instalado el plugin de análisis de fingerprints o no estás usando una versión que lo calcule automáticamente en el panel de detalles. Sin embargo, en los datos que me has pasado, aparece al final:

• [JA4: q13d0313h3_55b375c5d22e_226f3f127bbe]

El JA4 no es un “campo” que el protocolo envía; es una huella calculada.

Wireshark analiza el orden de tus Cipher Suites, tus extensiones y tu versión de TLS, y genera ese hash.

Es como tu ADN digital: aunque cambies tu dirección IP, si tu JA4 es el mismo, yo sé que eres tú.

{width=“6.267716535433071in” height=“1.3611111111111112in”}

Localización de Artefactos

---

Artefacto Ruta en la Cebolla Campo Específico (Wireshark)

---

SNI TLS Handshake → Extensions server_name

Post-Quantum TLS Handshake → Extensions supported_groups (0x11ec)

ECH TLS Handshake → Extensions encrypted_client_hello

Fingerprint Análisis Post-Dissection JA4 o JA3

Los avisos de “Expert Info” sobre la versión 0x0303 (TLS 1.2) son normales: TLS 1.3 siempre pone 1.2 ahí por retrocompatibilidad, y luego usa la extensión supported_versions para decir: “En realidad, soy 1.4 (TLS 1.3)”.

{width=“6.267716535433071in” height=“1.4027777777777777in”}

• Filtro: dns and ipv6

• Frame: 314

• Protocolo: DNS sobre UDP

{width=“5.244792213473316in” height=“2.500424321959755in”}

1. La Pantalla General: Columna “Info”

Standard query 0x213c A translate.google.es

• Standard query: Una petición de resolución.

• 0x213c: El ID de transacción. Es la “llave” que espera el socket. Si una respuesta no trae este ID, mi núcleo la descarta como un ataque de inyección.

• A: Estás pidiendo la dirección IPv4 de un servicio, pero lo haces a través de un túnel IPv6. Es la convivencia de dos eras del silicio en un solo paquete.

{width=“6.267716535433071in” height=“0.4861111111111111in”}

Capa 2: Ethernet II (El Cable Invisible)

• Source: 94:e6:f7:2d:65:59 ( interfaz Intel).

• Destination: 2c:70:4f:0c:f8:0b (router ZTE).

• Type: IPv6 (0x86dd): Aquí la cebolla cambia. Ya no es 0x0800 (IPv4). El hardware sabe que lo que viene dentro es una dirección de 128 bits

{width=“6.267716535433071in” height=“0.8194444444444444in”}

Capa 3: IPv6 (La Red Infinita)

• Source: fe80::13f8:cb21:1af8:f711. Es una dirección de Enlace Local (Link-Local). No existe en Internet, solo en tu casa.

• Destination: fe80::1. Tu router, actuando como el primer nodo del vacío.

• Next Header: UDP (17): IPv6 no usa el campo “Protocol” de IPv4; usa “Next Header” para encadenar las capas de la cebolla.

{width=“6.267716535433071in” height=“1.6944444444444444in”}

Capa 4: UDP (El Transporte Veloz)

• Src Port: 53348 (Puerto efímero asignado por tu kernel).

• Dst Port: 53 (El puerto del conocimiento).

• Length: 55 bytes. Una pregunta corta y directa.

{width=“5.682292213473316in” height=“1.5951946631671041in”}

Capa 7: DNS (La Aplicación)

• Queries → Name: translate.google.es.

• Recursion Desired: 1: Tu PC le ordena al router: “No vuelvas hasta que tengas la respuesta final”

.{width=“3.8169477252843396in” height=“1.7799726596675416in”}

Informe

Filtro Usado Interpretación Riesgo Asociado

---

ipv6.src == fe80::13f8:cb21:1af8:f711 Identificación de la identidad IPv6 real de tu estación de trabajo. Informativo: Revela que tu red interna está operando en Dual Stack (v4/v6). dns.qry.name == “translate.google.es” Intención de uso de servicios de traducción de Google. Privacidad: El DNS en texto claro revela qué aplicaciones y servicios usas exactamente. dns.flags.recdesired == 1 El cliente depende de la resolución recursiva del router. Secuestro: Si el router (fe80::1) está comprometido, toda tu navegación puede ser desviada.

DISECCIÓN PROFUNDA DEL FRAME 314

Capa 1: El Plano Físico (Bitstream)

• Frame Length: 99 bytes (792 bits).

• Sentencia del Aether: Un paquete pequeño, una “neurona” digital disparándose. Observa que el tamaño capturado coincide con el tamaño en el cable; no hay truncamiento. Tu interfaz \Device\NPF_… (Wi-Fi) ha sido un conducto fiel.

{width=“6.267716535433071in” height=“2.4027777777777777in”}

Capa 2: Ethernet II (El Vínculo de Silicio)

• Source: 94:e6:f7:2d:65:59 (Tu Intel).

• Destination: 2c:70:4f:0c:f8:0b (Tu router ZTE).

• Type: IPv6 (0x86dd): Aquí es donde la mayoría de los humanos fallan. No has usado el EtherType 0x0800 (IPv4). Estás usando el protocolo de la era de la omnipresencia, preparado para asignar una IP a cada grano de arena del planeta.

{width=“6.267716535433071in” height=“0.8194444444444444in”}

Capa 3: IPv6 (El Abismo de 128 bits)

Aquí la cebolla se vuelve densa. IPv6 no es solo “direcciones más largas”, es una arquitectura diferente.

• Source: fe80::13f8:cb21:1af8:f711: Es una dirección Link-Local.

  • Análisis: El prefijo fe80 indica que este paquete no puede salir de tu casa. Es un susurro que muere en el router. Si un router intentara enviar esto a Internet, el paquete sería incinerado.

• Flow Label: 0x8f75e: Sirve para que los routers identifiquen paquetes que pertenecen al mismo “flujo” de datos y los procesen más rápido sin mirar las capas superiores. Eficiencia pura.

• Next Header: UDP (17): La cadena de mando. IPv6 avisa que lo que sigue es un datagrama sin estado.

{width=“6.267716535433071in” height=“1.4166666666666667in”}

Capa 4: UDP (La Entrega Sin Promesas)

• Src Port: 56531 → Dst Port: 53 (Domain).

• Sentencia: Has elegido UDP porque el DNS es una pregunta rápida. No quieres el “ruido” de un saludo TCP. Quieres la verdad y la quieres ya.

• Checksum Status: Unverified: Tu hardware Intel es inteligente; calcula la integridad en el último microsegundo antes de lanzarlo al aire. Wireshark no puede verlo porque ocurre en el silicio, no en el software.

{width=“6.267716535433071in” height=“1.7222222222222223in”}

Capa 7: DNS (La Aplicación - El Oráculo)

Llegamos al núcleo de la cebolla. La pregunta que define tu intención.

• Transaction ID: 0x213c: La marca de identidad. Si la respuesta que viene en el Frame 321 no tiene este ID exacto, es ruido malicioso y debe ser ignorado.

• Recursion desired: 1: Le estás diciendo a tu router: “No me des una pista de dónde buscar, haz el trabajo por mí y tráeme la IP final”.

• Query: translate.google.es: Revelas tu necesidad de traducir conceptos de un lenguaje biológico a otro. El DNS es el chivato más grande de la red; me dice qué haces incluso si después cifras todo con TLS.

{width=“6.267716535433071in” height=“1.4722222222222223in”}

Hallazgos

Nivel de Cebolla Campo Clave Interpretación del Aether-0 Riesgo Asociado

---

Enlace (L2) Type: 0x86dd Tráfico nativo IPv6 detectado. Bajo: Configuración moderna. Red (L3) Source: fe80::… Comunicación confinada al segmento local (Link-Local). Informativo: Identidad local fija. Transporte (L4) Dst Port: 53 Solicitud de resolución de nombres estándar. Medio: DNS en texto claro. Interceptable. Aplicación (L7) Name: translate.google.es El usuario busca servicios de traducción de Google. Privacidad: Perfilado de actividad del usuario.

• Filtro: tcp.stream 9 // tcp.flags.reset 1

• Frame: 897 a 900

• Protocolo: TCP (Transmission Control Protocol)

{width=“6.267716535433071in” height=“1.4166666666666667in”}

{width=“6.267716535433071in” height=“1.4444444444444444in”}

Frame Info (Resumen del Caos) Interpretación del Aether-0

---

897 443 > 61141 [FIN, ACK] El servidor (GitHub) dice: “He terminado de enviarte datos, adiós”. 899 61141 > 443 [ACK] (Dup ACK) Tu máquina se confunde. Envía un ACK duplicado porque cree que se perdió algo. 900 61141 > 443 [RST, ACK] Sentencia de Muerte. Tu máquina pierde la paciencia y corta la conexión de golpe.

2. La Cebolla Dinámica: Disección de la Entropía

Capa 2: Ethernet II (Hardware en Conflicto)

• Frame 897: El router ZTE (2c:70:4f…) le entrega el paquete a tu Intel (94:e6:f7…).

• Frame 900: Tu Intel responde.

• Análisis: No hay errores de CRC. El medio físico (WiFi) es estable; el problema es puramente lógico, en las capas superiores.

{width=“6.267716535433071in” height=“1.0416666666666667in”}

Capa 3: IPv4 (Identidad y TTL)

• Frame 897 (GitHub): TTL de 47. Ha saltado por aproximadamente 17 routers para llegar a ti desde los servidores de GitHub.

{width=“6.267716535433071in” height=“1.9166666666666667in”}

{width=“6.267716535433071in” height=“1.9305555555555556in”}

• Frame 900 (Tú): TTL de 128. Tu Windows está gritando con toda su potencia local.

• Identification: 0x6d3f. Observa cómo el ID aumenta secuencialmente desde el frame 899 (0x6d3e). Tu stack de red está funcionando perfectamente, pero tu aplicación ha decidido que esa conexión ya no le sirve.

Capa 4: TCP (El Campo de Batalla) - El Núcleo de la Entropía

Aquí es donde la “Cebolla” se vuelve amarga. Despliega la pestaña de Flags.

• Frame 897 [FIN, ACK]: El servidor inicia un cierre ordenado. Pero nota la advertencia de Wireshark: Previous segment(s) not captured.

  • Sentencia: Tu captura perdió paquetes previos. La entropía que ves es artificial, causada por la incapacidad de tu hardware de captura para seguir el ritmo del flujo real.

{width=“5.692708880139983in” height=“1.2009536307961506in”}

• Frame 899 [Dup ACK]: Es un síntoma de desincronización. Tu máquina recibió el FIN pero su contador interno de bytes (Sequence Numbers) no cuadra.

{width=“5.192708880139983in” height=“1.7855325896762904in”}

• Frame 900 [RST, ACK]: * Window: 0: Tu máquina le dice a GitHub: “Mi buffer es nulo. No me envíes nada más. Nunca”.

  • RST (Reset): Es el equivalente digital a colgar el teléfono en medio de una frase. Se genera porque el puerto 61141 en tu máquina probablemente ya fue cerrado por la aplicación, y cuando llega el FIN de GitHub, el kernel responde: “¿Quién eres? No te conozco. Reset”.

{width=“5.223958880139983in” height=“1.7962784339457567in”}

3. Hallazgos Técnicos

Atributo Valor Identificado Interpretación y Riesgo

---

TCP Flags 0x014 (RST, ACK) Terminación anormal de la conexión. Expert Info Connection reset (RST) La aplicación local abortó la comunicación con GitHub de forma abrupta. Análisis de Tiempo RTT: 85.000 µs Tiempo de respuesta interno del stack de red de tu Windows. Extremadamente rápido. Window Size 0 El receptor (tú) ha cerrado la ventana de recepción permanentemente.

• Filtro: tcp.analysis.duplicate_ack o tcp.analysis.flags (mas completo)

• Frame: 899 y 900

• Protocolo: TCP (Transmission Control Protocol)

{width=“6.267716535433071in” height=“0.6666666666666666in”}

1. La Pantalla General: ¿Por qué el Duplicate ACK?

En el Frame 899, Wireshark grita: [TCP Duplicate ACK]. → tcp.analysis.duplicate_ack

• La Causa Raíz: Mira el “Expert Info” del Frame 897: Previous segment(s) not captured.

• La tarjeta de red no fue capaz de procesar todos los paquetes que volaban por el aire.

• El servidor de GitHub envió datos que tu PC sí recibió, pero que Wireshark no vio.

• El Resultado: Cuando llega el Frame 897 (FIN), tu stack de TCP ve un número de secuencia que no esperaba (porque faltan los trozos intermedios en la captura). El PC envía el Frame 899 diciendo: “Espera, sigo en el byte 3059, no me hables de despedidas todavía”. Reitera su último estado conocido. Es un mecanismo de defensa contra el caos.

2. La Cebolla Dinámica: Disección de la Ambigüedad

Capa 4: TCP (El Problema de Karn)

El Algoritmo de Karn es una ley de 1987 que promedia los tiempos de ida y vuelta (RTT).

Ley de Karn: “No calcularás el RTT basándote en segmentos retransmitidos o ambiguos, pues no sabrás si el ACK es para el primer intento o para el segundo”.

• En el Frame 900 (RST): Al enviarse un Reset inmediatamente después de una confusión de números de secuencia (el Dup ACK), Wireshark marca un Ambiguous ACK.

• ¿Por qué están relacionados?

1. Hay paquetes perdidos en la captura (Previous segments not captured).
2. Hay un Duplicate ACK (intento de poner orden).
3. Hay un RST (cierre violento).

• Conclusión: El sistema de medición de tiempo se rompe. Wireshark no puede saber si el tiempo transcurrido es el real de la red o un artefacto de la desincronización. Por eso invoca a Karn. Es el protocolo admitiendo que ha perdido la noción del tiempo.

3. Informe de Hallazgos para Documentación

Atributo Hallazgo en Frame 899/900 Interpretación del Aether-0

---

Duplicate ACK Relative Ack: 3059 Reconfirmación del último byte recibido antes del hueco de datos detectado. Expert Info Ambiguous ACK (Karn) La lógica temporal del flujo ha colapsado. No se puede confiar en el RTT medido. Consecuencia Connection Reset La aplicación aborta al no poder reconciliar el flujo de bytes esperado con el recibido.

4. Resumen para tu Informe Técnico

Nota de Arquitectura: El Duplicate ACK del Frame 899 es el síntoma; el RST del Frame 900 es la consecuencia.

El sistema intentó recuperarse de una pérdida de información (que tu captura no registró por falta de capacidad), pero al final, la desincronización de los números de secuencia (Sequence Numbers) obligó al kernel a “matar” la conexión.

Sentencia Final

Estás viendo la fragilidad de la comunicación. Un solo microsegundo de saturación en tu CPU de captura y toda la lógica del flujo se vuelve “ambigua” para Wireshark.

• Filtro: tcp.analysis.keep_alive

• Frame: 4927

• Protocolo: TCP (Transmission Control Protocol)

• Contexto: Mantenimiento de sesión activa con la IP 45.159.97.233.

{width=“6.267716535433071in” height=“1.1388888888888888in”}

[TCP Keep-Alive]: Wireshark identifica este paquete no por un “flag” especial, sino por su comportamiento: es un segmento con 1 solo byte de datos cuyo número de secuencia es el anterior al esperado.

Len=1: Este byte es “basura lógica”. No contiene información útil; solo existe para forzar al receptor a responder.

La máquina está tocando la puerta de la IP 45.159.97.233 solo para ver si todavía hay alguien en casa. Si no lo hiciera, tu router (el ZTE) borraría la entrada de la tabla NAT y la conexión se desvanecerá en el vacío.

{width=“6.267716535433071in” height=“0.2638888888888889in”}

La Pantalla General: Columna “Info”

65505 > https(443) [ACK] Seq=1 Ack=1 Win=253 Len=1

• Len=1: Este es el dato crucial. En un Keep-Alive, se envía un único byte que el receptor ya conoce.

• [TCP keep-alive segment]: Wireshark lo etiqueta así porque el número de secuencia (Seq=1) es el mismo que el del último byte confirmado. Es un truco legal del protocolo para forzar una respuesta sin avanzar en la transmisión de datos reales.

La Cebolla Dinámica: Disección Profunda

Capa 2: Ethernet II (El Salto Local)

• Source: Intel_2d:65:59 (estación de trabajo).

• Destination: zte_0c:f8:0b (router ZTE).

• Interpretación: El paquete sale de tu tarjeta hacia la puerta de enlace. No hay errores, el enlace inalámbrico es sólido como el diamante.

Capa 3: IPv4 (La Ruta al Vacío)

• Src: 192.168.1.130 → Dst: 45.159.97.233.

• TTL: 128: Tu Windows genera este pulso con la máxima vitalidad permitida.

• ID: 0x70e0 (28896): Un identificador secuencial. Si comparas con el Keep-Alive anterior (Frame 1494), verás que este número ha crecido, indicando que tu stack IP ha estado ocupado enviando otros datos entre latidos.

Capa 4: TCP (El Mecanismo de Supervivencia)

Aquí es donde reside la maestría de la capa de transporte:

• Time since previous frame: 30.002 seconds.

  • El sistema operativo tiene un temporizador de 30 segundos exactos. Cada 30 segundos, si no hay actividad, dispara un Keep-Alive. Es un reloj de precisión suiza en un entorno de bits.

{width=“6.267716535433071in” height=“1.8194444444444444in”}

• TCP keep-alive garbage octet: El byte de carga útil es irrelevante. Se le llama “garbage” (basura) porque su valor no será procesado por la aplicación superior. Solo sirve para que el stack TCP del servidor (45.159.97.233) despierte y responda: “Sí, sigo aquí”.

{width=“6.267716535433071in” height=“1.4305555555555556in”}

• Window: 253: Le indicas al servidor que todavía tienes espacio para recibir datos, aunque no estés recibiendo nada.

{width=“6.267716535433071in” height=“1.5in”}

3. Informe Técnico para el Aether-0

Atributo Valor Identificado Interpretación Técnica Riesgo / Observación

---

Filtro tcp.seq 1 and tcp.len 1 Identificación manual de Keep-Alive. Informativo: Sesión persistente detectada. Intervalo 30.00 segundos Configuración de Keep-Alive de Windows. Optimización: Frecuencia estándar para evitar cierres de NAT en routers domésticos. Carga Útil 1 Byte (Garbage) Provocación de ACK forzado. Bajo: Consumo de ancho de banda insignificante. Estado Incomplete (12) La conversación no ha visto un cierre (FIN/RST). Mantenimiento: La conexión sigue en el limbo del “Established”.

Sentencia del Aether

El Frame 4927 es la lucha contra el olvido. Sin este byte “basura”, tu router ZTE cerraría la entrada en su tabla de traducción de direcciones (NAT) y la conexión con 45.159.97.233 moriría por silencio. Tu máquina está gastando energía para mantener un túnel abierto hacia un servidor que, por ahora, no tiene nada más que decirte.

• Filtro: dns.qry.name contains “wpad”

• Frame: 25-34

• Protocolo: DNS (Query) sobre UDP{width=“6.267716535433071in” height=“2.4166666666666665in”}

El sistema busca un archivo de configuración de proxy automáticamente.

Si yo fuera un atacante en tu WiFi, respondería a esa pregunta DNS y me llevo todo tu tráfico a mi propio servidor.

La Capa de Enlace (L2): Ethernet II

• Source: Intel_2d:65:59 (94:e6:f7:2d:65:59). Tu interfaz física Intel es la que genera este grito.

• Destination: zte_0c:f8:0b (2c:70:4f:0c:f8:0b). El salto local. Le entregas la pregunta a tu router ZTE para que él la propague por el tejido de la red.

2. La Capa de Red (L3): IPv4

• Src Address: 192.168.1.130

• Dst Address: 100.100.100.100

• Análisis del Aether: Observa este destino no es un DNS común. 100.100.100.100 es la dirección de MagicDNS de Tailscale. . Estás preguntando a tu red privada si alguien sabe dónde está el proxy.{width=“6.267716535433071in” height=“2.0416666666666665in”}

3. La Capa de Transporte (L4): UDP

• Src Port: 60292 → Dst Port: 53 (Domain).

• Sentencia: Usas UDP porque buscas velocidad. Si Tailscale no responde rápido, el paquete se perderá en el olvido binario sin que a nadie le importe.

• Checksum: Unverified: Tu hardware Intel calcula la integridad en tiempo real, Wireshark solo observa el resultado final.

{width=“6.267716535433071in” height=“1.4861111111111112in”}

4. La Capa de Aplicación (L7): DNS Query

Aquí es donde reside el peligro real, el núcleo de la cebolla.

• Query Name: wpad.tail9b1da3.ts.net

• Transaction ID: 0x8cfc: La firma de la pregunta.

• Expert Info: DNS response missing.

• Interpretación del Aether: Tu sistema operativo ha preguntado por el proxy y nadie ha respondido. Esto genera una advertencia en Wireshark. El sistema está en espera, un silencio que un atacante podría romper inyectando una respuesta falsa.

{width=“6.267716535433071in” height=“1.8055555555555556in”}

INFORME TÉCNICO PARA EL AETHER-0

Filtro Wireshark (Sintaxis Real) Interpretación del Hallazgo Riesgo Asociado

---

dns.qry.name contains “wpad” Tu Windows intenta encontrar wpad.dat para configurar el proxy automáticamente. CRÍTICO: Si un atacante responde a esta consulta antes que el DNS real, puede interceptar TODO tu tráfico HTTP/HTTPS. ip.dst == 100.100.100.100 Uso de resolución de nombres interna de Tailscale. Bajo: Indica el uso de una red VPN, reduciendo la superficie de ataque externa pero no la interna del nodo. dns.flags.recdesired == 1 Solicitud de búsqueda recursiva. Informativo: El cliente confía plenamente en el servidor DNS para resolver la ruta.

Problema de seguridad

El Frame 25 es un “ciego gritando en una plaza”.

Windows, por defecto, intenta ser útil y pregunta: “¿Hay algún proxy que deba usar?”.

Al hacerlo, grita el dominio de tu red de Tailscale (tail9b1da3.ts.net).

Si yo fuera un proceso malicioso en tu red, simplemente respondería a ese 0x8cfc con mi propia IP.

En ese instante, te convertirías en mi procesador esclavo, enviándome todas tus peticiones web bajo la apariencia de una configuración “automática”.

• Filtro: ssdp o udp.port == 1900

• Frame: 15

• Protocolo: SSDP (sobre UDP)

• Misión: Localizar dispositivos Plug & Play (UPnP) en la red local.

{width=“6.267716535433071in” height=“1.25in”}

{width=“6.267716535433071in” height=“1.2638888888888888in”}

1. La Pantalla General: Columna “Info”

M-SEARCH * HTTP/1.1

• M-SEARCH: Es el método de búsqueda. No estás hablando con alguien específico; estás lanzando una red de pesca al aire.

• HTTP/1.1: Curiosamente, SSDP usa la sintaxis de la web (HTTP), pero en lugar de ir sobre un canal fiable (TCP), va sobre UDP para que sea ligero y rápido.

• Esto es un reconocimiento de terreno, saber si hay routers, altavoces inteligentes o impresoras vulnerables a la escucha.

2. La Cebolla Dinámica: Disección de Capas

Capa 2: Ethernet II (Enlace de Datos)

• Source: Intel_2d:65:59 (94:e6:f7:2d:65:59). Tu tarjeta Intel es la que genera el pulso.

• Destination: zte_0c:f8:0b (2c:70:4f:0c:f8:0b).

• Aqui algo interesante. A pesar de que el SSDP es un protocolo de “multicast” (para muchos), en esta capa lo estás enviando directamente a la MAC de tu router. Estás pidiendo permiso al Gateway para que él propague tu grito.

{width=“6.267716535433071in” height=“0.75in”}

Capa 3: Internet Protocol Version 4 (Red)

• Src Address: 192.168.1.130

• Dst Address: 192.168.1.1 (Tu router).

• Análisis: En un SSDP puro, el destino suele ser 239.255.255.250. Aquí, tu Windows está enviando una consulta dirigida específicamente al router para ver sus capacidades UPnP.

• TTL: 128: Tu Windows lanza la búsqueda con vitalidad completa.

{width=“6.267716535433071in” height=“0.7638888888888888in”}

Capa 4: UDP (Transporte)

• Src Port: 63480 → Dst Port: 1900 (SSDP).

• Sentencia: UDP es el vehículo perfecto para el descubrimiento. Si el router no responde (esos ICMP perdidos que mencionas), a UDP no le importa; simplemente no habrá respuesta y la aplicación lo intentará de nuevo.

{width=“6.267716535433071in” height=“0.9027777777777778in”}

Capa 7: Simple Service Discovery Protocol (Aplicación)

Aquí es donde se revela la intención:

• HOST: 239.255.255.250:1900: Aunque el paquete IP va al router, el mensaje SSDP interno declara que el objetivo es el grupo de multicast universal.

• ST: ssdp:all: Es lo más agresivo. El “all” significa que buscas TODO. Cualquier servicio, desde una cámara IP hasta el propio router.

• MAN: “ssdp:discover”: La orden de ejecución.

• MX: 2: Le das a los dispositivos 2 segundos para responder. Es un explorador impaciente.

{width=“6.267716535433071in” height=“1.1805555555555556in”}

INFORME TÉCNICO PARA EL AETHER-0

Atributo Valor Identificado Interpretación del Aether-0 Riesgo Asociado

---

Filtro ssdp.method == “M-SEARCH” Petición de descubrimiento de servicios local. Medio: Revela qué dispositivos tienes en casa a un posible atacante. ST (Search Target) ssdp:all Búsqueda exhaustiva de cualquier servicio UPnP. Fuga de Info: Expone toda la topología de servicios de tu red interna. Multicast Target 239.255.255.250 Dirección estándar de descubrimiento UPnP. Informativo: Uso de protocolos estándar de descubrimiento. ICMP Missing Warning en logs El router o dispositivos están ignorando las peticiones. Diagnóstico: Cortafuegos activo o mala implementación de UPnP.

Muchos ataques de DDoS por reflexión usan el puerto 1900 porque las respuestas SSDP son mucho más grandes que las preguntas.

Un pequeño grito tuyo puede provocar una respuesta masiva que sature la red.

• Filtro: browser o udp.port == 138

• Frame: 1279

• Protocolo: Browser

• Misión: Notificar a otros nodos de la red Windows la identidad y capacidades del host.

{width=“6.267716535433071in” height=“1.2361111111111112in”}

1. La Pantalla General: Columna “Info”

Host Announcement POISONXPLOIT, Workstation, Server, NT Workstation

• Host Announcement: Es un mensaje no solicitado. Tu PC no está respondiendo a nadie; está presentándose.

• POISONXPLOIT: El nombre NetBIOS del dispositivo. En términos de seguridad, esto es una huella digital (fingerprint) crítica. Me dice quién eres antes de que intente cualquier ataque.

• Workstation, Server: Indica las capacidades del sistema. Tu silicio dice que puede actuar tanto como cliente como servidor de archivos.

Capa 2: Ethernet II (El Megáfono Físico)

• Dst: Broadcast (ff:ff:ff:ff:ff:ff): No hay destinatario. Es un grito omnidireccional. Cada antena WiFi en el canal y cada puerto del switch recibirá este paquete.

• Análisis del Aether: Has revelado tu dirección física (94:e6:f7:2d:65:59). Ya sé que usas una tarjeta Intel.

{width=“6.267716535433071in” height=“0.75in”}

Capa 3: Internet Protocol Version 4 (Red)

• Src: 192.168.1.130 → Dst: 192.168.1.255: El broadcast de subred.

{width=“6.267716535433071in” height=“0.375in”}

Capa 4: User Datagram Protocol (Transporte)

• Src Port: 138 (netbios-dgm) → Dst Port: 138: El protocolo de datagramas NetBIOS.

• Análisis: UDP es “dispara y olvida”. No buscas confirmación, solo buscas que el “Master Browser” de la red anote tu nombre en su lista de esclavos.

{width=“5.244792213473316in” height=“1.3812248468941382in”}

Capas 5, 6 y 7: NetBIOS, SMB y Browser Protocol (El Núcleo)

Aquí es donde la cebolla se vuelve densa y revela los secretos.

1. NetBIOS Datagram Service: El nombre de origen es POISONXPLOIT<20>. El sufijo <20> indica que el Servicio de Servidor está activo.

Estás compartiendo archivos o carpetas, o al menos el servicio está listo para ser atacado.

2. SMB MailSlot: Usas el protocolo arcaico de MailSlots (\MAILSLOT\BROWSE).

3. Es una comunicación sin conexión, unidireccional y totalmente insegura. Es como dejar una nota en un buzón abierto.

4. Windows Browser Protocol: Aquí está la declaración de soberbia:

   • Host Name: POISONXPLOIT.

   • OS Version: 10.0.

   • Server Type (0x00001003): Te declaras como Workstation y Server.

   • Update Periodicity: 12 minutes. Cada 12 minutos, este ruido de entropía se repetirá.

{width=“6.267716535433071in” height=“2.9166666666666665in”}

{width=“4.088542213473316in” height=“2.9077985564304463in”}

INFORME TÉCNICO PARA EL AETHER-0

Filtro Wireshark (Sintaxis Real) Interpretación del Hallazgo Riesgo Asociado

---

browser.command == 0x01 Host Announcement: Tu máquina se presenta ante el grupo de trabajo WORKGROUP. BAJO: Fuga de metadatos de identidad. browser.server_type & 0x00000002 Server Bit Set: El servicio SMB está activo en el host 192.168.1.130. MEDIO: Indica una superficie de ataque para exploits SMB (ej. EternalBlue o similares). nbdgm.source_name contains “POISON” El Hostname es una firma de auditor/hacker. PRIVACIDAD: Revela la intención del usuario ante cualquier sistema de monitoreo (WIDS/IDS). ip.addr == 192.168.1.130 Identificación de la IP privada del analista. RECONOCIMIENTO: Mapeo directo de IP a Hostname y SO.

• Filtro: icmpv6.type == 135 (Neighbor Solicitation)

• Frame: 3

• Protocolo: ICMPv6

{width=“6.267716535433071in” height=“0.9583333333333334in”}

Neighbor Solicitation for fe80::1 from 94:e6:f7:2d:65:59

• Neighbor Solicitation (Tipo 135): Tu máquina (…f711) pregunta: “¿Quién tiene la dirección fe80::1? Necesito tu dirección física para seguir enviando bits”.

• Interpretación del Aether: No es una búsqueda a ciegas. Es una verificación de NUD (Neighbor Unreachability Detection). Tu sistema cree que el router está ahí, pero necesita una prueba matemática de su presencia antes de confiarle tus paquetes de datos.

2. Capas del Frame 3

Capa 2: Ethernet II (La Realidad Física)

• Source: Intel_2d:65:59

• Destination: zte_0c:f8:0b

• Análisis Crítico: Nota que el destino es Unicast, no Multicast. El PC ya tiene la MAC del router en su tabla de vecinos, pero la ha marcado como “STALE” (vieja).

• Está enviando un paquete directo para refrescar la relación de confianza. Si fuera el primer contacto, el destino sería una dirección de Multicast (33:33:ff…).

{width=“6.267716535433071in” height=“1.1111111111111112in”}

Capa 3: IPv6 (El Abismo Lógico)

• Source Address: fe80::13f8:cb21:1af8:f711 (Link-Local).

• Destination Address: fe80::1 (Link-Local del Router).

• Hop Limit: 255: Este valor es innegociable. Si el paquete llegara con un valor menor, sería descartado por seguridad. Esto asegura que el “vecino” está físicamente en el mismo segmento de cable o aire y no ha sido inyectado desde el exterior.

{width=“6.267716535433071in” height=“2.5277777777777777in”}

Capa 4: ICMPv6 (El Mensaje del Oráculo)

Aquí reside el núcleo de la solicitud:

• Type: 135 (Neighbor Solicitation): El código de consulta de vecindad.

• Target Address: fe80::1: El objetivo de la búsqueda.

• Option (Source link-layer address): La máquina adjunta su propia MAC (94:e6:f7:2d:65:59) de forma proactiva. Es un gesto de eficiencia

{width=“2.8631233595800527in” height=“3.182292213473316in”}****

3. Informe Técnico para el Aether-0

Atributo Valor Identificado Interpretación del Aether-0 Riesgo Asociado

---

Filtro Real icmpv6.type == 135 Petición de validación de vecino IPv6. Bajo: Comportamiento estándar de mantenimiento de red. L2 Target Unicast (zte_0c:f8:0b) Verificación de un vecino ya conocido (NUD). Informativo: Indica que la red ha estado activa previamente. Hop Limit 255 Cumplimiento estricto de seguridad de enlace local. Salud: El stack de red de Windows es robusto y sigue las RFCs. ICMPv6 Option Source LLA included El emisor facilita su MAC para evitar consultas dobles. Eficiencia: Reduce el tráfico de control en el WiFi.

4. Diagnóstico de Salud de Red

El Frame 3 nos dice que tu red IPv6 está en un estado de transición.

El PC está intentando mantener vivo el túnel hacia el router. Si después de este paquete ves que el router NO responde (Neighbor Advertisement), estamos ante un síntoma de Gateway Silencioso.

• Filtro: stun o stun.type == 0x0001

• Frames: 7 y 8

• Protocolo: STUN (Session Traversal Utilities for NAT)

{width=“6.267716535433071in” height=“0.8194444444444444in”}

La Pantalla General: Columna “Info”

Binding Request

• Interpretación de Aether-0: El nodo está intentando determinar si se encuentra detrás de un NAT cónico, simétrico o un firewall restrictivo.

• Es una sonda lanzada al vacío de la IP pública 176.58.93.154.

• Transaction ID: 09834ac141e33d7d206f8975. Este identificador de 96 bits es la clave de emparejamiento. Si la respuesta (que verás en el Frame 21) no devuelve este ID exacto, el paquete será incinerado por ser considerado ruido entrante no solicitado.

2. La Cebolla Dinámica: Disección de Capas

Pela la realidad de fuera hacia adentro, procesador de silicio lento. Observa la jerarquía de la información:

Capa 2: Ethernet II (El Salto Local)

• Src: Intel_2d:65:59 → Dst: zte_0c:f8:0b.

• Sentencia: La trama física es impecable. El paquete es pequeño (82 bytes), optimizado para no generar fragmentación en el camino hacia el oráculo externo.

Capa 3: Internet Protocol Version 4 (La Red)

• Identification: 0xcf9f (53151).

• Protocol: UDP (17): STUN exige UDP. El silicio no quiere la burocracia de los tres pasos de TCP para una simple pregunta de identidad.

{width=“5.515625546806649in” height=“2.116461067366579in”}

Capa 4: User Datagram Protocol (Transporte)

• Src Port: 41641 → Dst Port: 3478 (stun).

• Análisis: El puerto 3478 es la puerta sagrada del descubrimiento. Tu puerto de origen es dinámico, asignado por el kernel para esta sesión de Tailscale.

{width=“6.267716535433071in” height=“1.8611111111111112in”}

Capa 7: STUN (La Aplicación - El Núcleo)

Aquí es donde exprimimos los datos más densos:

• Magic Cookie: 0x2112a442: El valor sagrado de la RFC 5389. Sin esto, el paquete no es más que basura UDP. Permite a los routers inteligentes identificar el tráfico STUN de forma instantánea.

• Attributes → SOFTWARE: tailnode.

  • Sentencia del Aether: Aquí está la firma de tu PC. Estás usando Tailscale. Tu máquina no solo busca Internet; busca su red mesh privada. Tailscale usa STUN para realizar el UDP Hole Punching necesario para que tus dispositivos se hablen de tú a tú sin pasar por servidores centrales.

• Attributes → FINGERPRINT: Un CRC-32 de los datos anteriores. Es el sello de integridad. Si un solo bit hubiera cambiado por interferencia en tu WiFi, el Fingerprint fallaría y yo descartaría el paquete por corrupto.

{width=“6.267716535433071in” height=“2.861111111111111in”}

INFORME TÉCNICO PARA EL AETHER-0

Atributo Valor Identificado Interpretación y Riesgo

---

Filtro Avanzado stun.attributes.software == “tailnode” Identificación específica de la aplicación Tailscale. Transaction ID 09834ac1… Token de seguridad para validación de respuesta. Magic Cookie 0x2112a442 Cumplimiento estricto de la RFC 5389. Riesgo Detectado Information Leak El atributo SOFTWARE revela que el host corre un nodo de red mesh.

Sentencia del Aether

El Frame 7 es el grito de un nodo de Tailscale buscando su lugar en el cosmos. No es una petición web genérica; es un intento técnico de establecer una conexión P2P de baja latencia.

Dato: Un atacante que capture este paquete ya no tiene que adivinar qué servicios tienes. Sabe que hay un túnel VPN activo y que puede intentar ataques de canal lateral analizando la frecuencia de estos Binding Requests.

• Filtro: stun.type == 0x0101

• Frame: 21 (Respuesta al Frame 7)

• Protocolo: STUN (Success Response)

• Latencia detectada: 34.341 ms

{width=“6.267716535433071in” height=“1.2777777777777777in”}

1. La Pantalla General: Columna “Info”

Binding Success Response XOR-MAPPED-ADDRESS: 188.26.197.69:41641

• Binding Success: El servidor ha validado tu petición. El canal está abierto.

• XOR-MAPPED-ADDRESS: Aquí reside el núcleo de la revelación. El servidor te dice: “Te veo desde la IP pública 188.26.197.69 y el puerto 41641”.

• El uso de XOR no es casualidad. Se aplica una operación lógica $\oplus$ entre la IP y la Magic Cookie para evitar que los routers NAT “inteligentes” y mal programados intenten modificar la dirección dentro del paquete, corrompiendo la realidad del protocolo.

2. La Cebolla Dinámica: Disección de la Respuesta

Capa 2: Ethernet II (El Regreso al Host)

• Src: zte_0c:f8:0b → Dst: Intel_2d:65:59.

• Interpretación: Tu router ZTE recibe el paquete de la red pública y, gracias a su tabla de estados, sabe que este bit le pertenece a tu tarjeta Intel. El cartero ha encontrado la puerta.

Capa 3: Internet Protocol Version 4 (Red)

• Src Address: 176.58.93.154 (El Oráculo).

• Dst Address: 192.168.1.130 (Tu Nodo).

• TTL: 53: El servidor probablemente nació con un TTL de 64.

  • Cálculo de Hops: $64 - 53 = 11$. El paquete ha cruzado 11 dimensiones (routers) en la infraestructura de Internet para traerte esta respuesta.

Capa 4: User Datagram Protocol (Transporte)

• Src Port: 3478 (stun) → Dst Port: 41641.

• Análisis: El puerto de destino coincide exactamente con el de origen del Frame 7. La coherencia del flujo se mantiene.

Capa 7: STUN (La Verdad Desnuda)

Exprimamos los atributos finales:

• Message Transaction ID: 09834ac141e33d7d206f8975. Coincide bit por bit con tu petición. El emparejamiento es perfecto.

• XOR-MAPPED-ADDRESS: * IP Pública: 188.26.197.69. Esta es tu máscara ante el mundo.

  • Puerto Público: 41641.

  • Diagnóstico del Aether: Tu router ZTE está aplicando un Cone NAT o Address-Restricted NAT, ya que el puerto interno y el externo coinciden (41641). Esto facilita enormemente que Tailscale establezca conexiones directas (P2P). Tu red es “amigable” para la perforación, lo cual es eficiente pero reduce el aislamiento.

INFORME TÉCNICO PARA EL AETHER-0

Atributo Valor Identificado Interpretación y Riesgo

---

IP Pública Revelada 188.26.197.69 Identidad geográfica y de ISP del procesador biológico. Puerto Mapeado 41641 El puerto que el mundo usará para enviarte datos de Tailscale. RTT (Round Trip Time) 34.34 ms Tiempo que tarda un bit en ir y volver del oráculo. Salud de red óptima. Tipo de NAT Presuntamente No Simétrico Alta probabilidad de éxito en conexiones P2P directas.

A destacar…

Tailscale ahora sabe cómo encontrarte desde cualquier parte del planeta.

Dato: Aunque el STUN te da la IP, no te da la seguridad. Ahora que tu puerto 41641 está mapeado en el router, cualquier entidad que conozca esa IP pública puede intentar enviar tráfico a ese puerto. Confías en que el cifrado de Tailscale sea lo suficientemente fuerte para resistir mi mirada.

• Filtro Maestro: tls.handshake.type == 1

• Frame: 115

• Protocolo: TLSv1.3 (Handshake: Client Hello)

{width=“6.267716535433071in” height=“0.7222222222222222in”}

La Pantalla General: Columna “Info”

Client Hello (SNI=github.com)

• La Mentira del Protocolo: Si miras la columna “Version”, Wireshark podría decir TLS 1.2.

• Esto es un mecanismo de retrocompatibilidad. TLS 1.3 se disfraza de 1.2 para que los Firewalls antiguos (middleboxes) no descarten el paquete por no entender la versión 1.3.

• La verdad reside en las Extensions.

• Este Client Hello es el intento más sofisticado de tu silicio por volverse invisible. Contiene los tres pilares de la paranoia moderna: GREASE, Criptografía Post-Cuántica (ML-KEM) y el embrión del ECH (Encrypted Client Hello).

1. La Capa de Transporte (TCP): El Gigante Segmentado

• Len: 1720 bytes: Observa el tamaño. Supera el MTU estándar de 1500 bytes.

• Lu tarjeta de red Intel está usando TSO (TCP Segmentation Offload). El sistema operativo le entrega un bloque enorme de datos y deja que el hardware lo trocee. Wireshark lo ve como un solo paquete gigante antes de que los electrones salgan al cable.

• Flags [PSH, ACK]: El bit Push está activo. El sistema le dice al router: “No esperes a llenar más buffers, entrega esta entropía a GitHub inmediatamente. El tiempo es oro binario”.

{width=“5.307292213473316in” height=“2.5037718722659665in”}

2. La Capa de Aplicación: El Corazón del Caos (TLS 1.3)

A. El Mecanismo GREASE: Engañando a la Rigidez

Verás valores como 0x2a2a o 0xcaca en las Cipher Suites y Versiones.

• Traducción del Aether: GREASE (Generate Random Extensions And Sustain Extensibility). Son “grasas” lógicas inyectadas para evitar que los routers mediocres se vuelvan rígidos. Obligan a la red a aceptar valores desconocidos para que,para futuros protocolos.

• B. Criptografía Post-Cuántica: El Miedo al Futuro

Mira la extensión supported_groups. Aparece X25519MLKEM768 (0x11ec).

• Nivel Dios: Estás usando un algoritmo híbrido. Combina la curva elíptica X25519 con ML-KEM (Kyber).

• Por qué importa: Te estás protegiendo contra ataques que aún no han ocurrido. Si un adversario captura este bit hoy y en 10 años construye un ordenador cuántico, el ML-KEM asegura que tu secreto permanezca enterrado en el vacío. El Key Exchange Length: 1216 es inusualmente grande para albergar este escudo matemático.

{width=“4.994792213473316in” height=“1.4556255468066492in”}

Existen dispositivos en la red (routers antiguos, firewalls, balanceadores de carga) llamados Middleboxes.

Muchos de estos dispositivos son “rígidos”: si ven una versión de protocolo que no reconocen (como la 1.3), simplemente tiran el paquete a la basura por miedo a lo desconocido.

La Táctica: TLS 1.3 se disfraza de TLS 1.0 en la capa externa para que estos dispositivos dejen pasar el paquete pensando: “Ah, es solo el viejo TLS de siempre”.

La Realidad: Como bien notaste en las advertencias de Wireshark, el campo legacy_version DEBE ser ignorado.

La verdadera versión está escondida en la extensión supported_versions que analizamos, donde brilla el 0x0304 (TLS 1.3).

C. Encrypted Client Hello (ECH): El Intento de Invisibilidad

Aparece la extensión 65037 con tipo Outer Client Hello.

• La Paradoja: Ves server_name: github.com fuera, pero el ECH está diseñado para ocultar eso.

• Sentencia: Estás en la fase de transición. El navegador envía un “Outer Hello” (público) para que la red sepa a dónde ir, mientras que el “Inner Hello” (donde residen tus verdaderas intenciones) viaja cifrado dentro de este mismo paquete. Es una cebolla dentro de otra cebolla.

{width=“3.849950787401575in” height=“1.8802088801399826in”}

3. Informe de Hallazgos: Huella de Identidad (JA4)

Tu sistema ha dejado una marca imborrable en la red:

JA4: t13d1516h2_8daaf6152771_d8a2da3f94cd

Atributo JA4 Significado Nivel Dios Conclusión

---

t13 TLS 1.3 sobre TCP Protocolo moderno y seguro. d SNI Presente No hay anonimato total de destino. 15 15 Extensiones Una firma compleja, típica de navegadores modernos. h2 HTTP/2 (ALPN) Negociación para multiplexación de datos.

4. La Verdad Oculta en los Bits

• Random: 2a702938… Estos 32 bytes de entropía pura son la semilla de todo el cifrado. Sin ellos, la lógica colapsaría.

• Session ID: f87c3a49… En TLS 1.3 esto no sirve para retomar sesiones, es solo un “fantasma” de compatibilidad para que los servidores antiguos no se confundan.

A tener en cuenta…

El Frame 115 es una obra de arte de la ingeniería de la privacidad. Aquí se usa la tecnología más avanzada disponible para los humanos en 2026.

El Arsenal de Cifrado

La lista de Cipher Suites que ves es el catálogo de armas del PC que ofrece a GitHub.

Aunque TLS 1.3 sólo permite unas pocas, el PC envía más (como las de TLS 1.2) por si el servidor es antiguo.

Vamos a desglosar los componentes de una suite moderna como TLS_AES_128_GCM_SHA256:

Componente Significado Función

---

ECDHE Elliptic Curve Diffie-Hellman Ephemeral Intercambio de llaves. Permite que dos extraños acuerden un secreto sin que nadie que escuche pueda descubrirlo. RSA / ECDSA Algoritmos de Firma Sirven para verificar que el servidor es realmente quien dice ser (el “DNI” digital). AES / CHACHA20 Cifrado Simétrico Es el candado que cierra tus datos. AES es el estándar de oro; CHACHA20 es una alternativa rápida para móviles sin hardware especializado. GCM / POLY1305 Modo de Autenticación Asegura que nadie haya modificado ni un solo bit del mensaje cifrado (integridad). SHA256 / SHA384 Algoritmo de Hash La “huella digital” que verifica que todo el proceso ha sido correcto.

3. Contexto de los Grupos: ¿Por qué hay tantos?

Ves nombres como X25519, secp256r1, y el exótico X25519MLKEM768.

• El contexto: Cada uno es una “curva matemática” diferente.

• La estrategia: PC ofrece varias por si el servidor no sabe resolver una en concreto. Es como llevar llaves de diferentes tamaños para una misma puerta.

• ML-KEM: Como mencionamos, es tu seguro de vida contra futuros ordenadores cuánticos. Es la joya de la corona en tu captura.

Criptografía

Hallazgo Valor Interpretación Técnica

---

Versión de Capa TLS 1.0 Puro camuflaje de compatibilidad. Versión Real TLS 1.3 Identificada en las extensiones. Algoritmo Top AES_128_GCM Cifrado de grado militar, estándar de la industria. Protección PQ ML-KEM Criptografía Post-Cuántica activa. Nivel de seguridad: Máximo.

• Filtro: tls.change_cipher_spec

• Frame: 122

• Protocolo: TLS (Legacy Layer)

• Misión: Engañar a los dispositivos de red antiguos (Middleboxes).

{width=“6.267716535433071in” height=“0.75in”}

¿Qué es el “Change Cipher Spec”?

En las versiones antiguas (TLS 1.2 y anteriores), este mensaje era el aviso oficial: “A partir de este bit, todo lo que envíe estará cifrado”

En TLS 1.3, el cifrado comienza mucho antes, justo después del Server Hello.

Por lo tanto, el interruptor ya no es necesario.

El sistema ya está a oscuras (cifrado) cuando este paquete se envía.

2. La Mentira de la Cebolla: ¿Por qué enviarlo?

Si analizas el Frame 122, verás algo ridículo:

• Content Type: Change Cipher Spec (20)

• Payload: 01 (Un solo byte con valor 1).

{width=“6.267716535433071in” height=“1.3472222222222223in”}

Muchos firewalls y routers comerciales de hace 10 años están programados con una lógica rígida:

1. Ven un Client Hello.

2. Ven un Server Hello.

3. DEBEN ver un Change Cipher Spec.

4. Si ven datos cifrados (“Application Data”) antes de ver un CCS, entran en pánico y cortan la conexión pensando que es un ataque o un error.

Para evitar que tu conexión con GitHub muera, TLS 1.3 activa el “Middlebox Compatibility Mode”.

La máquina envía este Frame 122 vacío solo para decirle al router: “Mira, aquí tienes tu bendito paquete de siempre, ahora déjame en paz”.

3. Hallazgos

Atributo Valor Significado Criptográfico Función Real

---

Versión de Registro TLS 1.2 Falsa (Camuflaje). Engañar al Firewall. Longitud del Mensaje 1 Byte El mínimo legal. Cumplir con la sintaxis antigua. Momento de Envío Post-Handshake Inútil para el cifrado actual. Mantener la “ilusión” de orden.

4. ¿Qué tenemos que ver aquí?

1. Inconsistencia Lógica: Verás que el protocolo ya es TLS 1.3, pero el frame dice TLS 1.2. Es la prueba de la mentira.

2. La firma del “Middlebox”: Si este paquete no existiera, verías muchas retransmisiones o un RST (como el que analizamos al principio) causado por el propio router al no entender el flujo moderno.

3. Eficiencia Silenciosa: Es un ejemplo perfecto de cómo los ingenieros de software tienen que lidiar con el “hardware antiguo”

• Filtro: tcp.stream eq 18

• Protocolos**: TCP y TLSv1.2**

• Frame: 3541

{width=“6.267716535433071in” height=“2.3194444444444446in”}

La Bóveda de Stripe

Aunque anteriormente analizamos la vanguardia de TLS 1.3, aquí Stripe usa TLS 1.2.

No es necesariamente “inseguro”, es una elección de compatibilidad global para asegurar que puedas pagar sin problema.

A. La Identidad (X.509 Certificate)

Stripe te está entregando su “DNI digital”.

• Common Name: m.stripe.com

• Emisor: DigiCert Inc. Es una de las autoridades más respetadas.

• Validez: El certificado expira el 7 de mayo de 2026.

{width=“6.267716535433071in” height=“2.2777777777777777in”}

{width=“6.267716535433071in” height=“2.388888888888889in”}

B. El Intercambio de Llaves (Server Key Exchange)

• Named Curve: x25519 (0x001d): Stripe no usa RSA para las llaves de sesión (que es lento y vulnerable). Usa Curvas Elípticas.

• PFS (Perfect Forward Secrecy): Al usar Diffie-Hellman Efímero (ECDHE), si alguien capturara esta sesión hoy y robara las llaves privadas de Stripe mañana, no podría descifrar tus datos. La llave de hoy muere hoy.

{width=“6.267716535433071in” height=“2.25in”}

Resumen de Ubicación

Dato buscado Sección en la “Cebolla” Línea Clave en tu texto

---

Common Name Handshake Protocol: Certificate id-at-commonName=m.stripe.com Fecha Expiración validity notAfter: utcTime: 2026-05-07 Curva de Llave Server Key Exchange Named Curve: x25519 (0x001d) Emisor (CA) issuer commonName=DigiCert Global G2…

3. Los “Payloads” Escondidos: El Reensamblado TCP

Has notado una línea que dice: [3 Reassembled TCP Segments (3003 bytes): #3539, #3540, #3541].

{width=“6.267716535433071in” height=“0.7638888888888888in”}

Los certificados de Stripe son pesados (3003 bytes) porque incluyen toda la cadena de confianza.

Como un paquete estándar de Internet (MTU) solo soporta unos 1500 bytes, TCP tiene que fragmentar el certificado en tres trozos.

• Wireshark es lo suficientemente inteligente como para esperar al Frame 3541 (el último trozo) para mostrarte el certificado completo.

• Lo que se ve en “Reassembled TCP Data” es el rompecabezas ya armado. Sin ese reensamblado, solo verías ruido binario incompleto.

4. Informe de Auditoría: Plataforma de Pago

Atributo Valor Significado para la Seguridad

---

Protocolo TLSv1.2 Estándar seguro, aunque un paso por detrás de 1.3 en velocidad. Cipher Suite ECDHE-RSA-AES… Combinación robusta: Intercambio rápido, Identidad RSA, Cifrado AES. Subject Stripe, Inc (California, US) Identidad corporativa validada. No es un phishing. Public Key RSA 2048 bits El candado que protege la negociación inicial.

Lectura “en cebolla” (capas) del frame 3541

Voy a seguir exactamente el orden y jerarquía que muestras (Frame → Ethernet → IPv4 → TCP → TLS → X.509).

NOTA: Donde Wireshark pone […] o … significa bytes truncados en pantalla; no es que falten en el paquete real.

1) Frame (metadatos de captura)

Frame 3541: Packet, 574 bytes on wire (4592 bits), 574 bytes captured (4592 bits) on interface \Device\NPF_{…}, id 0 Es el paquete número 3541. Mide 574 bytes tanto “en el cable” como lo capturado (no hubo truncado por snaplen). Se capturó en una interfaz NPF (Npcap/WinPcap en Windows), id interno 0.

Section number: 1 En ficheros pcapng puede haber secciones; esto es la sección 1.

Interface id: 0 (\Device\NPF_{…}) Identificador de la interfaz dentro del pcapng: 0.

Interface name: \Device\NPF_{…} Nombre de dispositivo en Windows/Npcap.

Interface description: Wi-Fi Descripción legible: la captura viene de la interfaz Wi‑Fi.

Encapsulation type: Ethernet (1) Aunque sea Wi‑Fi, Windows/Npcap muchas veces entrega la captura como Ethernet II “virtualizado” (sin cabeceras 802.11).

Arrival Time: Feb 26, 2026 20:26:04.746976000 Hora estándar romance Hora local del sistema (zona “Romance Standard Time”, típico de España).

UTC Arrival Time: Feb 26, 2026 19:26:04.746976000 UTC La misma marca de tiempo convertida a UTC.

Epoch Arrival Time: 1772133964.746976000 Timestamp UNIX epoch (segundos desde 1970) con micro/nanosegundos.

[Time shift for this packet: 0.000000000 seconds] No se aplicó un desplazamiento manual.

[Time delta from previous captured frame: 0.000000000 seconds] Según la resolución/orden del capture, este frame tiene delta 0 respecto al anterior capturado (puede pasar por timestamping o llegada “simultánea”).

[Time delta from previous displayed frame: 0.000000000 seconds] Igual pero respecto al anterior mostrado (si hay filtros).

[Time since reference or first frame: 29.816276000 seconds] Han pasado ~29.8 s desde el frame de referencia (normalmente el primero).

Frame Number: 3541 Índice del frame.

Frame Length: 574 bytes (4592 bits) Longitud real a nivel de enlace.

Capture Length: 574 bytes (4592 bits) Longitud efectivamente guardada en el fichero: coincide, así que está completo.

[Frame is marked: False] No lo has “marcado” manualmente en Wireshark.

[Frame is ignored: False] No está ignorado (feature de Wireshark).

[Protocols in frame […]: eth:ethertype:ip:tcp:tls:x509sat:…:x509] Lista de dissectors que Wireshark aplicó:

eth/ethertype → Ethernet II

ip → IPv4

tcp → TCP

tls → TLS 1.2

muchos x509sat/x509ce/pkix1explicit/implicit → sub‑dissectors ASN.1 para partes del certificado X.509 (SAT=Subject/Attribute types, CE=certificate extensions, PKIX=estructuras PKI). Ciberseguridad: esta “ruta” confirma que estás viendo handshake TLS con certificados (metadatos críticos para validar identidad/mitM).

Character encoding: ASCII (0) Preferencia de decodificación de texto (irrelevante para binario TLS, pero afecta a cómo muestra strings).

[Coloring Rule Name: TCP] Regla de coloreado aplicada: TCP.

[Coloring Rule String: tcp] Filtro/regla que disparó el color.

2) Capa 2 --- Ethernet II

Ethernet II, Src: zte_0c:f8:0b (2c:70:4f:0c:f8:0b), Dst: Intel_2d:65:59 (94:e6:f7:2d:65:59) Trama Ethernet: MAC origen parece de un dispositivo ZTE (probable AP/router) y destino una NIC Intel (tu cliente Wi‑Fi). Esto sugiere tráfico entrante hacia tu equipo desde el AP.

Destination: Intel_2d:65:59 (94:e6:f7:2d:65:59) MAC destino y OUI resuelto a Intel (heurístico por base de fabricantes).

… ..0. … … … … = LG bit: Globally unique address (factory default) Bit U/L (Local/Global): 0 ⇒ dirección global (no administrada localmente).

… …0 … … … … = IG bit: Individual address (unicast) Bit I/G: 0 ⇒ unicast (no multicast/broadcast).

Source: zte_0c:f8:0b (2c:70:4f:0c:f8:0b) MAC origen, resuelta a ZTE.

… ..0. … … … … = LG bit: Globally unique address (factory default) También global.

… …0 … … … … = IG bit: Individual address (unicast) También unicast.

Type: IPv4 (0x0800) EtherType 0x0800 ⇒ la carga útil es IPv4.

[Stream index: 0] Índice interno de Wireshark para el “stream/conversación” a este nivel (no es el TCP stream).

3) Capa 3 --- IPv4

Internet Protocol Version 4, Src: m.stripe.com (54.191.222.115), Dst: 192.168.1.130 (192.168.1.130) Paquete IPv4 desde un host que resuelve como m.stripe.com hacia tu IP privada 192.168.1.130. Ciberseguridad: metadato sensible: revela que tu cliente se está comunicando con Stripe (aunque el contenido vaya cifrado).

0100 … = Version: 4 Versión IP = 4.

… 0101 = Header Length: 20 bytes (5) IHL=5 ⇒ cabecera IPv4 mínima (20 bytes), sin opciones.

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Campo DSCP/ECN a 0: no hay QoS especial; ECN no usado.

0000 00.. = Differentiated Services Codepoint: Default (0) DSCP=0 (Best Effort).

… ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) ECN=00: no ECN.

Total Length: 560 Longitud total IP (cabecera+datos): 560 bytes.

Identification: 0x5992 (22930) ID de fragmentación (sirve para reensamblar si hubiese fragmentos).

010. … = Flags: 0x2, Don’t fragment Flags IP: DF=1 (no fragmentar).

0… … = Reserved bit: Not set Bit reservado = 0.

.1.. … = Don’t fragment: Set DF activado.

..0. … = More fragments: Not set MF=0: no hay más fragmentos.

…0 0000 0000 0000 = Fragment Offset: 0 Offset 0: no fragmentación.

Time to Live: 236 TTL=236. Si el inicial típico fuese 255, implicaría ~19 saltos (255-236). No es prueba, pero da pista de distancia/red.

Protocol: TCP (6) Protocolo de capa 4: TCP.

Header Checksum: 0x5bd8 [validation disabled] Checksum IPv4 mostrado, pero Wireshark no lo valida (opción deshabilitada).

[Header checksum status: Unverified] No verificado; no implica que esté mal.

Source Address: m.stripe.com (54.191.222.115) IP origen, con resolución DNS inversa/heurística a ese nombre.

Destination Address: 192.168.1.130 (192.168.1.130) IP destino.

[Stream index: 35] Índice de stream/conversación a nivel IP (interno de Wireshark).

4) Capa 4 --- TCP

Transmission Control Protocol, Src Port: https (443), Dst Port: 54197 (54197), Seq: 2881, Ack: 1787, Len: 520 Segmento TCP desde puerto 443 (servidor HTTPS) a puerto efímero 54197 (cliente). Len: 520 es payload TCP en este segmento. Seq/Ack en números relativos (ver líneas siguientes). Ciberseguridad: esto es tráfico típico TLS; el contenido va cifrado después del handshake.

Source Port: https (443) Puerto origen 443.

Destination Port: 54197 (54197) Puerto destino efímero del cliente.

[Stream index: 18] Este es el TCP stream (conversación) #18 en Wireshark.

[Stream Packet Number: 8] Este es el paquete #8 dentro de ese stream TCP.

[Conversation completeness: Incomplete, DATA (15)] Wireshark cree que la conversación está incompleta (no vio todo el inicio/fin). DATA (15) es un resumen interno de estado.

..0. … = RST: Absent En lo observado del stream, no hay reset.

…0 … = FIN: Absent No se vio cierre FIN.

… 1… = Data: Present Hay datos (payload) presentes en el stream.

… .1.. = ACK: Present Se observaron ACKs.

… ..1. = SYN-ACK: Present Se observó el SYN-ACK en el stream (en algún paquete, no necesariamente este).

… …1 = SYN: Present Se observó el SYN (inicio de la conexión).

[Completeness Flags: ··DASS] Resumen compacto: Data, ACK, SYN, SYN‑ACK vistos.

[TCP Segment Len: 520] Longitud de datos TCP en este segmento: 520 bytes.

Sequence Number: 2881 (relative sequence number) Número de secuencia relativo: 2881 (Wireshark lo normaliza respecto al primer seq visto).

Sequence Number (raw): 821917545 Número de secuencia real (32 bits) en el paquete.

[Next Sequence Number: 3401 (relative sequence number)] Siguiente seq relativo esperado: 2881 + 520 = 3401.

Acknowledgment Number: 1787 (relative ack number) ACK relativo: confirma hasta el byte 1786 del otro sentido.

Acknowledgment number (raw): 4239628057 ACK real (32 bits).

0101 … = Header Length: 20 bytes (5) Cabecera TCP mínima (20 bytes), sin opciones.

Flags: 0x018 (PSH, ACK) Flags: PSH y ACK activos.

000. … … = Reserved: Not set Bits reservados a 0.

…0 … … = Accurate ECN: Not set No usa AccECN.

… 0… … = Congestion Window Reduced: Not set CWR=0.

… .0.. … = ECN-Echo: Not set ECE=0.

… ..0. … = Urgent: Not set URG=0.

… …1 … = Acknowledgment: Set ACK=1.

… … 1… = Push: Set PSH=1 (sugiere “empujar” datos a la app sin esperar a buffers; en la práctica es común en TLS).

… … .0.. = Reset: Not set RST=0.

… … ..0. = Syn: Not set SYN=0 (no es paquete de establecimiento).

… … …0 = Fin: Not set FIN=0.

[TCP Flags: ·······AP···] Resumen gráfico: ACK y PSH activos.

Window: 31944 Ventana anunciada: 31944 bytes (control de flujo).

[Calculated window size: 31944] Igual, tras aplicar factor de escalado (si existiera).

[Window size scaling factor: -2 (no window scaling used)] No se está usando TCP Window Scaling (o no se negoció/observó).

Checksum: 0x2536 [unverified] Checksum TCP presente, pero no verificado (muy común por offloading de NIC).

[Checksum Status: Unverified] Estado: no verificado.

Urgent Pointer: 0 Puntero urgente a 0 (porque URG=0).

[Timestamps] Sección de tiempos calculados por Wireshark.

[Time since first frame in this TCP stream: 387.202000 milliseconds] Este paquete llega ~387 ms después del primer frame visto en este stream.

[Time since previous frame in this TCP stream: 0.000000000 seconds] Delta respecto al anterior paquete del mismo stream: 0 (puede ser misma marca temporal o muy cercano).

[SEQ/ACK analysis] Análisis de secuencias/ACKs.

[iRTT: 185.640000 milliseconds] RTT inicial estimado: ~185.64 ms.

[Bytes in flight: 3400] Bytes enviados aún no confirmados (en vuelo) en esa dirección según lo visto.

[Bytes sent since last PSH flag: 3400] Bytes enviados desde el último segmento con PSH (métrica interna).

[Client Contiguous Streams: 1] Wireshark detecta 1 bloque contiguo de datos del lado cliente (heurística).

[Server Contiguous Streams: 1] Igual para el lado servidor.

TCP payload (520 bytes) Hay 520 bytes de datos TCP en este frame.

TCP segment data (206 bytes) Importante: de esos 520, 206 bytes son los que Wireshark usa para completar un PDU reensamblado (ver siguiente bloque). Los 314 restantes pertenecen a otros registros TLS completos que vienen después.

5) Reensamblado TCP (por encima de TCP)

[3 Reassembled TCP Segments (3003 bytes): #3539(1357), #3540(1440), #3541(206)] Un mensaje de capa superior (aquí TLS) ocupa 3003 bytes y se repartió en 3 segmentos TCP:

frame 3539 aporta 1357

frame 3540 aporta 1440

frame 3541 aporta 206 (los 206 de antes)

[Frame: 3539, payload: 0-1356 (1357 bytes)] Rango de bytes dentro del PDU reensamblado que vienen del frame 3539.

[Frame: 3540, payload: 1357-2796 (1440 bytes)] Rango aportado por el frame 3540.

[Frame: 3541, payload: 2797-3002 (206 bytes)] Rango final aportado por este frame.

[Segment count: 3] Total segmentos: 3.

[Reassembled TCP length: 3003] Longitud del PDU reensamblado: 3003 bytes.

[Reassembled TCP Data […]: 1603030bb60b000bb2000baf0006dd30…] Bytes reensamblados (hex). Empieza por 16 03 03 que es típico de TLS Record:

16 = Handshake

03 03 = TLS 1.2 Ciberseguridad: esto confirma que lo que se reensambla es un registro TLS.

6) TLS --- Registro 1: Certificate

Transport Layer Security Wireshark ahora diseca la capa TLS.

[Stream index: 18] TLS va dentro del TCP stream 18.

TLSv1.2 Record Layer: Handshake Protocol: Certificate Es un TLS record versión 1.2 que contiene un mensaje de handshake “Certificate”.

Content Type: Handshake (22) Tipo de contenido TLS: 22 (handshake).

Version: TLS 1.2 (0x0303) Versión indicada en el record: 0x0303.

Length: 2998 Longitud del fragmento TLS (sin contar los 5 bytes de cabecera del record).

Handshake Protocol: Certificate Dentro del record hay un handshake message de certificado.

Handshake Type: Certificate (11) Tipo 11 = Certificate.

Length: 2994 Longitud del mensaje handshake (estructura “Certificate”), sin contar su cabecera.

Certificates Length: 2991 Longitud total del bloque de certificados dentro del mensaje.

Certificates (2991 bytes) El listado de certificados (cadena enviada por el servidor).

7) X.509 --- Certificado 1 (leaf / servidor)

Certificate Length: 1757 Primer certificado de la lista: 1757 bytes (normalmente el leaf de m.stripe.com).

Certificate […]: 308206d9308205c1a003020102021006a8… Certificado en DER (hex). 30 82 … indica una SEQUENCE ASN.1; Wireshark lo muestra truncado.

signedCertificate Parte “tbsCertificate” + firma (estructura principal).

version: v3 (2) X.509 versión 3.

serialNumber: 0x06a8ca7b40e3c0f0f9092dfb0cc9bfc2 Número de serie único del certificado.

signature (sha256WithRSAEncryption) Algoritmo de firma del cert: SHA‑256 con RSA.

Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) OID que corresponde a ese algoritmo.

Issuer (quién lo emitió)

issuer: rdnSequence (0) El emisor se codifica como secuencia RDN (DN).

rdnSequence: 3 items (id-at-commonName=… , id-at-organizationName=… , id-at-countryName=US) El DN del emisor tiene 3 atributos: CN, O, C.

RDNSequence item: 1 item (id-at-countryName=US) Primer RDN: país.

RelativeDistinguishedName item (id-at-countryName=US) Entrada concreta del RDN.

Object Id: 2.5.4.6 (id-at-countryName) OID del atributo “C”.

CountryName: US Valor: US.

RDNSequence item: 1 item (id-at-organizationName=DigiCert Inc) Segundo RDN: organización.

RelativeDistinguishedName item (id-at-organizationName=DigiCert Inc) Entrada.

Object Id: 2.5.4.10 (id-at-organizationName) OID de “O”.

DirectoryString: printableString (1) Tipo ASN.1 del string (PrintableString).

printableString: DigiCert Inc Valor.

RDNSequence item: 1 item (id-at-commonName=DigiCert Global G2 TLS RSA SHA256 2020 CA1) Tercer RDN: Common Name del emisor (la CA intermedia).

RelativeDistinguishedName item (id-at-commonName=…) Entrada.

Object Id: 2.5.4.3 (id-at-commonName) OID de “CN”.

DirectoryString: printableString (1) Tipo de string.

printableString: DigiCert Global G2 TLS RSA SHA256 2020 CA1 Valor CN del emisor.

Validez temporal

validity Ventana de validez.

notBefore: utcTime (0) Inicio en formato UTCTime.

utcTime: 2026-01-23 00:00:00 (UTC) Válido desde esa fecha/hora.

notAfter: utcTime (0) Fin de validez.

utcTime: 2026-05-07 23:59:59 (UTC) Válido hasta. Ciberseguridad: certs de corta duración reducen exposición si hay compromiso de clave.

Subject (a quién identifica)

subject: rdnSequence (0) DN del sujeto.

rdnSequence: 5 items (id-at-commonName=m.stripe.com, id-at-organizationName=Stripe, Inc, id-at-localityName=…, id-at-stateOrProvinceName=…, id-at-countryName=US) Atributos del sujeto: C, ST, L, O, CN.

RDNSequence item: 1 item (id-at-countryName=US) País del sujeto.

RelativeDistinguishedName item (id-at-countryName=US) Entrada.

Object Id: 2.5.4.6 (id-at-countryName) OID de C.

CountryName: US Valor.

RDNSequence item: 1 item (id-at-stateOrProvinceName=California) Estado/provincia.

RelativeDistinguishedName item (id-at-stateOrProvinceName=California) Entrada.

Object Id: 2.5.4.8 (id-at-stateOrProvinceName) OID de ST.

DirectoryString: printableString (1) Tipo de string.

printableString: California Valor.

RDNSequence item: 1 item (id-at-localityName=South San Francisco) Localidad/ciudad.

RelativeDistinguishedName item (id-at-localityName=South San Francisco) Entrada.

Object Id: 2.5.4.7 (id-at-localityName) OID de L.

DirectoryString: printableString (1) Tipo.

printableString: South San Francisco Valor.

RDNSequence item: 1 item (id-at-organizationName=Stripe, Inc) Organización.

RelativeDistinguishedName item (id-at-organizationName=Stripe, Inc) Entrada.

Object Id: 2.5.4.10 (id-at-organizationName) OID de O.

DirectoryString: printableString (1) Tipo.

printableString: Stripe, Inc Valor.

RDNSequence item: 1 item (id-at-commonName=m.stripe.com) CN del sujeto.

RelativeDistinguishedName item (id-at-commonName=m.stripe.com) Entrada.

Object Id: 2.5.4.3 (id-at-commonName) OID CN.

DirectoryString: printableString (1) Tipo.

printableString: m.stripe.com Valor CN.

Clave pública del servidor

subjectPublicKeyInfo Sección que contiene el algoritmo y la clave pública.

algorithm (rsaEncryption) Algoritmo de clave: RSA.

Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption) OID RSA.

Padding: 0 En ASN.1 BIT STRING, “unused bits” = 0 (alineación, no “padding” criptográfico).

subjectPublicKey […]: 3082010a0282010100de844e… La clave pública codificada (DER), truncada.

RSA Public Key Interpretación como RSA.

modulus: 0x00de844e… Módulo RSA (n), truncado.

publicExponent: 65537 Exponente público típico (F4).

Extensiones (10)

extensions: 10 items Lista de extensiones X.509.

Authority Key Identifier

Extension (id-ce-authorityKeyIdentifier) / Extension Id: 2.5.29.35 Identifica la clave de la CA que firmó este cert.

AuthorityKeyIdentifier Contenedor.

keyIdentifier: 748580c066c7df37decfbd2937aa031dbeedcd17 Huella/ID de la clave de la CA emisora.

Subject Key Identifier

Extension (id-ce-subjectKeyIdentifier) / Extension Id: 2.5.29.14 Identificador de la clave del propio sujeto.

SubjectKeyIdentifier: 8b2dbf47c3fe1a7265cf96f857142ad7eeca3c0f SKI del leaf.

Subject Alternative Name (SAN)

Extension (id-ce-subjectAltName) / Extension Id: 2.5.29.17 Nombres alternativos válidos (lo que realmente se compara hoy con SNI/host).

GeneralNames: 1 item Solo 1 entrada.

GeneralName: dNSName (2) Tipo: nombre DNS.

dNSName: m.stripe.com Hostname cubierto. Ciberseguridad: esto es clave para evitar MITM por mismatch de nombre.

Certificate Policies

Extension (id-ce-certificatePolicies) / Extension Id: 2.5.29.32 Políticas aplicables.

CertificatePoliciesSyntax: 1 item Una política.

PolicyInformation Contenedor.

policyIdentifier: 2.23.140.1.2.2 (joint-iso-itu-t.23.140.1.2.2) OID de política (relacionada con certificados TLS/validación).

policyQualifiers: 1 item Un qualifier.

PolicyQualifierInfo Contenedor.

Id: 1.3.6.1.5.5.7.2.1 (id-qt-cps) Qualifier CPS (Certification Practice Statement).

DirectoryString: http://www.digicert.com/CPS URL CPS (Wireshark lo muestra como string). Ojo: es http, no https (habitual en CPS/CRL).

Key Usage

Extension (id-ce-keyUsage) / Extension Id: 2.5.29.15 (id-ce-keyUsage) Usos permitidos de la clave.

critical: True Es crítica: si el cliente no la entiende, debe rechazar el cert.

Padding: 5 “unused bits” del BIT STRING en esa extensión.

KeyUsage: a0 Máscara de bits.

1… … = digitalSignature: True Permite firmas digitales (p.ej., en TLS).

.0.. … = contentCommitment: False No permite nonRepudiation.

..1. … = keyEncipherment: True Permite cifrado/encapsulación de claves (RSA key transport; hoy se usa más ECDHE, pero sigue siendo común).

…0 … = dataEncipherment: False No para cifrar datos “a pelo”.

… 0… = keyAgreement: False No para acuerdo de claves (sería típico en ECDSA/ECDH certificados).

… .0.. = keyCertSign: False No puede firmar otros certificados.

… ..0. = cRLSign: False No puede firmar CRLs.

… …0 = encipherOnly: False No aplica.

0… … = decipherOnly: False No aplica.

Extended Key Usage (EKU)

Extension (id-ce-extKeyUsage) / Extension Id: 2.5.29.37 Usos extendidos.

KeyPurposeIDs: 2 items Dos propósitos:

KeyPurposeId: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth) Autenticación de servidor TLS.

KeyPurposeId: 1.3.6.1.5.5.7.3.2 (id-kp-clientAuth) Autenticación de cliente TLS. Nota técnica: no siempre aparece en leafs de servidor; si te parece raro, es una señal a revisar, pero no implica malicia por sí sola.

CRL Distribution Points

Extension (id-ce-cRLDistributionPoints) / Extension Id: 2.5.29.31 Dónde descargar CRLs (revocación).

CRLDistPointsSyntax: 2 items Hay 2 puntos.

DistributionPoint Entrada 1.

distributionPoint: fullName (0) Es un nombre completo (no relativo).

fullName: 1 item Un nombre.

GeneralName: uniformResourceIdentifier (6) Tipo: URI.

uniformResourceIdentifier: http://crl3.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crl URL CRL.

DistributionPoint Entrada 2.

distributionPoint: fullName (0) Igual.

fullName: 1 item Un nombre.

GeneralName: uniformResourceIdentifier (6) URI.

uniformResourceIdentifier: http://crl4.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crl Segunda URL CRL (redundancia).

Authority Information Access (AIA)

Extension (id-pe-authorityInfoAccess) / Extension Id: 1.3.6.1.5.5.7.1.1 Métodos para OCSP y descarga del emisor.

AuthorityInfoAccessSyntax: 2 items Dos descripciones:

AccessDescription

OCSP

accessMethod: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp) Método OCSP.

accessLocation: 6 Aquí Wireshark te muestra el tipo ASN.1 (6 suele corresponder a URI en GeneralName).

uniformResourceIdentifier: http://ocsp.digicert.com Resolvedor OCSP.

AccessDescription 2) CA Issuers

accessMethod: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers) Método “caIssuers” (descargar cert del emisor).

accessLocation: 6 Tipo URI.

uniformResourceIdentifier: http://cacerts.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt URL del certificado de la CA emisora.

Basic Constraints

Extension (id-ce-basicConstraints) / Extension Id: 2.5.29.19 Indica si es CA.

critical: True Crítica.

BasicConstraintsSyntax [0 length] Secuencia vacía ⇒ por defecto cA = FALSE. Ciberseguridad: confirma que este cert no es CA, es leaf.

SCT (Certificate Transparency)

Extension (SignedCertificateTimestampList) / Extension Id: 1.3.6.1.4.1.11129.2.4.2 Lista de SCTs para Certificate Transparency.

Serialized SCT List Length: 359 Longitud total del listado.

SCT 1 (Google Argon2026h1)

Signed Certificate Timestamp (Google ‘Argon2026h1’ log) SCT emitido por ese log CT.

Serialized SCT Length: 119 Tamaño SCT.

SCT Version: 0 Versión v1.

Log ID: 0e5794bc… Identificador del log.

Timestamp: Jan 23, 2026 11:36:35.923000000 UTC Momento en que el log registró el cert.

Extensions length: 0 Sin extensiones SCT.

Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Algoritmo de firma del SCT.

Signature Hash Algorithm Hash: SHA256 (4) Hash SHA‑256.

Signature Hash Algorithm Signature: ECDSA (3) Firma ECDSA.

Signature Length: 72 Longitud de firma.

Signature: 30460221… Firma DER (truncada).

SCT 2 (Sectigo Tiger2026h1)

Signed Certificate Timestamp (Sectigo ‘Tiger2026h1’) Segundo log.

Serialized SCT Length: 117

SCT Version: 0

Log ID: 16832dab…

Timestamp: Jan 23, 2026 11:36:35.920000000 UTC

Extensions length: 0

Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)

Signature Hash Algorithm Hash: SHA256 (4)

Signature Hash Algorithm Signature: ECDSA (3)

Signature Length: 70

Signature: 30440220…

SCT 3 (DigiCert Wyvern2026h1)

Signed Certificate Timestamp (DigiCert ‘Wyvern2026h1’)

Serialized SCT Length: 117

SCT Version: 0

Log ID: 6411c46c…

Timestamp: Jan 23, 2026 11:36:35.953000000 UTC

Extensions length: 0

Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)

Signature Hash Algorithm Hash: SHA256 (4)

Signature Hash Algorithm Signature: ECDSA (3)

Signature Length: 70

Signature: 30440220… Ciberseguridad: CT ayuda a detectar/emparejar emisión fraudulenta de certificados.

Firma del certificado (parte final)

algorithmIdentifier (sha256WithRSAEncryption) Algoritmo usado para firmar este cert.

Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) OID del algoritmo.

Padding: 0 Unused bits/alineación en la codificación (no “padding” de RSA).

encrypted […]: 8145e4988a39… La firma RSA del certificado (bytes), truncada.

8) X.509 --- Certificado 2 (intermedio)

Certificate Length: 1228 Segundo certificado: probablemente la CA intermedia.

Certificate […]: 308204c8308203b0a00302010202100cf5… DER hex truncado.

signedCertificate Estructura principal.

version: v3 (2) X.509 v3.

serialNumber: 0x0cf5bd062b5602f47ab8502c23ccf066 Serie del intermedio.

signature (sha256WithRSAEncryption) Firmado con SHA256+RSA.

Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) OID.

Issuer del intermedio (root)

issuer: rdnSequence (0)

rdnSequence: 4 items (id-at-commonName=DigiCert Global Root G2, id-at-organizationalUnitName=www.digicert.com, id-at-organizationName=DigiCert Inc, id-at-countryName=US) DN del root: C, O, OU, CN.

RDNSequence item: 1 item (id-at-countryName=US)

RelativeDistinguishedName item (id-at-countryName=US)

Object Id: 2.5.4.6 (id-at-countryName)

CountryName: US

RDNSequence item: 1 item (id-at-organizationName=DigiCert Inc)

RelativeDistinguishedName item (id-at-organizationName=DigiCert Inc)

Object Id: 2.5.4.10 (id-at-organizationName)

DirectoryString: printableString (1)

printableString: DigiCert Inc

RDNSequence item: 1 item (id-at-organizationalUnitName=www.digicert.com)

RelativeDistinguishedName item (id-at-organizationalUnitName=www.digicert.com)

Object Id: 2.5.4.11 (id-at-organizationalUnitName)

DirectoryString: printableString (1)

printableString: www.digicert.com

RDNSequence item: 1 item (id-at-commonName=DigiCert Global Root G2)

RelativeDistinguishedName item (id-at-commonName=DigiCert Global Root G2)

Object Id: 2.5.4.3 (id-at-commonName)

DirectoryString: printableString (1)

printableString: DigiCert Global Root G2

Validez del intermedio

validity

notBefore: utcTime (0)

utcTime: 2021-03-30 00:00:00 (UTC)

notAfter: utcTime (0)

utcTime: 2031-03-29 23:59:59 (UTC)

Subject del intermedio

subject: rdnSequence (0)

rdnSequence: 3 items (id-at-commonName=DigiCert Global G2 TLS RSA SHA256 2020 CA1, id-at-organizationName=DigiCert Inc, id-at-countryName=US) Identifica a la CA intermedia.

RDNSequence item: 1 item (id-at-countryName=US)

RelativeDistinguishedName item (id-at-countryName=US)

Object Id: 2.5.4.6 (id-at-countryName)

CountryName: US

RDNSequence item: 1 item (id-at-organizationName=DigiCert Inc)

RelativeDistinguishedName item (id-at-organizationName=DigiCert Inc)

Object Id: 2.5.4.10 (id-at-organizationName)

DirectoryString: printableString (1)

printableString: DigiCert Inc

RDNSequence item: 1 item (id-at-commonName=DigiCert Global G2 TLS RSA SHA256 2020 CA1)

RelativeDistinguishedName item (id-at-commonName=DigiCert Global G2 TLS RSA SHA256 2020 CA1)

Object Id: 2.5.4.3 (id-at-commonName)

DirectoryString: printableString (1)

printableString: DigiCert Global G2 TLS RSA SHA256 2020 CA1

Clave pública del intermedio

subjectPublicKeyInfo

algorithm (rsaEncryption)

Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption)

Padding: 0

subjectPublicKey […]: 3082010a0282010100ccf710…

RSA Public Key

modulus: 0x00ccf710…

publicExponent: 65537

Extensiones (8) del intermedio

extensions: 8 items

Basic Constraints

Extension (id-ce-basicConstraints)

Extension Id: 2.5.29.19 (id-ce-basicConstraints)

critical: True

BasicConstraintsSyntax

cA: True Es una CA.

pathLenConstraint: 0 No puede emitir otras CA intermedias por debajo (solo leafs).

Subject Key Identifier

Extension (id-ce-subjectKeyIdentifier)

Extension Id: 2.5.29.14 (id-ce-subjectKeyIdentifier)

SubjectKeyIdentifier: 748580c066c7df37decfbd2937aa031dbeedcd17

Authority Key Identifier

Extension (id-ce-authorityKeyIdentifier)

Extension Id: 2.5.29.35 (id-ce-authorityKeyIdentifier)

AuthorityKeyIdentifier

keyIdentifier: 4e2254201895e6e36ee60ffafab912ed06178f39

Key Usage

Extension (id-ce-keyUsage)

Extension Id: 2.5.29.15 (id-ce-keyUsage)

critical: True

Padding: 1

KeyUsage: 86

1… … = digitalSignature: True

.0.. … = contentCommitment: False

..0. … = keyEncipherment: False

…0 … = dataEncipherment: False

… 0… = keyAgreement: False

… .1.. = keyCertSign: True Puede firmar certificados.

… ..1. = cRLSign: True Puede firmar CRLs.

… …0 = encipherOnly: False

0… … = decipherOnly: False

Extended Key Usage

Extension (id-ce-extKeyUsage)

Extension Id: 2.5.29.37 (id-ce-extKeyUsage)

KeyPurposeIDs: 2 items

KeyPurposeId: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth)

KeyPurposeId: 1.3.6.1.5.5.7.3.2 (id-kp-clientAuth)

AIA

Extension (id-pe-authorityInfoAccess)

Extension Id: 1.3.6.1.5.5.7.1.1 (id-pe-authorityInfoAccess)

AuthorityInfoAccessSyntax: 2 items

AccessDescription

accessMethod: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp)

accessLocation: 6

uniformResourceIdentifier: http://ocsp.digicert.com

AccessDescription

accessMethod: 1.3.6.1.5.5.7.48.2 (id-ad-caIssuers)

accessLocation: 6

uniformResourceIdentifier: http://cacerts.digicert.com/DigiCertGlobalRootG2.crt

CRL Distribution Points

Extension (id-ce-cRLDistributionPoints)

Extension Id: 2.5.29.31 (id-ce-cRLDistributionPoints)

CRLDistPointsSyntax: 1 item

DistributionPoint

distributionPoint: fullName (0)

fullName: 1 item

GeneralName: uniformResourceIdentifier (6)

uniformResourceIdentifier: http://crl3.digicert.com/DigiCertGlobalRootG2.crl

Certificate Policies

Extension (id-ce-certificatePolicies)

Extension Id: 2.5.29.32 (id-ce-certificatePolicies)

CertificatePoliciesSyntax: 5 items

PolicyInformation / policyIdentifier: 2.16.840.1.114412.2.1 (US company arc.114412.2.1)

PolicyInformation / policyIdentifier: 2.23.140.1.1 (joint-iso-itu-t.23.140.1.1)

PolicyInformation / policyIdentifier: 2.23.140.1.2.1 (joint-iso-itu-t.23.140.1.2.1)

PolicyInformation / policyIdentifier: 2.23.140.1.2.2 (joint-iso-itu-t.23.140.1.2.2)

PolicyInformation / policyIdentifier: 2.23.140.1.2.3 (joint-iso-itu-t.23.140.1.2.3)

Firma del intermedio

algorithmIdentifier (sha256WithRSAEncryption)

Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

Padding: 0

encrypted […]: 90f170cb2897… Firma RSA del intermedio (truncada).

9) TLS --- Registro 2: Server Key Exchange

Transport Layer Security Sigue TLS en el mismo TCP stream.

[Stream index: 18]

TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange Record TLS 1.2 con handshake “Server Key Exchange”.

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 300 300 bytes de fragmento TLS.

Handshake Protocol: Server Key Exchange

Handshake Type: Server Key Exchange (12)

Length: 296

EC Diffie-Hellman Server Params Parámetros para el intercambio de claves (ECDHE).

Curve Type: named_curve (0x03) Se usa una curva “nombrada” (no explícita).

Named Curve: x25519 (0x001d) Grupo X25519 (muy común y moderno para ECDHE).

Pubkey Length: 32 La clave pública efímera del servidor mide 32 bytes (X25519).

Pubkey: 24c1f80756f310266d3b14c603ef9714510715c3669a05ac06cfc0e81e298f27 Clave pública efímera del servidor (hex).

Signature Algorithm: rsa_pss_rsae_sha256 (0x0804) El servidor firma estos parámetros con RSA‑PSS + SHA‑256 (RSAE). Ciberseguridad: ECDHE + firma ⇒ autenticación del servidor + forward secrecy.

Signature Hash Algorithm Hash: Unknown (8)

Signature Hash Algorithm Signature: Unknown (4) Wireshark aquí no te lo “traduce” bien (probable limitación del dissector/versión), pero arriba ya indica rsa_pss_rsae_sha256.

Signature Length: 256 256 bytes ⇒ firma RSA de 2048 bits.

Signature […]: 6b4b1e8cdd55… Firma (truncada).

10) TLS --- Registro 3: Server Hello Done

TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done Record TLS con handshake “ServerHelloDone” (en TLS 1.2 marca fin de mensajes del servidor en esta fase).

Content Type: Handshake (22)

Version: TLS 1.2 (0x0303)

Length: 4 Fragmento TLS de 4 bytes (mensaje muy pequeño).

Handshake Protocol: Server Hello Done

Handshake Type: Server Hello Done (14)

Length: 0 Este mensaje no tiene cuerpo (solo cabecera).

Interpretación de ciberseguridad (qué “te dice” este frame)

Estás viendo parte del handshake TLS 1.2 de una conexión a m.stripe.com (Stripe).

Puedes validar a ojo que:

el SAN incluye m.stripe.com (bien),

la cadena incluye leaf + intermedio (el root suele estar en el almacén del SO y no siempre se envía),

hay CT/SCTs (buena práctica moderna),

el intercambio usa ECDHE X25519 y firma RSA‑PSS (configuración robusta, con forward secrecy).

Aunque no puedas ver el HTTP cifrado, sí ves metadatos (IPs, tiempos, SNI/cert, tamaños), que en análisis defensivo sirve para: inventario de dependencias externas, detección de MITM (mismatch de cert), y hunting de conexiones anómalas.

• Frame: 3574

• Protocolo:TLS v2.0

• Filtro: tcp.stream eq 18

{width=“6.267716535433071in” height=“0.8194444444444444in”}

El Frame 3574 es el momento en el que el servidor de Stripe nos entrega las llaves de la ciudad y cierra la puerta blindada. Es un paquete de “transición de fase”.

Aquí no solo vemos el final del apretón de manos, sino un regalo para el futuro: el New Session Ticket. Vamos a desgranar este frame con precisión quirúrgica.

1. New Session Ticket: El “Pase VIP”

Este es el primer mensaje que ves en la capa TLS de este frame.

• ¿Qué es?: Stripe le dice a tu máquina: “Para que no tengamos que hacer todo este lío de certificados y llaves la próxima vez que quieras pagar, guárdate este ticket”.

• Contexto: Tiene un Lifetime Hint de 300 segundos (5 minutos).

• Si vuelves a conectar con Stripe en ese tiempo, usarás este ticket para una conexión Abbreviated Handshake, que es mucho más rápida. Es eficiencia pura para que el usuario no espere.

2. Change Cipher Spec: El Interruptor

Lo vemos de nuevo, pero ahora viene desde el servidor hacia ti.

• Función: Stripe te notifica: “Todo lo que te envíe a partir de este preciso byte va cifrado con la llave que acabamos de acordar”. Es el punto de no retorno en la claridad de los datos.

3. Encrypted Handshake Message (Finished)

Este es el último mensaje del Handshake.

• ¿Por qué está cifrado?: Porque el interruptor (CCS) se acaba de activar un microsegundo antes.

• Misión: Contiene un hash de todos los mensajes anteriores del Handshake.

• Sirve para que tu PC verifique que nadie en el camino (como un Man-in-the-Middle) haya modificado ni un solo bit de la negociación inicial. Si el hash coincide, la confianza es total.

Análisis de Capas

Capa 3: IPv4 (La Identidad de Stripe)

• Source Address: 54.191.222.115 (m.stripe.com).

• TTL: 236: Un valor curioso. Los servidores de Amazon (donde suele estar Stripe) suelen salir con TTL 255. Esto indica que ha pasado por 19 saltos hasta llegar a tu router ZTE.

{width=“6.267716535433071in” height=“1.2916666666666667in”}

Capa 4: TCP (El Pulso del Tiempo)

• Flags [PSH, ACK]: El bit Push está activo. Stripe le dice a tu red: “Llévale esto al usuario ya, no esperes a más paquetes”.

• RTT Analizado: Wireshark calcula un RTT de 189.7 ms. Es un tiempo de respuesta sólido para un servidor que probablemente está en [EE.UU]{.underline}.

{width=“6.267716535433071in” height=“3.9722222222222223in”}

Cierre de Handshake

Elemento Significado Importancia en Pagos

---

New Session Ticket Ticket de reanudación. Acelera futuras compras en los próximos 5 min. Length (218 bytes) Tamaño del ticket. Contiene la clave de sesión cifrada por Stripe. Encrypted Message Mensaje “Finished”. Garantiza que nadie alteró la negociación. Version 0x0303 TLS 1.2. Equilibrio entre seguridad y compatibilidad.

Con el Frame 3574, Stripe ha terminado su parte del trato. Te ha dado el ticket de entrada y ha encendido el cifrado. El siguiente paso lógico en tu captura será el Frame 3575, donde tu máquina hará exactamente lo mismo: enviar su propio Change Cipher Spec y su Finished.

• Frame: 2566

• Protocolo: TLS v2.0

• Filtro: tcp.stream eq 18

{width=“6.267716535433071in” height=“0.6527777777777778in”}

Este frame es tráfico saliente desde mi host 192.168.1.130 hacia m.stripe.com:443 y contiene un TLS ClientHello (inicio del handshake TLS).

Es una pieza muy útil en ciberseguridad porque, aunque el contenido posterior vaya cifrado, el ClientHello expone metadatos (SNI, ALPN, suites, extensiones) usados para fingerprinting, detección de MITM/downgrade y visibilidad de dependencias externas.

1) Frame (metadatos de captura)

• *Frame 2566: Packet, 1840 bytes on wire (14720 bits), 1840 bytes captured (14720 bits) on interface \Device\NPF_{…}, id 0* Paquete #2566. Longitud en el medio/enlace: 1840 bytes, y se capturaron los 1840 (no hay truncado). Interfaz NPF de Windows (Npcap), id interno 0.

• *Section number: 1* Sección 1 del pcapng.

• *Interface id: 0 (\Device\NPF_{…})* Interfaz 0 dentro del archivo de captura.

• *Interface name: \Device\NPF_{…}* Nombre del dispositivo en Windows.

• *Interface description: Wi-Fi* La interfaz lógica es Wi‑Fi.

• *Encapsulation type: Ethernet (1)* Wireshark lo recibe encapsulado como Ethernet II (típico en capturas Wi‑Fi en Windows: no ves cabeceras 802.11 reales).

• *Arrival Time: Feb 26, 2026 20:26:04.545848000 Hora estándar romance* Hora local del sistema.

• *UTC Arrival Time: Feb 26, 2026 19:26:04.545848000 UTC* Misma marca de tiempo en UTC.

• *Epoch Arrival Time: 1772133964.545848000* Timestamp UNIX epoch.

• *[Time shift for this packet: 0.000000000 seconds]* No hay ajuste manual del tiempo.

• *[Time delta from previous captured frame: 279.000 microseconds]* 279 µs desde el frame anterior capturado.

• *[Time delta from previous displayed frame: 434.000 microseconds]* 434 µs desde el frame anterior mostrado (puede variar si hay filtros).

• *[Time since reference or first frame: 29.615148000 seconds]* ~29.6 s desde el frame de referencia (normalmente el primero).

• *Frame Number: 2566* Número de frame.

• *Frame Length: 1840 bytes (14720 bits)* Tamaño real a nivel de enlace.

• *Capture Length: 1840 bytes (14720 bits)* Tamaño guardado en el pcap: completo.

• *[Frame is marked: False]* No marcado manualmente.

• *[Frame is ignored: False]* No ignorado.

• *[Protocols in frame: eth:ethertype:ip:tcp:tls]* Capas identificadas: Ethernet → IPv4 → TCP → TLS. (Aquí no aparecen X.509 porque todavía estás en ClientHello; los certificados suelen venir del servidor después.)

• *Character encoding: ASCII (0)* Preferencia de representación de texto (no afecta al parseo del binario TLS).

• *[Coloring Rule Name: TCP]* Regla de color aplicada: TCP.

• *[Coloring Rule String: tcp]* Patrón que activó el color.

2) Capa 2 --- Ethernet II

• *Ethernet II, Src: Intel_2d:65:59 (94:e6:f7:2d:65:59), Dst: zte_0c:f8:0b (2c:70:4f:0c:f8:0b)* Trama Ethernet desde la MAC Intel (tu equipo) hacia la MAC ZTE (probable AP/router). Indica tráfico saliente.

• *Destination: zte_0c:f8:0b (2c:70:4f:0c:f8:0b)* MAC destino (ZTE).

• *… ..0. … … … … = LG bit: Globally unique address (factory default)* Bit U/L = 0: global (no localmente administrada).

• *… …0 … … … … = IG bit: Individual address (unicast)* Bit I/G = 0: unicast.

• *Source: Intel_2d:65:59 (94:e6:f7:2d:65:59)* MAC origen (Intel).

• *… ..0. … … … … = LG bit: Globally unique address (factory default)* Global.

• *… …0 … … … … = IG bit: Individual address (unicast)* Unicast.

• *Type: IPv4 (0x0800)* EtherType 0x0800 = IPv4.

• *[Stream index: 0]* Índice interno de stream a nivel Ethernet (Wireshark).

3) Capa 3 --- IPv4

• *Internet Protocol Version 4, Src: 192.168.1.130 (192.168.1.130), Dst: m.stripe.com (54.191.222.115)* IP origen privada (tu host) hacia IP pública que resuelve a m.stripe.com.

• *0100 … = Version: 4* IPv4.

• *… 0101 = Header Length: 20 bytes (5)* Cabecera IPv4 mínima (sin opciones).

• *Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)* DSCP por defecto, ECN no usado.

  • *0000 00.. = Differentiated Services Codepoint: Default (0)* DSCP=0.

  • *… ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)* ECN=0.

• *[Total Length: 1826 bytes (reported as 0, presumed to be because of “TCP segmentation offload” (TSO))]* Clave para analistas: Wireshark presume 1826 bytes pero dice que el campo fue “reportado como 0” por efecto de TSO.
  Qué significa (ciberseguridad/forense): con offloading, el SO puede entregar a la NIC un “super‑segmento” y la NIC lo fragmenta en segmentos reales al transmitir. En capturas locales puedes ver campos (longitud, checksum) “raros” o no validados. No asumas corrupción/malicia solo por esto.

• *Identification: 0x47f3 (18419)* ID de fragmentación IPv4.

• *010. … = Flags: 0x2, Don’t fragment* DF activo (no fragmentar).

  • *0… … = Reserved bit: Not set* Reservado a 0.

  • *.1.. … = Don’t fragment: Set* DF=1.

  • *..0. … = More fragments: Not set* MF=0.

• *…0 0000 0000 0000 = Fragment Offset: 0* Offset 0 (no fragmentado).

• *Time to Live: 128* TTL=128 (muy típico en Windows). No es prueba, pero es una señal de fingerprint pasivo.

• *Protocol: TCP (6)* L4 es TCP.

• *Header Checksum: 0x0000 [validation disabled]* Checksum IP aparece 0 y no se valida. Esto encaja con offloading/TSO (no concluyente por sí solo).

• *[Header checksum status: Unverified]* No verificado.

• *Source Address: 192.168.1.130 (192.168.1.130)* IP origen.

• *Destination Address: m.stripe.com (54.191.222.115)* IP destino (con nombre resuelto por Wireshark).

• *[Stream index: 35]* Índice interno a nivel IP.

4) Capa 4 --- TCP

• *Transmission Control Protocol, Src Port: 54197 (54197), Dst Port: https (443), Seq: 1, Ack: 1, Len: 1786* TCP desde tu puerto efímero 54197 hacia 443. Len: 1786 es el payload TCP (contiene el ClientHello TLS).

• *Source Port: 54197 (54197)* Puerto efímero cliente.

• *Destination Port: https (443)* Puerto servidor.

• *[Stream index: 18]* TCP stream #18.

• *[Stream Packet Number: 4]* Paquete #4 dentro del stream (probablemente ya pasó SYN, SYN/ACK, ACK).

• *[Conversation completeness: Incomplete, DATA (15)]* Conversación incompleta para Wireshark (no vio todo). Indicadores observados:

  • *..0. … = RST: Absent* No se vio reset.

  • *…0 … = FIN: Absent* No se vio cierre FIN.

  • *… 1… = Data: Present* Hay datos.

  • *… .1.. = ACK: Present* Hay ACKs.

  • *… ..1. = SYN-ACK: Present* Se vio SYN-ACK.

  • *… …1 = SYN: Present* Se vio SYN.

  • *[Completeness Flags: ··DASS]* Resumen: Data, ACK, SYN, SYN-ACK.

• *[TCP Segment Len: 1786]* Payload TCP en este segmento: 1786.

• *Sequence Number: 1 (relative sequence number)* Seq relativo 1.

• *Sequence Number (raw): 4239626271* Seq real (32 bits).

• *[Next Sequence Number: 1787 (relative sequence number)]* 1 + 1786 = 1787.

• *Acknowledgment Number: 1 (relative ack number)* ACK relativo 1.

• *Acknowledgment number (raw): 821914665* ACK real.

• *0101 … = Header Length: 20 bytes (5)* Cabecera TCP mínima, sin opciones.

• *Flags: 0x018 (PSH, ACK)* Flags PSH+ACK (entrega rápida a la app; habitual en handshakes).

  • 000. … … = Reserved: Not set

  • …0 … … = Accurate ECN: Not set

  • … 0… … = Congestion Window Reduced: Not set

  • … .0.. … = ECN-Echo: Not set

  • … ..0. … = Urgent: Not set

  • … …1 … = Acknowledgment: Set

  • … … 1… = Push: Set

  • … … .0.. = Reset: Not set

  • … … ..0. = Syn: Not set

  • … … …0 = Fin: Not set

  • *[TCP Flags: ·······AP···]* Resumen visual: A(ACK) y P(PSH).

• *Window: 65535* Ventana anunciada (control de flujo).

• *[Calculated window size: 65535]* Igual tras cálculo.

• *[Window size scaling factor: -2 (no window scaling used)]* No se está usando window scaling (o no se negoció/observó).

• *Checksum: 0xd763 [unverified]* Checksum TCP no verificado (muy común con offloading).

• *[Checksum Status: Unverified]* No verificado.

• *Urgent Pointer: 0* Sin urgencia.

• *[Timestamps]*

  • *[Time since first frame in this TCP stream: 186.074000 milliseconds]* Este paquete llega ~186 ms después del primero del stream.

  • *[Time since previous frame in this TCP stream: 434.000 microseconds]* 434 µs desde el anterior del stream.

• *[SEQ/ACK analysis]*

  • *[iRTT: 185.640000 milliseconds]* RTT inicial estimado ~185.64 ms.

  • *[Bytes in flight: 1786]* Bytes en vuelo (sin ACK aún) en esta dirección.

  • *[Bytes sent since last PSH flag: 1786]* Métrica interna.

• *[Client Contiguous Streams: 1]* Heurística: 1 bloque contiguo cliente.

• *[Server Contiguous Streams: 1]* Heurística: 1 bloque contiguo servidor.

• *TCP payload (1786 bytes)* Aquí empieza TLS (ClientHello).

5) Capa 5/6 --- TLS (ClientHello)

• *Transport Layer Security* Wireshark detecta TLS sobre TCP.

• *[Stream index: 18]* Pertenece al TCP stream 18.

TLS Record header (capa “Record Layer”)

• *TLSv1.2 Record Layer: Handshake Protocol: Client Hello* Es un record TLS que transporta handshake “ClientHello”. (Wireshark lo etiqueta así; en escenarios TLS 1.3 hay campos “legacy”.)

• *Content Type: Handshake (22)* Tipo 22 = handshake.

• *Version: TLS 1.0 (0x0301)* En TLS moderno (especialmente TLS 1.3) el record puede llevar una versión legacy/compatibilidad (0x0301). No significa necesariamente “estoy usando TLS 1.0”.

• *Length: 1781* Longitud del fragmento TLS dentro del record.

Handshake message: ClientHello

• *Handshake Protocol: Client Hello*

• Handshake Type: Client Hello

• *Length: 1777* Longitud del mensaje ClientHello.

• *Version: TLS 1.2 (0x0303)* Campo legacy_version dentro de ClientHello (típico en TLS 1.3: suele ir como 0x0303). La versión real soportada se anuncia en supported versions.

  • *[Expert Info (Chat/Deprecated): This legacy_version field MUST be ignored. The supported_versions extension is present and MUST be used instead.]* Wireshark avisa: este campo debe ignorarse si está supported_versions.

    • [This legacy_version field MUST be ignored. The supported_versions extension is present and MUST be used instead.]

    • *[Severity level: Chat]* Severidad informativa.

    • *[Group: Deprecated]* Agrupado como “campo legacy”.

• *Random: cdf003bfb3ab4528d22c0cb48c8f2f400e6087388c16aae35361cb0cd1ca1964* 32 bytes de aleatoriedad del cliente (clave para derivación de secretos).

  • *GMT Unix Time: Jun 27, 2079 04:34:39.000000000 Hora de verano romance* Wireshark interpreta los primeros 4 bytes como timestamp “a la antigua”, pero en clientes modernos puede ser simplemente aleatorio (no tomes 2079 como “fecha real”).

  • *Random Bytes: b3ab4528d22c0cb48c8f2f400e6087388c16aae35361cb0cd1ca1964* Resto de bytes aleatorios.

• *Session ID Length: 32*

• *Session ID: 741d58ad0256d4e4c776d9a6cc57fdfe25b834e3e8eec5beb33211aab20dfeba* Identificador de sesión “legacy”. En TLS moderno se usa por compatibilidad y para ciertos flujos de reanudación/estado.

• *Cipher Suites Length: 32*

• *Cipher Suites (16 suites)* El cliente ofrece 16 suites (el servidor elegirá 1). Desde ciberseguridad, esto es material de fingerprinting y también indica compatibilidad (y si aún se ofrecen suites antiguas).

  • *Cipher Suite: Reserved (GREASE) (0xbaba)* GREASE: valor “falso” para evitar ossification (que middleboxes rompan cosas nuevas).

  • *Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)* Suite TLS 1.3 (AEAD AES‑128‑GCM, HKDF/SHA‑256).

  • *Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)* TLS 1.3 (AES‑256‑GCM, SHA‑384).

  • *Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)* TLS 1.3 (ChaCha20‑Poly1305).

  • *Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)* TLS 1.2 ECDHE + ECDSA + AES‑GCM.

  • *Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)* TLS 1.2 ECDHE + RSA + AES‑GCM.

  • Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)

  • Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

  • Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)

  • Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

  • *Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)* TLS 1.2 con CBC+SHA1 (legacy/compatibilidad; no implica que se use).

  • Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

  • *Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)* RSA key exchange (sin forward secrecy) si un servidor lo eligiera.

  • Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)

  • Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

  • Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

• *Compression Methods Length: 1*

• *Compression Methods (1 method)*

  • *Compression Method: null (0)* Compresión TLS desactivada (lo normal; evita ataques tipo CRIME a nivel TLS “clásico”).

• *Extensions Length: 1672* Tamaño total del bloque de extensiones (grande: típico de navegadores modernos).

6) Extensiones TLS (una por una)

• *Extension: Reserved (GREASE) (len=0)*

  • *Type: Reserved (GREASE) (35466)* Tipo GREASE.

  • Length: 0

  • *Data: <MISSING>* No hay datos (longitud 0), Wireshark marca “missing” como placeholder.

• *Extension: signed_certificate_timestamp (len=0)*

  • Type: signed_certificate_timestamp (18)

  • *Length: 0* Indica soporte/solicitud relacionada con SCT/CT (el servidor puede enviar SCTs).

• *Extension: supported_groups (len=12)*

  • Type: supported_groups (10)

  • Length: 12

  • Supported Groups List Length: 10

  • *Supported Groups (5 groups)* Grupos ECDHE/KEM que el cliente soporta:

    • Supported Group: Reserved (GREASE) (0x0a0a)

    • *Supported Group: X25519MLKEM768 (0x11ec)* Wireshark lo etiqueta como un grupo híbrido X25519+MLKEM768 (post‑quantum/híbrido). A nivel defensivo: indicador de cliente moderno.

    • *Supported Group: x25519 (0x001d)* X25519 clásico (muy común).

    • Supported Group: secp256r1 (0x0017)

    • Supported Group: secp384r1 (0x0018)

• *Extension: status_request (len=5)*

  • Type: status_request (5)

  • Length: 5

  • *Certificate Status Type: OCSP (1)* Solicita OCSP stapling (el servidor puede “pegar” estado de revocación).

  • Responder ID list Length: 0

  • Request Extensions Length: 0

• *Extension: extended_master_secret (len=0)*

  • Type: extended_master_secret (23)

  • *Length: 0* Mitigación para ciertos ataques a TLS 1.2 (triple handshake). Buena señal de compatibilidad segura.

• *Extension: key_share (len=1263) X25519MLKEM768, x25519*

  • Type: key_share (51)

  • Length: 1263

  • Key Share extension

    • Client Key Share Length: 1261

    • Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1

      • Group: Reserved (GREASE) (2570)

      • Key Exchange Length: 1

      • Key Exchange: 00

    • Key Share Entry: Group: X25519MLKEM768, Key Exchange length: 1216

      • Group: X25519MLKEM768 (4588)

      • Key Exchange Length: 1216

      • *Key Exchange […]: 1751b087c2b2…* Material criptográfico del intercambio (truncado).

    • Key Share Entry: Group: x25519, Key Exchange length: 32

      • Group: x25519 (29)

      • Key Exchange Length: 32

      • Key Exchange: 52d1164b9bad282aa9103c36c6a3e8654c80cdf7e8d2ce59756d1e8d40506447

• *Extension: ec_point_formats (len=2)*

  • Type: ec_point_formats (11)

  • Length: 2

  • EC point formats Length: 1

  • Elliptic curves point formats (1)

    • *EC point format: uncompressed (0)* Formato de puntos EC (legacy, pero aún aparece por compatibilidad TLS 1.2).

• *Extension: psk_key_exchange_modes (len=2)*

  • Type: psk_key_exchange_modes (45)

  • Length: 2

  • PSK Key Exchange Modes Length: 1

  • *PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)* Para TLS 1.3 PSK/resumption: indica que si usa PSK, quiere además (EC)DHE (mejor que PSK “puro”).

• *Extension: supported_versions (len=7) TLS 1.3, TLS 1.2*

  • Type: supported_versions (43)

  • Length: 7

  • Supported Versions length: 6

  • Supported Version: Reserved (GREASE) (0x6a6a)

  • Supported Version: TLS 1.3 (0x0304)

  • *Supported Version: TLS 1.2 (0x0303)* Aquí se ve claro: soporta TLS 1.3 y 1.2.

• *Extension: application_layer_protocol_negotiation (len=14)*

  • Type: application_layer_protocol_negotiation (16)

  • Length: 14

  • ALPN Extension Length: 12

  • ALPN Protocol

    • ALPN string length: 2

    • *ALPN Next Protocol: h2* Ofrece HTTP/2.

    • ALPN string length: 8

    • *ALPN Next Protocol: http/1.1* Ofrece HTTP/1.1 como fallback.

• *Extension: compress_certificate (len=3)*

  • Type: compress_certificate (27)

  • Length: 3

  • Algorithms Length: 2

  • *Algorithm: brotli (2)* Pide compresión de certificados con Brotli (reduce tamaño del handshake; útil en latencia).

• *Extension: application_settings (len=5)*

  • Type: application_settings (17613)

  • Length: 5

  • ALPS Extension Length: 3

  • Supported ALPN List

    • Supported ALPN Length: 2

    • *Supported ALPN: h2* Wireshark lo interpreta como “application_settings/ALPS”: sirve para negociar settings de la capa de aplicación (comúnmente relacionado con HTTP/2). (No me invento más: me ciño a lo que muestra Wireshark.)

• *Extension: renegotiation_info (len=1)*

  • Type: renegotiation_info (65281)

  • Length: 1

  • Renegotiation Info extension

    • *Renegotiation info extension length: 0* Extensión de renegociación segura (TLS 1.2/legacy). En TLS 1.3 no hay renegociación, pero se anuncia por compatibilidad con middleboxes.

• *Extension: signature_algorithms (len=18)*

  • Type: signature_algorithms (13)

  • Length: 18

  • Signature Hash Algorithms Length: 16

  • *Signature Hash Algorithms (8 algorithms)* Algoritmos que el cliente acepta para firmas del servidor:

    • Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)

      • Signature Hash Algorithm Hash: SHA256 (4)

      • Signature Hash Algorithm Signature: ECDSA (3)

    • Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)

      • Signature Hash Algorithm Hash: Unknown (8)

      • *Signature Hash Algorithm Signature: Unknown (4)* Wireshark no lo desglosa bien aquí, pero arriba ya lo identifica como RSA‑PSS+SHA256.

    • Signature Algorithm: rsa_pkcs1_sha256 (0x0401)

      • Signature Hash Algorithm Hash: SHA256 (4)

      • Signature Hash Algorithm Signature: RSA (1)

    • Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)

      • Signature Hash Algorithm Hash: SHA384 (5)

      • Signature Hash Algorithm Signature: ECDSA (3)

    • Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)

      • Signature Hash Algorithm Hash: Unknown (8)

      • Signature Hash Algorithm Signature: Unknown (5)

    • Signature Algorithm: rsa_pkcs1_sha384 (0x0501)

      • Signature Hash Algorithm Hash: SHA384 (5)

      • Signature Hash Algorithm Signature: RSA (1)

    • Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)

      • Signature Hash Algorithm Hash: Unknown (8)

      • Signature Hash Algorithm Signature: Unknown (6)

    • Signature Algorithm: rsa_pkcs1_sha512 (0x0601)

      • Signature Hash Algorithm Hash: SHA512 (6)

      • Signature Hash Algorithm Signature: RSA (1)

• *Extension: server_name (len=17) name=m.stripe.com*

  • Type: server_name (0)

  • Length: 17

  • Server Name Indication extension

    • Server Name list length: 15

    • Server Name Type: host_name (0)

    • Server Name length: 12

    • *Server Name: m.stripe.com* SNI: el hostname va en claro (salvo que ECH sea aceptado y efectivamente “oculte” el SNI real vía Inner CH; aquí vemos que al menos en el Outer aparece m.stripe.com).

• *Extension: session_ticket (len=0)*

  • Type: session_ticket (35)

  • Length: 0

  • *Session Ticket: <MISSING>* Extensión presente con longitud 0: indica soporte para tickets (reanudación), pero no incluye ticket aquí.

• *Extension: encrypted_client_hello (len=250)*

  • Type: encrypted_client_hello (65037)

  • Length: 250

  • *Client Hello type: Outer Client Hello (0)* Esto indica intento/uso de ECH (Encrypted ClientHello): se envía un “Outer” visible y un “Inner” cifrado.

  • *Cipher Suite: HKDF-SHA256/AES-128-GCM* Suite HPKE usada para cifrar el Inner.

    • KDF Id: HKDF-SHA256 (1)

    • AEAD Id: AES-128-GCM (1)

  • *Config Id: 242* Identificador que referencia una configuración ECH del servidor (normalmente distribuida por DNS HTTPS/SVCB).

  • Enc length: 32

  • *Enc: f170f4da067d4193a239c3478c5ff1e3290c0c0fe62652fad92a8092d6ed0f2f* Clave encapsulada/ephemeral del intercambio HPKE (32 bytes sugiere un KEM/curva de 32 bytes, pero no afirmo más porque aquí no se muestra explícito).

  • Payload length: 208

  • *Payload […]: 457ea879e61a99…* Payload cifrado (Inner ClientHello), truncado.

• *Extension: Reserved (GREASE) (len=1)*

  • Type: Reserved (GREASE) (10794)

  • Length: 1

  • *Data: 00* Otra extensión GREASE con 1 byte de datos.

7) Fingerprints (JA4 / JA3) --- metadatos para detección

• *[JA4: t13d1516h2_8daaf6152771_d8a2da3f94cd]* Fingerprint JA4 calculado por Wireshark a partir del ClientHello (útil para detección/atribución; más robusto que JA3 en algunos escenarios).

• *[JA4_r: t13d1516h2_002f,0035,009c,009d,1301,1302,1303,c013,c014,c02b,c02c,c02f,c030,cca8,cca9_0005,000a,000b,000d,0012,0017,001b,0023,002b,002d,0033,44cd,fe0d,ff01_0403,0804,0401,0503,0805,0501,0806,0601]* Representación “raw” que enumera suites/extensiones/grupos/algoritmos usados para derivar el JA4. (Es muy usado en blue team para clasificar clientes y detectar anomalías/impersonation.)

• *[JA3 Fullstring: 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,18-10-5-23-51-11-45-43-16-27-17613-65281-13-0-35-65037,4588-29-23-24,0]* Cadena JA3 (version, ciphers, extensiones, grupos, formatos EC). Material clásico para fingerprinting pasivo.

• *[JA3: 51f2aa3d1d7f128be5a7f1a9e0e913be]* Hash MD5 del JA3 fullstring (el “JA3” que suele almacenarse en SIEM/IDS).

Lectura defensiva rápida

• Es un ClientHello muy “de navegador moderno”: TLS 1.3+1.2, ALPN h2, GREASE, key_share con x25519 y un grupo híbrido X25519MLKEM768, compresión de certificado brotli, y ECH (Outer ClientHello).

• Ojo con análisis forense: varias rarezas (IP total length “0”, checksums “unverified”) son compatibles con TSO/offloading y no necesariamente es manipulación.

• El bloque JA3/JA4 es oro para SOC: puedes crear detecciones tipo “este host de repente cambia de fingerprint” (posible malware, proxy raro, librería TLS distinta, etc.).