333.i2p

Форум, посвященный разработке и поддержке i2pd
4 сообщений
 
Tue, 07 Jun 2022, 08:37pm Tor-like I2P proposal »
Люк
Участник
Registered: May 2022
Последний раз: Tue, 07 Jun 2022
Сообщения: 4

orignal wrote:

Надо подумать нет ли тут возможности для атаки и деанона сервера.
В целом идея здравая, что для каждого клиента формируется уникальный лизсет со своим набором тоннелей.

Думаю, что это зависит от соотношения трафика и количества своих туннелей к транзитным.
Чтобы не получить деанон, подключение нового клиента не должно мгновенно триггерить создание известного количества туннелей. Туннели должны появляться при длительной активности клиента, в случайном количестве 1-2. По всем параметрам нужна рандомизация. Сколько трафика должно быть передано этому клиенту, сколько времени он должен быть активен, прежде чем его пересаживать на персональный лизсет, надо рандомизировать. Туннели от других клиентов переиспользовать. Так снизится риск от этой фичи, мое мнение.

Offline
Sun, 29 May 2022, 06:07pm Tor-like I2P proposal »
Люк
Участник
Registered: May 2022
Последний раз: Tue, 07 Jun 2022
Сообщения: 4

Взаимодействие клиента с сервером в I2P выглядит так. Сервер публикует в NetDB Leaseset со списком входящих туннелей. Когда клиент хочет обратиться к серверу, то он получает Leaseset из NetDB, обращается к серверу через входящие туннели. Когда туннели сервера обновляются, клиент их получает не из NetDB, а непосредственно от сервера. Всем клиентам сообщается одинаковый список входящих туннелей.

Предлагаю улучшение для серверов, принимающих или раздающих большие файлы, т.е. использующих длительные соединения с непрерывной передачей данных.
Изначально все клиенты используют одни и те же входящие туннели сервера, получаемые из NetDB, других вариантов нет. Когда объем передаваемых данных (или время соединения) превысил заданный порог, сервер создает 1-2 входящих и исходящих туннеля, которые будет использовать исключительно с этим клиентом. Клиенту теперь отдает Leaseset с этими уникальными входящими туннелями. Постепенно клиент пересаживается на них.
Таким образом мы избегаем ситуации, когда большое количество клиентов совместно используют одни и те же туннели сервера и перегружают их. Описанная схема имеет общие черты с работой onion-сервисов, в которых к каждому к клиенту выстраивается своя цепочка.
Если клиент, посаженный на уникальные туннели, перестал использовать пропускную способность, сервер будет его пересаживать обратно на общие туннели и закрывать ненужные уникальные. Уникальные туннели отключившегося клиента можно перераспределить между другими клиентами или закрыть.

Offline
Sat, 28 May 2022, 03:47pm Серверный HTTP туннель и клиентский SOCKS прокси »
Люк
Участник
Registered: May 2022
Последний раз: Tue, 07 Jun 2022
Сообщения: 4

Как я понял, этот код обрабатывает входящие соединения? Получается, что здесь один раз обрабатывается заголовок с добавлением X_I2P_DEST_B32, X_I2P_DEST_HASH, X_I2P_DEST_B64, а все, что идет дальше, передается как есть. Не учитвается возможный http keep-alive. Если дальше идет новый http заголовок, то он будет передан в неизменном виде. Тут можно даже подменить X_I2P_DEST_B32, X_I2P_DEST_HASH, X_I2P_DEST_B64. Я правильно понял?

void I2PServerTunnelConnectionHTTP::Write (const uint8_t * buf, size_t len)
{
if (m_HeaderSent)
I2PTunnelConnection::Write (buf, len);
else
{
m_InHeader.clear ();
m_InHeader.write ((const char *)buf, len);
std::string line;
bool endOfHeader = false;
while (!endOfHeader)
{
std::getline(m_InHeader, line);
if (!m_InHeader.fail ())
{
if (line == "\r") endOfHeader = true;
else
{
if (m_Host.length () > 0 && !line.compare(0, 5, "Host:"))
m_OutHeader << "Host: " << m_Host << "\r\n"; // override host
else
m_OutHeader << line << "\n";
}
}
else
break;
}

if (endOfHeader)
{
// add X-I2P fields
if (m_From)
{
m_OutHeader << X_I2P_DEST_B32 << ": " << context.GetAddressBook ().ToAddress(m_From->GetIdentHash ()) << "\r\n";
m_OutHeader << X_I2P_DEST_HASH << ": " << m_From->GetIdentHash ().ToBase64 () << "\r\n";
m_OutHeader << X_I2P_DEST_B64 << ": " << m_From->ToBase64 () << "\r\n";
}

m_OutHeader << "\r\n"; // end of header
m_OutHeader << m_InHeader.str ().substr (m_InHeader.tellg ()); // data right after header
m_InHeader.str ("");
m_From = nullptr;
m_HeaderSent = true;
I2PTunnelConnection::Write ((uint8_t *)m_OutHeader.str ().c_str (), m_OutHeader.str ().length ());
}
}
}

Offline
Sat, 28 May 2022, 03:19pm Серверный HTTP туннель и клиентский SOCKS прокси »
Люк
Участник
Registered: May 2022
Последний раз: Tue, 07 Jun 2022
Сообщения: 4

Выяснили, что когда клиент заходит на сайт через socks прокси, на некоторых запросах серверный роутер не проставляет заголовки HTTP_X_I2P_DESTB32.

Я провел эксперимент на i2pd 2.42.1. Что выяснил: когда клиент сидит через socks прокси, на некоторых запросах не проставляется b32. На моем сервере из 75 запрсов только 6 содержали b32. Предположу, что проблема возникает из-за http keep-alive. Когда несколько запросов приходят через одно соединение, i2pd на сервере проставляет HTTP_X_I2P_***-заголовки только в первом запросе, в последующие не проставляет.

Offline