Foro de elhacker.net

Se conoce como túnel o tunneling a la técnica que consiste en encapsular un protocolo de red sobre otro (protocolo de red encapsulador) creando un túnel de información dentro de una red de computadoras.

Pues el cliente (TU) y el servidor negociais una conexión por HTTPs y tunelas las peticiones hacia el servicio de Spotify por ahí. Luego el servidor, tiene que hablar el mismo idioma, por lo tanto ha de "empaquetar" o "encapsular" las respuestas del servicio en paquetes HTTP over TLS (HTTPS).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pero TCP no representa un paquete en su totalidad. Piensa que una trama TCP/IP completa contiene la capa de aplicación, donde realmente están los datos que el cliente envía.

De todas formas existen mas técnicas pues los payload se pueden usar para eludir firewalls

Supuse que te referias a eso por un minuto... pero quise saber propiamente a que te referias.
¿Entonces solamente protocolos que funcionan en la capa de aplicacion (supongo que te refieres al modelo OSI) pueden "hacerse casting mutuamente", por decirlo asi, cosa que se llama tunneling?

¿Para eludir firewalls en que sentido? ¿Se puede usar la tecnica para evitar que un firewall detecte una escucha en el puerto 443 con otro fin mas que la negociacion de paquetes HTTP?

(https://i.imgur.com/BlvGuCQ.jpg)

Es decir que el paquete TCP iria en el campo de datos del paquete UDP, ¿No?. Madre mia que interesante...

¿Sabes como podria experimentar esto? quiero decir... puedes experimentar la criptografia programando o haciendo calculos, pero ¿Hay alguna forma de depurar estos protocolos? Quiero decir verlos como ves el ensamblador de un programa, aunque este escrito en un lenguaje de alto nivel, con un depurador.

Y segun esta logica, un protocolo puede ser encapsulado en otro siempre que se encuentren en la misma capa en terminos del modelo OSI, ¿No? porque no podrias, por ejemplo, encapsular a TCP en HTTP porque en primer lugar HTTP necesita a TCP para funcionar... ¿O si?

Y segun esta logica, un protocolo puede ser encapsulado en otro siempre que se encuentren en la misma capa en terminos del modelo OSI, ¿No? porque no podrias, por ejemplo, encapsular a TCP en HTTP porque en primer lugar HTTP necesita a TCP para funcionar... ¿O si?

Existe una forma determinista de experimientar esto, y es programando y depurando con un capturador de paquetes de red ya sea TCPDump o Wireshark.

Un paquete de red se compone en una serie de tramas.

Cuando recibes un paquete vía Socket estás recibiendo un paquete TCP o UDP. Dentro de esté en el campo de datos está el paquete HTTP embebido.

requeriría que en el campo de datos del paquete TCP esté el paquete HTTP, que el servidor extraiga el paquete HTTP y finalmente como este contiene otro paquete TCP lo enviaría al destino. Así que sí que se podría.

Lo que quiero que quede claro es que tu PC recibe unas tramas y te muestra el paquete TCP/UDP si tu socket maneja paquetes TCP o UDP(datagramas) y en el campo de datos vendrían los paquetes de la capa de aplicación.

https://es.wikipedia.org/wiki/T%C3%BAnel_(inform%C3%A1tica) (https://es.wikipedia.org/wiki/T%C3%BAnel_(inform%C3%A1tica))

¿A que se refiere exactamente con 'encapsular un protocolo'? ¿Como puede encapsularse un protocolo sobre otro? Lo unico que se me viene a la mente es un cast de estructuras de C  :huh:

Saludos...

¿Conoces PuTTY? ¿Se podria usar de alguna forma para probar estos conceptos?

Claro, pero ¿Como podria siquiera existir una conexion HTTP sin una conexion TCP? en ese caso habrian dos conexiones TCP: la que sostiene la conexion HTTP en si y la que se "tunelea" por el mismo protocolo, ¿No?

Un proxy es un representante. Tu interactúas con el representante y el representante interactúa por ti con otros servicios. Tu router por ejemplo podría considerarse un proxy porque representa a todos los dispositivos en la red. Es el encargado de recibir información fuera de tu red y distribuirlos a los miembros de tu red.

Un túnel es simplemente una estructura para conectar dos puntos. Así que las conexiones de red fácilmente pueden ser consideradas como un túnel. Yo entiendo un túnel de red como un túnel dentro de la red. Podrías decir que es un túnel dentro de otro túnel. Es replicar una conexión dentro de una conexión.

Para comunicarte con el proxy (tu representante) podrías decir que usas un túnel. Por ejemplo, para comunicarte con una VPN (también considerados proxy) se necesita usualmente un túnel de red.

Son términos muy genéricos a decir verdad y por lo general se entiende solo una parte de lo que realmente significan.

Ahora, podría ser que Wireshark o tcpdump necesiten acceso al fichero donde esta la key privada del server SSH puesto que el sniffer necesita obtener la clave simétrica de sesión, busca y encontraras seguro que es fácil, al igual que descifrando tramas de Firefox.

¿Dices que descifrar una conexion HTTPS no es tan dificil si tienes acceso a las tramas?

A tunnel acts as a relay point between two connections
   without changing the messages; tunnels are used when the
   communication needs to pass through an intermediary (such as a
   firewall) even when the intermediary cannot understand the contents
   of the messages.

https://tools.ietf.org/html/rfc2616#page-12 (https://tools.ietf.org/html/rfc2616#page-12)

¿"Tunel", en este caso, significa lo mismo?