Хотел спросить существуют ли какие то концептуально новые решения, патчи или ответвления в проекте тор, в связи с появлением новых инструментов блокировки сети у различных государств? Может быть есть какие то решения улучшающие обфускацию, или смотрящие в сторону большей распределенности сети и децентрализованности? Что нового обсуждается в среде разработчиков? Спасибо

ARTI с трудом но работает
но пока что ИМХО слишком сырое
нет кучи полезных опций типа torexit country
нередко материться на IPv6 сайты да и на обычных бывает не грузит ссылки а в логах какие то мутные error socks
но при этом на РТ/РФ (Калуга) там где обычный тор работает только через webtunnel там АРТИ соединятеся без мостов. пока что.

А за счет чего? Я думал arti это просто переписанный на раст тор, а там еще иновации есть? Webtunnel я так понял это новый тип мостов, в чем особенность? Что то инфу не могу найти, что он имитирует. Как я понял его еще нет в релизном браузере, только в альфа. Нужно затестить, вроде говорят лучше obfs и snowflake.

Немного другой выбор релеев и таймаутов. Ведь многие релеи незаблокированы.

Имитирует https, что довольно полезно. Но готовых предложений немного.
Еще есть крутая технология conjure, работает из коробки пока. Какие-то фантомные прокси при поддержке сетевых операторов. Очень сложная логика, я так и не понял.

Ну наконец то, давно пора. Хех, мог бы догадаться по названию.
спасибо за ответ.

как я понял в АРТИ и выбор по другому сделан. и сам АРТИ особенно на rustls вместо native-tls пока что не ловят через DPI
все плугины собираются руками через Pluggable Transports · GitLab ну или выдрать из Index of /tor-package-archive/torbrowser/13.5a1
новые мосты webtunnel дают на bridges.torproject.org/bridges/?transport=webtunnel&ipv6=no но там лично мне выдают из одной и той же IPv6 подсети. может еще где есть списки

под win32/x64 винду есть лично собранные https://github.com/laileb76/le0n/raw/main/_arti_1-1-10_windows_20231103_1913.rar с snowflake/webtunnel и конфигами

Насколько я понял - всё очень просто с точки зрения обывателя. Операторы владельцы IP-шников дают возможность использовать эти айпишники для прокси. Как там технологически устроено я не знаю, но факт в том что операторы должны пойти на это. Для них это большое политическое решение. Соответственно и поддержка у них должна быть политическая и соответствующие проблемы.

Еще можно пустить tor через yggdrasil. Хотя, будет лишний трафик, как у любой p2p сети.
И у меня давно уже в планах потестить старый fte мост на своем сервере, fte маскируется под обычный http, даже не https. Это давно забытое старое.

Кто знает почему fteproxy не работает? Неторовский, напрямую. Делал как здесь https://fteproxy.org/help-server-without-tor.html

Server:
wget https://fteproxy.org/dist/0.2.18/fteproxy-0.2.18-linux-x86_64.tar.gz
tar -xf fteproxy-0.2.18-linux-x86_64.tar.gz
cd fteproxy-0.2.18-linux-x86_64
./fteproxy.bin --mode test
./fteproxy.bin --server_ip X.X.X.X --server_port 43332 --proxy_ip 127.0.0.1 --proxy_port 9050

(127.0.0.1:9050 SOCKS Tor client on server)
X.X.X.X Server IP

Client:
cd /home/denis/fteproxy
./fteproxy.bin --client_ip 127.0.0.1 --client_port 2080 --server_ip X.X.X.X --server_port 43332

(127.0.0.1:2080 Local SOCKS for browsers)

В Wireshark видно, что коннект с сервером есть, замаскированный HTTP запрос отправляется, в ответ что-то приходит, но в браузере таймаут.

Как будто серверный fteproxy не дружит с вышестоящим прокси (tor).
И не совсем понятно почему бы серверному fteproxy не взять серверный интернет напрямую и зачем надо обязательно лезть через вышестоящий прокси. В инструкции ssh, но я использовал tor демон, тоже socks.

Технология интересная. Хоть и старая, но все равно. Чистый HTTP для провайдера. Не надо возиться с сертификатами. Подскажите. Где-то затык.
Правда, для настоящей маскировки под HTTP полагается, чтобы порт был 80, но я такой заюзать не могу на сервере. Может, в этом дело.

Запросы к вышестоящему прокси не уходят 127.0.0.1:9050 (я заюзал Charles вместо Tor). Может быть fteproxy не договорились друг с другом (клиент-сервер). Или нужен какой-нибудь ключ.

Извините, всё работает. Просто, забыл параметр --mode server на сервере. Документация об этом умолчала, а в --help было.

Параметры такие:
./fteproxy.bin --mode server --server_ip 0.0.0.0 --server_port 60576 --proxy_ip 127.0.0.1 --proxy_port 9050 --key FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000000000000000000000000000

./fteproxy.bin --mode client --client_ip 127.0.0.1 --client_port 2080 --server_ip X.X.X.X --server_port 60576 --key FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000000000000000000000000000

Как видите, здесь fteproxy используется не как мост для тора, а как обычный зашифрованный прокси (трафик которого выглядит как HTTP). Не вижу смысла в торе.
Единственное, похоже что на сервере все равно нужен какой-то вышестоящий socks прокси, хотя бы как localhost посредник. Напрямую не хочет брать интернет.
Так что если 127.0.0.1:9050 будет серверным tor клиентом, то у клиента (браузера) в конечном итоге будет торовский айпишник.

Наверное, это не очень надежная HTTP маскировка, без защиты от active probing. Наверняка сейчас есть решения более продвинутые и современные.
Там просто GET цифры HTTP/1.1. В ответ HTTP/1.1 200 OK Content-Type: бинарные данные. Без домена.
Если цензор обратится браузером к IP сервера, ответа не будет. Зато в логе сервера посыпятся ошибки.