333.i2p

333 wrote:

Люди анонимные, напишите, пожалуйста, эти строки, полученные по ссылке выше, как-то деанонят? Если да, то какие и как/чем/почему.

User-Agent=MYOB/6.66 (AN/ON)
Connection=close
Accept-Encoding=gzip, deflate
X-I2p-Desthash=удолил
X-I2p-Destb32=удолил
Upgrade-Insecure-Requests=1
X-I2p-Destb64=удолил

Это все строки. У кого больше/меньше? Если да, то какие.

X-I2p-Desthash, X-I2p-Destb32, X-I2p-Destb64 уникально идентифицируют тебя, больше ни у кого таких же нет. Они привязаны к туннелям твоего клиентского http прокси. Если ты заходишь на несколько разных сайтов, они будут видеть одни и те же значения и смогут понять, что на них заходила одна и та же личность (если сайты майорский и майор имеет доступ к логам посещений всех этих сайтов). Поэтому b32 стоит почаще менять.
С настройками по умолчанию они не меняются до перезапуска роутера. Чтобы сменить b32 в i2pd, нужно, чтобы в настройках туннеля было прописано keys = transient и делать HUP для перезагрузки конфига. Тогда у всех туннелей с keys = transient поменяется b32. Другой вариант - прописать keys = имя_файла. Тогда для смены b32 на этом туннеле надо удалить файл ключей и сделать HUP (а если не удалять, то b32 будет сохраняться после перезагрузки роутера).

orignal, проясни какую терминологию лучше использовать:
Говорить "b32", подразумевая b32, b64, desthash - корректно?
Говорить "туннель", подразумевая один конкретный клиентский http-прокси, socks-прокси или серверный и прочее со всеми их входящими и исходящими туннелями - корректно? Или есть более подходящий термин?

Orignal, я нашел в чем дело. В коде проверяется
if(req.GetHeader("Referrer") != "") {

Referrer с двумя r. Браузер посылает Referer с одной r. Это и в firefox и в w3m. И по идее в любом браузере он с одной r.

2. У java роутера разве не такой же User-Agent? Я говорю о том, что по наличию Referer можно отличить пользователей i2pd от пользователей java i2p.

orignal wrote:

С Referer несколько посложнее. В коде
/**
* according to i2p ticket #1862:
* leave Referrer if requested URL with same schema, host and port,
* otherwise, drop it.
*/

Иначе говоря если переход идет с того же адреса то не удавляется.
Проверь с какого нибудь друого.

Я с твоих слов понял, что referer должен быть, если я перехожу с одной страницы сайта на другую страницу того же сайта. И его не должно быть в любом другом случае. Т.е. при переходе с другого сайта Referer не должен быть доступен серверу, а он доступен. Ты пробовал заходить со страницы форума на http://63sgpiu6f33arldcxkbjsn3jgf6asyx3onjmz6j6... ? Он видит Referer.
Если переходить, с того же адреса, то Referer остается, это да.

Надо. Java роутер его вырезает.
1) Это снижает анонимность, т.к. показывает серверу, откуда пришел пользователь.
2) Это снижает анонимность, т.к. позволяет серверу определить клиента как пользователя i2pd.

orignal, в версии 2.41 этот баг тоже присутствовал.
[s]Теперь баг пофишен, проверено мной. Версия 2.42.1.[/s]
Баг НЕ ПОЛНОСТЬЮ пофикшен!
Если во время HUP нет активных стримов у серверного туннеля, то он сохраняет работоспособность после HUP.
Если во время HUP были стримы у серверного туннеля, то они рвутся. Все новые стримы виснут с 500-1000 входящих и исходящих байт. На клиентской стороне просто нет ответа от сервера, соединение висит. На серверном роутере в логах куча "Streaming: Acceptor for incoming stream is not set". Вернуть серверный туннель в работоспоссобное состояние можно только закомментировав его в tunnels.conf, сделать HUP, раскомментировать, и еще раз HUP.

Эта проблема не распространяется на клиентские туннали. Если есть туннели с keys=имя_файла, то после HUP туннели продолжает работу, даже если были активные стримы. Они не рвутся. В отличие от ситуации с серверными туннелями.

Orignal, я постарался подробно расписать симпотомы проблемы. Надеюсь, это поможет в ее решении.

Last edited: Thu, 26 May 2022, 09:43pm от reportn462

Http прокси настроен в tunnels.conf. Он не вырезает referer, как это делает java роутер. Что видно на http://63sgpiu6f33arldcxkbjsn3jgf6asyx3onjmz6j6...

Не проверял прокси в i2pd.conf.