@mp4treiser Так а в результате то запустил или как ?
HTTP/3 Работает :D
-
@sergerdn said in HTTP/3 Работает :D:
-
Connectionless Protocol: UDP is a connectionless protocol, which means that each packet is sent independently and there is no inherent order or reliability to the delivery of packets. This makes it more difficult to track and route packets in a proxy environment.
-
Statelessness: UDP is stateless, which means that there is no inherent state information maintained between packets. This can make it more difficult to track and manage packets in a proxy environment.
-
Low-Level Protocol: UDP is a low-level protocol, which means that it operates closer to the network layer of the OSI model. This can make it more difficult to intercept and modify packets in a proxy environment.
All of these factors make proxying UDP traffic a more challenging task than proxying TCP traffic. While it is possible to proxy UDP traffic, it often requires specialized knowledge and techniques to overcome these challenges.
ну да понимаю, продавцам тяжелее будет, нежели чем для себя поднять. Сначала надо проверить конечный ПК юзера, есть ли у него белый ip или нет. В зависимости от этого пойдут 2 ветки логики )) Потом еще гемор с подсчетом соединений )) в TCP это легко, по кол-ву соединений, а в UDP пинг нолевой всегда и соединения мгновенные, а то как ограничивать всех то )
-
-
@FastSpace said in HTTP/3 Работает :D:
ну да понимаю, продавцам тяжелее будет, нежели чем для себя поднять. Сначала надо проверить конечный ПК юзера, есть ли у него белый ip или нет. В зависимости от этого пойдут 2 ветки логики )) Потом еще гемор с подсчетом соединений )) в TCP это легко, по кол-ву соединений, а в UDP пинг нолевой всегда и соединения мгновенные, а то как ограничивать всех то )
Не будут ничего продавцы прокси ничего делать. Даже пытаться не будут, так как слишком сложно.
У поставщиков софта для DPI(Deep Packet Inspection) есть простое решение проблемы - просто блокировать этот протокол, так как у них нет решения по анализу пакетов и, когда будет, никто не говорит. -
@sergerdn said in HTTP/3 Работает :D:
@FastSpace said in HTTP/3 Работает :D:
ну да понимаю, продавцам тяжелее будет, нежели чем для себя поднять. Сначала надо проверить конечный ПК юзера, есть ли у него белый ip или нет. В зависимости от этого пойдут 2 ветки логики )) Потом еще гемор с подсчетом соединений )) в TCP это легко, по кол-ву соединений, а в UDP пинг нолевой всегда и соединения мгновенные, а то как ограничивать всех то )
Не будут ничего продавцы прокси ничего делать. Даже пытаться не будут, так как слишком сложно.
У поставщиков софта для DPI(Deep Packet Inspection) есть простое решение проблемы - просто блокировать этот протокол, так как у них нет решения по анализу пакетов и, когда будет, никто не говорит.Хорошая универсальная проверка для отсева ботов.
-
@FastSpace said in HTTP/3 Работает :D:
Хорошая универсальная проверка для отсева ботов.
Чушь. Я сижу за обычным роутером, обычные браузеры, почти все, две системы и мак и винда, все по http 2.0 по твоей проверке. И чё? Меня кто-то банит?
В любом деле есть избыточность рвения и достаточность. Не в обиду, но есть такая русская поговорка - заставь дурака богу молиться, он и лоб расшибет...
А ещё есть в психиатрии понятие - мания приследования 😁 ну не обижайся. Это так к слову.
-
@Bigma said in HTTP/3 Работает :D:
@FastSpace said in HTTP/3 Работает :D:
Хорошая универсальная проверка для отсева ботов.
Чушь. Я сижу за обычным роутером, обычные браузеры, почти все, две системы и мак и винда, все по http 2.0 по твоей проверке. И чё? Меня кто-то банит?
В любом деле есть избыточность рвения и достаточность. Не в обиду, но есть такая русская поговорка - заставь дурака богу молиться, он и лоб расшибет...
А ещё есть в психиатрии понятие - мания приследования 😁 ну не обижайся. Это так к слову.
Ты это образец для мерила 😁, ведь у нас в стране каждая домохозяйка кастомит роутер, а сверху систему. Да ещё скриптики сверху написывает.
Ты не забывай, что 1 проверки недостаточно, а вот двух уже да. UDP, DRM, ну и моник чекнуть наличие. Все 3 фейла, бот
-
@FastSpace а зачем тебе две если одной достаточно - она однозначна, а вторая сомнительна, и может привести к ложным срабатываниям...
-
@FastSpace said in HTTP/3 Работает :D:
Ты не забывай, что 1 проверки недостаточно, а вот двух уже да. UDP, DRM, ну и моник чекнуть наличие. Все 3 фейла, бот
Я думаю, что в реальной жизни все проще. Так как работает машинное обучение с подкреплением на стороне антифрода, а вот это решение уже может легко пометить всех пользователей без QUIC как подозрительных. Так как по другим показателям среди таких пользователей, к примеру, 70% фродеры.
Мое мнение - да, проблема есть. И, вероятно, проблема серьёзная. -
@Bigma said in HTTP/3 Работает :D:
@sergerdn я зашел с мобилы с chrome браузера с мобильного интернета - на данную ссылку, и у меня выдает что нет поддержки квика, перезагрузил страницу, тоже самое - я бот ?
Я этого не говорил. А говорил, что отсутствие поддержки QUIC может свидетельствовать о том, что ты подозрительный, а в совокупностями с другими признаками, с точки зрения машинного обучения, пометить тебя как бота.
Вроде на одном языке говорим, а такое непонимание. -
@Bigma said in HTTP/3 Работает :D:
@sergerdn может лет через 10 это и можно будет использовать однозначным способом, а пока это лишь технология, которая мало ещё поддерживается. Вот как клаудфлер начнет пинать по этому признаку, вот тогда это звоночек 🧐
Можно не гадать, сам Cloudflare дает статистику и тенденция заставляет напрягаться.


-
@Bigma said in HTTP/3 Работает :D:
@sergerdn я зашел с мобилы с chrome браузера с мобильного интернета - на данную ссылку, и у меня выдает что нет поддержки квика, перезагрузил страницу, тоже самое - я бот ?
Ссылка тестовая и нужно сначала разобратся как работает. Если начать детектить UDP это будет сделано без той ссылки.
-
@FastSpace по тенденции, которая по статистики Клауда есть ещё как минимум три года, хотя все стремительней развивается технологии... Но это не касается РФ. А свои фермы вы очевидно в РФ тюнити...
-
@FastSpace ты смотрел слив по Яше? Там очень все забавно 🧐
-
Решил не создавать новую ветку и написать сюда.
Целью данного сообщения является демонстрация способа определения поддержки протокола QUIC браузером со стороны антифрод систем очень незаметно для пользователя. Так как факт проверки не будет виден в developer tools Chrome, потому что сайт не доступен по протоколу QUIC.
Множество подробностей реализации я опускаю ради упрощения. Описываю ниже возможную(я ее протестировал) логику реализации такой проверки.
Подготовка на стороне сервера:
- Веб-сервер (в моем случае nginx, но можно использовать любой).
- Инструмент для мониторинга и захвата UDP-пакетов с признаками QUIC (в моем случае, собственное решение на базе eBPF/pcap). Альтернативы: стандартный tcpdump или Wireshark.
Основная логика:
- При первом запросе страницы отправлять специальные заголовки Alt-Svc и Critical-CH.
- В ответ на это, браузер (Chrome) попытается установить QUIC-соединение перед повторным запросом страницы. Повторный запрос страницы Chrome делает потому что получил заголовок Critical-CH.
- К моменту повторного запроса на сервере уже известно, был ли отправлен UDP-пакет с QUIC-признаками.
Последовательность работы Chrome:
- Исходный запрос страницы.
- Попытка установления QUIC-соединения.
- Повторный запрос страницы.
Теоретически, существует вероятность, что QUIC-пакет не успеет дойти до сервера до повторного запроса, но это маловероятно и решаемо.
Дополнительно для браузеров без поддержки Critical-CH или для надежности можно использовать внутренние редиректы, чтобы браузер успел отправить QUIC пакет к моменту анализа на сервере.
В качестве побочного эффекта можно также относительно незаметно получить реальный ip пользователя, если он использует прокси, не отключил QUIC, и устанавливает прокси в браузер стандартным способом. BAS этому не подвержен.
Выводы:
Всем капец 😁
P.S.
Стал собирать статистику по поддержке протокола QUIC в живой природе. Предварительные результаты не утешительные. Я давал выше ссылку на анализ Cloudflare. Cloudflare мягко говоря немного манипулирует статистикой, так как не дает данных в разрезе операционных систем и версий браузеров. Если выкинуть старые версии браузеров и операционных систем, то будет совсем другая история.P.P.S
Может быть добавлю позже статистику, что сейчас собирается на трафике у меня. -
@sergerdn Ты как обычно всё усложнил. На гитхабе питон готовый лежит на 20 строк по проверке UDP у прокси. Ищи называется udp_check.py
Там можно обратится как по IP, так и по hostname. Выяснилось что тот же говно 3proxy не умеет по домену, только в последнем мастере починили, а его скачать не смогут многие. Остальные вещи зараза вообще отказался фиксить. В топку этот 3proxy так что -
@sergerdn said in HTTP/3 Работает :D:
В качестве побочного эффекта можно также относительно незаметно получить реальный ip пользователя, если он использует прокси, не отключил QUIC, и устанавливает прокси в браузер стандартным способом. BAS этому не подвержен.
Потому что
Браузер должен уметь слать UDP вносокSocks5. Это не умеет делать Chrome, Firefox и прочие браузеры реальные. Это даже не умеют антики и конкурент на букву з. Бас тут топчик.Это не всё еще. Сервер с прокси тоже должен на своей стороне отправлять такие пакеты не мимо прокси. Горе подниматели с 3372 и тут накосячат.
-
@FastSpace said in HTTP/3 Работает :D:
@sergerdn Ты как обычно всё усложнил. На гитхабе питон готовый лежит на 20 строк по проверке UDP у прокси. Ищи называется udp_check.py
Нет у меня цели проверить работает ли прокси по UDP, а цель предупредить, что сайт может делать "скрытую" проверку браузера на наличие поддержки QUIC. В связи с твоим комментарием отредактировал свой пост, чтобы было более четко и яснее.
@FastSpace said in HTTP/3 Работает :D:
Браузер должен уметь слать UDP в носок Socks5. Это не умеет делать Chrome, Firefox и прочие браузеры реальные. Это даже не умеют антики и конкурент на букву з. Бас тут топчик.
BAS использует стороннюю библиотеку туннелирования трафика(правда очень древнюю). Каждый так может, почему не делают - вопрос другой. Вероятно, потому что не знают, что нужно.
Можно делать следующий хак, когда разработчики антиков забивают на запросы от пользователя:
- заменить исполняемый файл Chrome в антике на свой, предварительно переименовать оригинальный файл
- свой файлик при запуске парсит параметры командной строки и запускает оригинальный файл Chrome антика с какими угодно параметрами, какими угодно плюшками сбоку, включая туннелирование трафика всего процесса Chrome, установку переменных окружения, etc.
Пример, что может делать кастомный Chrome.exe, чтобы запускать оригинальный файл:
proxy_tunnel_program.exe --proxy=socks://127.0.0.1:3223 chrome_original.exe --profile-directory=Buu ....Я так делал в незапамятные времена с Multilogin. Думаю, что будет работать и сейчас.
-
@FastSpace said in HTTP/3 Работает :D:
Выяснилось что тот же говно 3proxy не умеет по домену, только в последнем мастере починили, а его скачать не смогут многие. Остальные вещи зараза вообще отказался фиксить. В топку этот 3proxy так что
Есть rfc9298, который вводит новый стандарт для проксирования QUIC трафика.
Несмотря на то, что есть готовые библиотеки для протокола(quiche) с вообщем-то довольно простым API, вероятно, ready to use решений мы увидим весьма не скоро.
Причина отсутствия готовых продуктов простая. Разработчики могут в 20 строк кода набросать SOCKS5 прокси, так как за них всю работу делает TCP, а вот в случае с QUIC(UDP) все уже сильно сложнее и строк надо 2К.
Можно немного почитать еще тут - https://blog.cloudflare.com/unlocking-quic-proxying-potential/
Наверное, на данный момент единственное решение это вставлять мобильный модем в сервер, там поднимать прокси, который не сильно разбирается что за трафик он проксирует. А связь с клиентом делать с помощью чего-то вроде Tailscale, так как он работает на уровне IP. Будет что-то вроде локальной сети, чтобы UDP трафик ходил в любые стороны между прокси и клиентом.
Я думаю, что люди так и делают. Сам лично НЕ делал. Немного раздражает, что прокси-сервисы забили один большой инструмент на пользователей. Но что делать - такова реальность.
Возможная архитектура для поставщиков прокси:
- Выходная нода(где трафик ходит в Интернет) -> IP туннель как backconnect к серверу.
- клиент прокси сервиса -> распаковка SOCKS5(проверка прав доступа, etc) -> заворачивание трафика в IP туннель до выходной ноды