[О блоге] [наверх] [пред] [2023-08-16 20:18:53+03:00] [552979396ad8de1f3bbeb409f1c2a65f7446806b]
Темы: [crypto]

udpobfs

http://www.git.cypherpunks.ru/?p=udpobfs.git;a=blob;f=README
Постоянно стали возникать новости о блокировках VPN-ов в РФ. Хотя у меня
только один раз возникала она (55eac8d1c25b49bafcc4ed1ece2f4f7763e0230f)
на несколько часов.

Многие предлагают бороться обфускацией трафика, маскированием его под
что-то другое. Я на всё это смотрю проще, со времён разработки GoVPN:
если сеть не позволяет случайные данные (сплошной рандом) отправлять, то
значит это whitelist блокировка: разрешено отправлять только явно
заданные вещи. По этой сети нельзя произвольными данными обмениваться.
Извращаться и страдать хернёй с попытками то так, то сяк, то таким или
другим образом запрятать данные, а то и вообще со стеганографией -- я не
собираюсь. Нет сети обмена произвольными данными -- значит нет. Мне не
интересно играть в игры, прятки и притворяться по всякому. Это же всё
равно продолжение игры по правилам не совсем дружных с головой людей,
и потакание их тупостям. А с их точки зрения они будут продолжать видеть
то, что люди, не смотря на whitelisting, всё равно продолжают
использовать эти каналы связи.

Blacklist блокировки уже давно стали нормой абсолютно везде в мире,
задолго до РФ -- да и в целом то я не сталкивался с ними на практике
особо.

Так вот для меня лакмусовой бумажкой является возможность отправки чисто
шума, не содержащего ни структуры, ни заголовков явных каких-то, ни чего
то подобного. Это у меня умел GoVPN, но не охота снова смотреть на него,
ибо это мой первый проект на Go, где по идее надо бы вообще всё
переписать с нуля. Сам протокол то там нормальный, а вот код так себе.
Да и я уже говорил, что если бы WireGuard появился раньше, то я бы и не
начинал писать GoVPN, ведь всякие DPI-resistant фишки я уже добавлял
после того как мне просто нужен был какой-то простой препростой VPN, а
не IPsec или OpenVPN.

Нельзя ли просто сделать какой-нибудь простой UDP прокси, который бы
симметрично как-то шифровал пакетики, исключительно для того, чтобы они
выглядели как сплошной шум? Проще написать, чем читать документацию
какого-нибудь shadowsocks, obfsproxy и подобных проектов, где я так и не
смог за пару минут найти как именно они работают и могут ли просто "шум"
слать. Всякие имитации HTTPS/whatever мне не интересны.

Вот и написал его. (Пока?) Даже handshake нету. Предполагаю что в любом
случае уж OpenSSH то будет работать априори (а если нет, то можно
выдернуть Ethernet -- всё равно это не работающая сеть). А значит по
нему (аутентифицированному, с PFS) можно просто отправлять ключи для
udpobfs какими-нибудь скриптами. Вариантов масса. Почему не делать VPN
прямо поверх OpenSSH, который вполне себе из коробки умеет даже TUN
интерфейс создавать? Плохая производительность, как минимум потому что
это поверх TCP будет.

Каждая сторона имеет 64-бит счётчики, являющиеся nonce-ом. В начале
пакета добавляются только 24-бит счётчика, остальная часть в памяти на
каждой стороне. Если значение счётчика пакета пришло меньше чем было
прежде, то значит было переполнение и в памяти увеличивается оставшаяся
часть. Аналогично как это с ESN в IPsec ESP делается. Над полным 64-бит
счётчиком и шифротекстом (ChaCha20) вычисляется Poly1305 (ключ, как это
принято в ChaCha20-Poly1305, берётся из первых 256-бит выхлопа ChaCha20)
вычисляется MAC, но только 40-бит от него используется. 24-бит часть
счётчика и 40-бит MAC добавляются перед шифротекстом, всего восемь байт
overhead. И эти 8 байт шифруются Blowfish-ем. Почему Blowfish? Потому
что у него 64-бит блок, а почти у всех остальных шифров (хоть сколько то
серьёзных) -- 128-бит. "Заголовок" 8 байт. UDP пакет может быть пустым,
а значит для 128-бит шифров понадобится дополнение, с которым не хочется
возиться. Ключи для всего этого (пара ChaCha20+Blowfish для каждой
стороны) вырабатываются из выхлопа SHA3 SHAKE128, на входе которого
общий ключ приходящий из вне.

Демон берёт ключи из stdin -- можно прямо на лету их подавать всё новые
и новые. Конечно же будет какой-то промежуток времени когда ключи будут
разсинхронизованы и поэтому часть трафика потеряется, но да и фиг с
этим. Это всё равно заточено под обфускацию VPN, внутри которого всякие
TCP не сильно пострадают.

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

    [оставить комментарий]
    комментарий 0:
    From: John Doe
    Date: 2023-08-17 18:51:18Z
    
    Добрый день, попробуйте почитать рип сайта, который прикрыли,
    
    https://www.mediafire.com/file/70ml76bg35weabx/oilandfish.tar.gz/file
    
    Вполне себе рабочие конструкции написаны, я остановился на cloak +
    wireguard over tcp, tunsafe называется. Плясок с mtu устраивать не
    приходится. Нагрузка на процессор есть, т.к. в пространстве
    пользователя работает, в отличии от wg. Но wg скорость в 2 раза меньше,
    т.к. udp over tcp инкапсулирование идет.
    
    Есть еще проект https://gost.run/en/, можно проброс портов и туда и
    обратно делать, а также разные другие вещи, с cloak нормально работает.
    
    Всех благ.
    
    комментарий 1:
    From: Sergey Matveev
    Date: 2023-08-17 19:30:33Z
    
    Приветствую!
    
    *** John Doe [2023-08-17 18:24]:
    >https://www.mediafire.com/...
    
    Не даёт скачать, нет ссылки. Думаю что требует JavaScript.
    
    >Есть еще проект https://gost.run/en/, можно проброс портов и туда и
    >обратно делать, а также разные другие вещи, с cloak нормально работает.
    
    Его я давно ещё видел. Вот именно про это и писал: всё это большие
    full-featured решения, полноценные VPN-ы со всякими плюшками. Это не
    плохо, ничего против не имею, но тащить такое только ради того, чтобы
    сделать обфускацию я просто, как минимум, эстетически не хотел бы. И я
    именно просто превращение в "шум" хочу, а не имитацию другого протокола.
    
    Плюс надо смотреть их протокол и конкретные преобразования как делаются:
    для обфускации я очень бы хотел что-то максимально лёгкое, пускай даже и
    не обеспечивающее конфиденциальность, защиту от replay и подобного. Ибо
    если будет серьёзная нормальная криптография, то значит ощутимо будет
    тратиться часть CPU. А поверх этого я в любом случае буду использовать
    WireGuard, ибо ему полное доверие (да и даже приятно что оно в ядре
    встроено вообще). А полностью менять VPN решение: вообще не вариант, тем
    более на такое громоздкое и большое, что я больше потрачу времени на
    исследование кода их реализации (проще GoVPN возродить, который уметь
    создавать только "шум" даже при handshake).
    
    >Но wg скорость в 2 раза меньше, т.к. udp over tcp инкапсулирование идет.
    
    Если бы я согласился на UDP/IP-over-TCP, то я бы просто взял OpenSSH и
    его встроенную возможность TUN-интерфейсов. Пускай оно и будет
    ограничено одним ядром процессора (OpenSSH не параллелиться) -- но для
    100Mbps Интернет канала этого достаточно. Да и вообще нескольких мегабит
    бы было достаточно. А раз OpenSSH и так есть -- то вообще не хочется
    париться с чем-то ещё.
    
    Я отталкиваюсь от того, что SSH всегда будет в whitelist. Если же нет
    (его заблокируют), то я вообще ничего не буду пытаться делать дальше,
    ибо с моей точки зрения это полностью неработающая сеть, а чисто
    удалённый доступ до ряда разрешённых сервисов.
    
    Пока то каких-то фатальных блокировок, тем более whitelist, в РФ нету.
    Обфускация у меня что в GoVPN, где даже есть режим без использования
    шифрования, что в других проектах -- чисто любопытство.
    
    В любом случае спасибо за предложения! Я был удивлён насколько
    github.com/go-gost/gost развился, ведь когда-то я видел его прям в
    зачаточном состоянии. Но мне хочется чисто only lightweight obfuscation,
    ничего сложнее. Возможно даже go-gost даже по легковесности
    алгоритма/протокола бы удовлетворил, но вот просто даже лень копаться в
    документации и искать это :-)
    
    >Всех благ.
    
    И вам!
    
    комментарий 2:
    From: kmeaw
    Date: 2023-08-17 23:42:40Z
    
    > Не даёт скачать, нет ссылки. Думаю что требует JavaScript.
    
    У меня сработал
    https://github.com/Andrew-J-Larson-Alt/mediafire-direct/raw/main/!-bash-script/mediafire-direct.sh
    
    комментарий 3:
    From: Sergey Matveev
    Date: 2023-08-18 08:01:58Z
    
    *** kmeaw [2023-08-18 00:37]:
    >У меня сработал [...]
    
    mediafire сайт не даёт ссылок на этот скрипт/проект. Я про него ничего и
    не знаю (если предполагалось что это нечто также известное как и YouTube,
    для которого тоже свои скачивалки есть).
    
    Скрипт... просто ужас :-). Во-первых, bash (который по умолчанию даже на
    Debian не ставится). Во-вторых, первым делом он лезет в google.com...
    чтобы проверить есть ли Интернет соединение. Просто даже не понимаю:
    какая взаимосвязь между google.com и mediafire сайтами? А если
    google.com не работает, а mediafire будет? А если наоборот? О чём думал
    автор? Сделав zsh mediafire-direct.sh скрипт в итоге смог скачать этот
    файлик, хотя grep мне выдал несколько раз: "grep: Warnung: überzähliges
    vor /", хотя при этом у меня в PATH-е GNU Grep стоял. В общем, ужас.
    Просто к слову :-)
    
    Что касается oilandfish, то это прям классический сайт про кучу всяких
    Tor/8.8.8.8-like решений для обхода цензуры. Мой cypherpunks.ru когда-то
    тоже из этой серии предполагался быть и частично был, но сейчас
    кардинально иной взгляд на все эти вещи. А oilandfish вообще первой
    ссылкой про политику начал объяснять. В общем, задачи подобных проектов
    (Tor и рядом с ним) -- не для меня.
    
    комментарий 4:
    From: John Doe
    Date: 2023-08-21 20:57:45Z
    
    Добрый день, ссылка утягивается wget-ом, файл переименуйте в .tar.gz
    потом.
    https://file.io/k6606j3Izkrw
    
    Great firewall насколько я понял начинает резать активные ssh
    соединения, когда становится понятно, что идет много трафа, и это
    видимо туннель, посредством замедления. Где читал, уже не помню.
    Но надеяться только на статику, что будет как whitelist без динамики
    получается однобоко.
    
    Есть еще такой ресурс https://github.com/net4people/bbs/issues
    
    Всех благ.
    
    комментарий 5:
    From: John Doe
    Date: 2023-08-21 21:10:01Z
    
    https://file.io/NlkVq7a4l2Z8
    https://file.io/ZJAufEv54lrM
    
    Ссылки одноразовые.
    
    комментарий 6:
    From: Sergey Matveev
    Date: 2023-08-21 21:11:56Z
    
    *** John Doe [2023-08-21 20:57]:
    >ссылка утягивается wget-ом, файл переименуйте в .tar.gz потом.
    
    Говорит 404, не найден. В любом случае, с комментарием с bash-скриптом я
    смог скачать тот архив. Равнодушен к той информации :-)
    
    >Но надеяться только на статику, что будет как whitelist без динамики
    >получается однобоко.
    
    Просто не хочу и не собираюсь играть во все эти кошки мышки. Или нам
    дают возможность между нашими компьютерами обмениваться данными, или нам
    дают возможность удалённого доступа до ряда ресурсов/служб. Где-то
    возможно есть поломанная связанность (ведь между Cogent и Hurricane
    Electric вообще на глобальном уровне нет IPv6 связанности) -- это ещё
    можно обходить.
    
    >Есть еще такой ресурс https://github.com/net4people/bbs/issues
    
    Понятно. В любом случае, ничто из этого не позволяет мне решить мою
    простую задачу (или надо вчитываться внимательно в документацию всяких
    этих проектов).
    
    комментарий 7:
    From: Sergey Matveev
    Date: 2023-08-21 21:34:20Z
    
    *** John Doe [2023-08-21 20:57]:
    >посредством замедления
    
    Кстати, тоже видел упоминания о том, что соединения не режутся
    полностью, а замедляются до 64Kbps. Вообще-то про себя я при этом думал
    и продолжаю думать: лично мне бы этого было бы достаточно. Для общения,
    для новостей, для RSS и чтения статеек из них, для обмена патчами,
    git-ом: этой скорости достаточно. Я ради любопытства (хотя я прекрасно
    помню времена и модемов, и GPRS и 128Kbps ADSL Интернета) несколько лет
    назад урезал себе трафик чтобы оценить user experience
    (de75e479db454b88a42096f2ff5e1538c513e919), а также сидел через COM-порт
    (правда на 115200bps) -- вполне себе.
    
    Да, для большинства, понимаю, это более чем неприемлемо будет, ибо
    объёмы JavaScript, да даже того же CSS умопомрачительные. Да и hi-res
    фотографию не передать быстро.