WebTunnels de Tor: otra forma de evitar la censura

viernes, 29 de noviembre de 2024 | Publicado por el-brujo | Editar entrada

En un esfuerzo por combatir la censura en internet y promover una experiencia en la red personalizada y privada, Tor ha lanzado su más reciente innovación: WebTunnel. Esta nueva configuración puente, incorporada en su última versión estable, está diseñada para ayudar a los usuarios en regiones represivas al simular tráfico HTTPS, facilitando la evasión de las restricciones sin ser detectados.

WebTunnel surge como respuesta a las limitaciones impuestas en varios países hacia Tor, una herramienta que permite el acceso a la web oscura y que ha sido prohibida en múltiples regiones debido al tráfico de internet peculiar que genera. Tradicionalmente, las capas de cifrado aplicadas por Tor para proteger los datos de los usuarios hacen que el tráfico sea fácilmente identificable para las autoridades, debido a su aspecto fuertemente ofuscado. Sin embargo, WebTunnel busca cambiar esta situación al mimetizar el tráfico de Tor con el tráfico HTTPS común, haciendo casi imposible su detección por parte de regímenes opresivos.

La tecnología detrás de WebTunnel envuelve la conexión de carga útil en una conexión HTTPS tipo WebSocket, apareciendo ante los observadores de la red como una conexión HTTPS (WebSocket) ordinaria. Tor garantiza que la similitud con el tráfico HTTPS es tal que puede coexistir con un sitio web en el mismo punto de red, permitiendo que un proxy inverso de tráfico estándar redirija tanto el tráfico convencional como el WebTunnel a los respectivos servidores de apl

Cómo funciona

WebTunnel funciona envolviendo la carga útil de la conexión en una conexión HTTPS similar a WebSocket. Para un observador externo el tráfico es indiscernible del que generaría un usuario que estuviese visitando una página web convencional.

Esto es de especial utilidad en situaciones en las que el censor trabaja con una lista de protocolos permitidos y bloquea todos los demás. En un entorno de estas características otro tipo de puente, como obfs4, no conseguiría evitar el filtrado.

Cómo utilizarlo

Aunque planean incluir más métodos de distribución en el futuro, por el momento WebTunnel sólo se pueden encontrar en la web de Tor Project.

Paso 1 — Obtener el puente WebTunnel

Utilizando un navegador cualquiera visitar el sitio https://bridges.torproject.org/options
En “Advanced Options” seleccionar webtunnel y hacer click en “Get Bridges”.
Resolver el captcha.
Copiar la línea que se proporciona.

Paso 2 — Descargar e instalar el navegador Tor

Descargar e instalar el navegador Tor para escritorio.
Abrir el navegador, ir a las preferencias de conexión.
Hacer click en “Add a Bridge Manually” y añadir la línea copiada en el paso 1.
Cerrar el cuadro de diálogo y hacer click en “Connect”.

El objetivo de Tor Project es asegurarse de que su red sea accesible para todo el mundo.

En momentos en que conflictos geopolíticos ponen a millones de personas en riesgo, Internet es crucial para comunicarnos, compartir y ser testigos de lo que sucede en el mundo, organizarnos, defender los derechos humanos, y construir redes de solidaridad.

Desde la organización se recuerda que la contribución de los voluntarios es vital para la continuidad del proyecto.

Instalación de Webtunnel

WebTunnel es un puente de transporte conectable (PT) para el ecosistema Tor. Es un proxy resistente a la censura que intenta imitar el tráfico HTTPS.

Pasos para la instalación y puesta en marcha de un puente Webtunnel

Requerimientos previos
Instalación de software
Configuración
Inicio de la aplicación Webtunnel en un contenedor
Actualización

1. Requerimientos previos

Dominio de internet con sus DNS habilitados
Una máquina virtual o dedicada con Debian 11 o 12
Dirección IP pública

2. Instalación de software

Docker CE
Cerbot
Nginx

Instalación de docker

sudo apt install curl
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh ./get-docker.sh'

Instalación de cerbot

sudo apt install certbot

Instalación de nginxs

udo apt install nginx python3-certbot-nginx

3. Configuración

Creación de certificados
Configuración del servidor nginx
Crear el archivo de configuración .env para docker-compose.yml

Creación de certificados

Antes de proceder a la creación de los certificados con Certbot es necesario agregar a los DNS de nuestro dominio el registro A necesario para que el dominio apunte a la dirección IP de nuestra máquina.

sudo certbot --nginx -d mydominio.org

Configuración del servidor nginx

Configuración de reenvío de http para el dominio en /etc/nginx/site-enabled/default

Reemplace $PATH con una cadena aleatoria que se genera con el siguiente comando:

echo $(cat /dev/urandom | tr -cd "qwertyuiopasdfghjklzxcvbnmMNBVCXZLKJHGFDSAQWERTUIOP0987654321"|head -c 24)

Agregamos el siguiente bloque de configuración al archivo /etc/nginx/site-enabled/default

server {
listen [::]:443 ssl http2;
listen 443 ssl http2;
server_name $SERVER_ADDRESS;
#ssl on;

# certificates generated via acme.sh
ssl_certificate /root/.acme.sh/DOMAIN_ecc/fullchain.cer;
ssl_certificate_key /root/.acme.sh/DOMAIN_ecc/DOMAIN.key;

ssl_session_timeout 15m;

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

ssl_prefer_server_ciphers off;

ssl_session_cache shared:MozSSL:50m;
#ssl_ecdh_curve secp521r1,prime256v1,secp384r1;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=63072000" always;

location = /$PATH {
proxy_pass http://127.0.0.1:15000;
proxy_http_version 1.1;

### Set WebSocket headers ###
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

### Set Proxy headers ###
proxy_set_header Accept-Encoding "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
add_header Front-End-Https on;

proxy_redirect off;
access_log off;
error_log off;
}

}

Apache:

<VirtualHost *:443>
ServerName [[HOST_NAME]]

Protocols http/1.1 h2

SSLEngine on

# Certificates generated via acme.sh
SSLCertificateFile /root/.acme.sh/DOMAIN_ecc/fullchain.cer
SSLCertificateKeyFile /root/.acme.sh/DOMAIN_ecc/DOMAIN.key

SSLProtocol TLSv1.2 TLSv1.3
SSLSessionCacheTimeout 900

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

ProxyPreserveHost On
ProxyRequests off

Header always set Strict-Transport-Security "max-age=63072000"

<Location /[[SECRET_PATH]]>
# This lets Apache set the "X-Forwarded-For", "X-Forwarded-Host" and
# "X-Forwarded-Server" HTTP headers automatically if enabled (Default is 'On').
# "X-Forwarded-For" is set manually below to avoid the other two
# headers provided by this directive that we don't need.
ProxyAddHeaders Off

# Set Proxy headers
RequestHeader unset Accept-Encoding
RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s"
RequestHeader set X-Forwarded-Proto "%{REQUEST_SCHEME}s"
Header set Front-End-Https on

ProxyPass "ws://127.0.0.1:15000/%{REQUEST_URI}s"
ProxyPassReverse "ws://127.0.0.1:15000%{REQUEST_URI}s"
</Location>

ErrorLog off
</VirtualHost>

Docker

Descarga del archivo docker-compose.yml

curl https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/raw/main/release/container/docker-compose.yml?inline=false > docker-compose.yml

Creamos en el mismo directorio el archivo .env

truncate --size 0 .env

Agregamos las siguientes variables de configuración. Esto creará un archivo de entorno para la configuración del puente.

Variable de nombre de dominio o subdominio. Tendremos que cambiar el nombre de dominio o subdominio que dispongamos para nuestro puente

echo "URL=https://mydominio.org/$path" >> .env

Variable de dirección de correo electrónica que estará asociada a nuestro puente

echo "OPERATOR_EMAIL=your@email.org" >> .env

Agregamos nombre del puente

echo "BRIDGE_NICKNAME=WTBr$(cat /dev/urandom | tr -cd 'qwertyuiopasdfghjklzxcvbnmMNBVCXZLKJHGFDSAQWERTUIOP0987654321'|head -c 10)" >> .env

Agregamos número de puerto

echo "GENEDORPORT=4$(cat /dev/urandom | tr -cd '0987654321'|head -c 4)" >> .env

4. Inicio de la aplicación Webtunnel en un contenedor

Una vez que tenemos nuestro .env con las variables completas iniciamos nuestra aplicación con docker compose. Para así ejecutar la aplicación Webtunnel en un contenedor dentro de nuestra máquina.

docker compose up -d

Ahora podemos comprobar que nuestro puente Webtunnel se está funcionando adecuadamente

docker compose exec webtunnel-bridge get-bridge-line.sh

5. Actualización

Para mantener actualizado el software por medio de docker compose. Utiliza los siguientes comandos

docker compose pull
docker compose up -d

Renovación de certificados

certbot renew

Fuentes y más información:

Vía:

https://casi-cincuenta-monos.medium.com/tor-project-lanza-una-nueva-herramienta-para-luchar-contra-la-censura-cfc17c1f602a

https://www.jacobo.org/instalacion-de-webtunnel/

Etiquetas: bridge , privacidad , socket , tor , tunnel , web , webtunnel

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.

Tienda Wifi

Tutoriales y Manuales

Entradas Mensuales

Síguenos en:

Blogroll

Etiquetas

Entradas populares