HTTP/3 Работает :D

[FastSpace]

@Bigma said in HTTP/3 Работает :D:

@sergerdn я зашел с мобилы с chrome браузера с мобильного интернета - на данную ссылку, и у меня выдает что нет поддержки квика, перезагрузил страницу, тоже самое - я бот ?

Ссылка тестовая и нужно сначала разобратся как работает. Если начать детектить UDP это будет сделано без той ссылки.

[A Former User]

@FastSpace по тенденции, которая по статистики Клауда есть ещё как минимум три года, хотя все стремительней развивается технологии... Но это не касается РФ. А свои фермы вы очевидно в РФ тюнити...

[A Former User]

@FastSpace ты смотрел слив по Яше? Там очень все забавно 🧐

[sergerdn]

Решил не создавать новую ветку и написать сюда.

Целью данного сообщения является демонстрация способа определения поддержки протокола QUIC браузером со стороны антифрод систем очень незаметно для пользователя. Так как факт проверки не будет виден в developer tools Chrome, потому что сайт не доступен по протоколу QUIC.

Множество подробностей реализации я опускаю ради упрощения. Описываю ниже возможную(я ее протестировал) логику реализации такой проверки.

Подготовка на стороне сервера:

1. Веб-сервер (в моем случае nginx, но можно использовать любой).
2. Инструмент для мониторинга и захвата UDP-пакетов с признаками QUIC (в моем случае, собственное решение на базе eBPF/pcap). Альтернативы: стандартный tcpdump или Wireshark.

Основная логика:

1. При первом запросе страницы отправлять специальные заголовки Alt-Svc и Critical-CH.
2. В ответ на это, браузер (Chrome) попытается установить QUIC-соединение перед повторным запросом страницы. Повторный запрос страницы Chrome делает потому что получил заголовок Critical-CH.
3. К моменту повторного запроса на сервере уже известно, был ли отправлен UDP-пакет с QUIC-признаками.

Последовательность работы Chrome:

1. Исходный запрос страницы.
2. Попытка установления QUIC-соединения.
3. Повторный запрос страницы.

Теоретически, существует вероятность, что QUIC-пакет не успеет дойти до сервера до повторного запроса, но это маловероятно и решаемо.

Дополнительно для браузеров без поддержки Critical-CH или для надежности можно использовать внутренние редиректы, чтобы браузер успел отправить QUIC пакет к моменту анализа на сервере.

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

Выводы:

Всем капец 😁

P.S.
Стал собирать статистику по поддержке протокола QUIC в живой природе. Предварительные результаты не утешительные. Я давал выше ссылку на анализ Cloudflare. Cloudflare мягко говоря немного манипулирует статистикой, так как не дает данных в разрезе операционных систем и версий браузеров. Если выкинуть старые версии браузеров и операционных систем, то будет совсем другая история.

P.P.S
Может быть добавлю позже статистику, что сейчас собирается на трафике у меня.

[FastSpace]

@sergerdn Ты как обычно всё усложнил. На гитхабе питон готовый лежит на 20 строк по проверке UDP у прокси. Ищи называется udp_check.py
Там можно обратится как по IP, так и по hostname. Выяснилось что тот же говно 3proxy не умеет по домену, только в последнем мастере починили, а его скачать не смогут многие. Остальные вещи зараза вообще отказался фиксить. В топку этот 3proxy так что

[FastSpace]

@sergerdn said in HTTP/3 Работает :D:

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

Потому что
Браузер должен уметь слать UDP в носок Socks5. Это не умеет делать Chrome, Firefox и прочие браузеры реальные. Это даже не умеют антики и конкурент на букву з. Бас тут топчик.

Это не всё еще. Сервер с прокси тоже должен на своей стороне отправлять такие пакеты не мимо прокси. Горе подниматели с 3372 и тут накосячат.

[sergerdn]

@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 использует стороннюю библиотеку туннелирования трафика(правда очень древнюю). Каждый так может, почему не делают - вопрос другой. Вероятно, потому что не знают, что нужно.

Можно делать следующий хак, когда разработчики антиков забивают на запросы от пользователя:

1. заменить исполняемый файл Chrome в антике на свой, предварительно переименовать оригинальный файл
2. свой файлик при запуске парсит параметры командной строки и запускает оригинальный файл Chrome антика с какими угодно параметрами, какими угодно плюшками сбоку, включая туннелирование трафика всего процесса Chrome, установку переменных окружения, etc.

Пример, что может делать кастомный Chrome.exe, чтобы запускать оригинальный файл:

proxy_tunnel_program.exe --proxy=socks://127.0.0.1:3223 chrome_original.exe --profile-directory=Buu ....

Я так делал в незапамятные времена с Multilogin. Думаю, что будет работать и сейчас.

[sergerdn]

@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 туннель до выходной ноды

[FastSpace]

@sergerdn Уже есть все готовое.
Кроме QUIC в UDP есть еще WEB RTC. Это тоже надо проксировать правильно

[sergerdn]

@FastSpace said in HTTP/3 Работает :D:

@sergerdn Уже есть все готовое.

Где готовое есть? Для кого? Для поставщиков прокси? Они совсем разные бывают, есть и те, у кого выходные ноды и на мобилках под Андроидом, есть те, у кого и на Микротиках.

@FastSpace said in HTTP/3 Работает :D:

Кроме QUIC в UDP есть еще WEB RTC. Это тоже надо проксировать правильно

Если весь трафик завернут в тунель на уровне IP и прокси не разбирается что он проксирует, а просто меняет в пакете TCP/IP, UPD/IP адрес источника - все равно какой протокол.

Но это все теоретические. Если у тебя есть ссылки на готовые решения - я с удовольствием их почитаю, чтобы опять не изобретать свой велосипед.