Ограничение HTTP/3 (QUIC)

Заполнение нулями (наружное) QUIC initial триггерит блокировку. В Firefox такое применяется. В quictls внутренний с финальными 1200 байтами. В quiche – у меня нет данных (не собирается ржавчина).

Хаотичные зависания могут быть вызваны большими (1400+) QUIC пакетами в середине сеанса, которые триггерят блокировку. В моем случае это был механизм pmtud на QUIC клиенте, после отключения зависаний нет. К проблемам с mtu это не имеет отношения, блокировка по тестируемым парам адреса:порты наблюдается на хопе с ТСПУ.

У Firefox нет механизма pmtud, но он может быть на сервере.

UPD:
Большой размер пакета похоже так не важен, дело в другом.

Есть скрипт, который возможно воспроизводит блокировку.

Активация блокировки:
Запрос, ответ, запрос.
Нет ответа – нет блокировки.
Размер запросов и ответа учитывается, но точно неизвестно.

UPD: Код бредовый. Удалил. Вызывает блокировку потому что нарушает RFC.

Если удалить заполняющие нули из пакета от Firefox – блокировки нет, и есть реакция на SNI.
Это новое поведение или так было?

Под это правило могли попадать разные сценарии:

  1. Пробует расшифровать только если размер больше X, неудача=блокировка.
  2. Пробует расшифровать всегда, неудача=блокировка если размер больше X.

Действительно, зависаний сессии больше нет.
Сессия не зависает, если первым отправлять пакет с длиной 601 байт и “1” во 2-ом бите.

quicfix.bin (601 Bytes)

У меня работает такой обход

первым фейком, состоящим из нулей, пробиваем начальную проверку
далее при первом встреченном пакете с длиной >=600 и short header шлем произвольный фейк пакет тоже с short header , но другим connection id. далее можно ничего не слать, сессия похоже окончательно уходит в разрешенные

для такой хитрости сделал custom скрипт для zapret custom-nfqws-quic4all-tspu

Вариант без скриптов :

/opt/zapret/nfq/nfqws --qnum 210 --dpi-desync=fake --debug
/opt/zapret/nfq/nfqws --qnum 211 --dpi-desync=fake --dpi-desync-any-protocol --debug --dpi-desync-fake-unknown-udp=/opt/zapret/files/fake/quic_short_header.bin --dpi-desync-cutoff=d2
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:1 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 210 --queue-bypass
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m length --length 600:1500 -m u32 --u32 "0>>22&0x3C@8>>24&0xC0=0x40" -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 211 --queue-bypass

Спасибо anonymous32 за идею

На == 600 ТСПУ не переключает фазу проверки и ждет дальше.

Сперва у меня не получилось пробить висы лишь первым фейком.
Но я ошибся, использовал не тот параметр nfqws.
Все нормально. Достаточно вместо нулей послать первым фейком достаточно длинный пакет с short header. Нет нужды в дополнительных сложностях

Как-то так

nfqws --qnum=210 --user=daemon --dpi-desync-fwmark=0x40000000 --dpi-desync=fake --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_short_header.bin
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:3 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 210 --queue-bypass

В последней версии nfqws сделал по умолчанию quic fake , состоящий из 620 байт со всеми нулями, кроме первого байта - 0x40. Так что файл с содержимым пакета не нужен

Kathrin Elmenshort has done some tests and on Yota, at least, there seems to be a 2-layer filter.

https://github.com/net4people/bbs/issues/108#issuecomment-1115131376

One layer blocks all QUIC version 1, except to specific servers; and a second layer blocks QUIC version 1 with with specific SNI values, no matter the server.

The evidence for this comes from observing what happens when accessing different servers using different SNI values.

condition result
Access foreign server with correct SNI blocked
Access foreign server with vk.com SNI blocked
Access vk.com server with vk.com SNI works
Access vk.com server with www.facebook.com SNI blocked

и что как щас жить с этим, есть ли универсальное решение?
а то в браузерах то я отключил QUIC и стало норм, но не везде выходит его отключить, например в приложении спотифая никак, либо на телефоне в приложениях гугла

юзаю антизапрет на роутере через openvpn

как это на nft в openwrt будет выглядеть?

см тему whats new в разделе zapret. если руками то есть docs/nftables.txt

Сегодня на домру Ростов обнаружилась такая ситуевина.

google.com, youtube.com - quic нормально работает с curl и PC броузеров firefox, chromium (версия для Linux)
facebook.com - после пробоя блокировки TLS все то же самое, кроме chromium. С ним первый же quic initial блокируется. При попытке пробоя nfqws через fake ответ от сервера приходит, идет новый пакет от клиента, и дальше вис.

сам не проверял, но владелец подключения утверждает, что у него проблемы с quic с android/mac с броузера chrome на google.com. И для лечения он использовал nfqws, но неправильно, из-за чего он работал исключительно на блокировку QUIC. Без QUIC броузер довольно быстро выправлялся. А с ним, выходит, что застревал где-то посередине соединения. И на это жалуется не только он.

ТСПУ там тоже наблюдается. Одна из моих тор нод заблокирована. Но блокировка QUIC отличается от обычной для, скажем, tiera spb или мегафон спб.

Пробить facebook с PC хрома удалось через --dpi-desync=fake --dpi-desync-repeats=5.
То ли лимит на количество анализируемых пакетов у DPI, то ли размер буфера ограничен, но если за первые 5 пакетов бросать туда не QUIC, он отстает

Похоже, блокировка QUIC связана с попыткой блокировки программы Psiphon — она использует QUIC с разными версиями протокола и разными фингерпринтами, как один из методов обхода фильтрации.

Только вот Psiphon продолжает успешно подключаться через QUIC, хоть и не моментально, а браузеры — нет :smiley:

На моем провайдере tiera появился дополнительный DPI от gblnet
Обычный блокировщик и ТСПУ находятся на 5-м хопе.
gblnet-овский на 11м.

- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=3
[attempt 1] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 2] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 3] suspicious redirection 307 to : https://tiera.ru/blocked.php
UNAVAILABLE
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=4
[attempt 1] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 2] suspicious redirection 307 to : https://tiera.ru/blocked.php
[attempt 3] suspicious redirection 307 to : https://tiera.ru/blocked.php
UNAVAILABLE
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=5
[attempt 1] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 2] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 3] suspicious redirection 302 to : https://gblnet.net/blocked.php
UNAVAILABLE
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=6
[attempt 1] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 2] suspicious redirection 302 to : https://gblnet.net/blocked.php
[attempt 3] suspicious redirection 302 to : https://gblnet.net/blocked.php
UNAVAILABLE
..........
- checking nfqws --dpi-desync=fake,split --dpi-desync-ttl=11
[attempt 1] AVAILABLE
[attempt 2] AVAILABLE
[attempt 3] AVAILABLE
!!!!! AVAILABLE !!!!!

Что примечательно касаемо QUIC.
Похоже, что gblnet полностью блокирует QUIC initial пакеты на udp port 443 в stateless режиме вне зависимости от IP назначения.

Если я отсылаю сначала фейк с short header, потом initial, установив пакету ttl=8, например, то приходит TTL expired in transit. Начиная с 11 хопа не приходит ничего. То есть 5-й хоп пробивается с обычным DPI, но глобал блочит все.

Проверял на свою VPSку. initial не доходят вообще. если мешать с одним src_port, то short доходят все, initial не доходят

Как-то далеко. Есть признаки что это сеть провайдера, а не магистраль?
Может уровень супербосса блокировок достигли.

UPD:
По ссылке на сайте c блокировкой от gblnet картинка и телефон ООО “ЕТЕЛЕКОМ”, который входит вместе с ООО “ГЛОБАЛНЕТ” в холдинг ООО “ЕТ-ГРУПП”. При этом гендир у холдинга и ООО “ТИЕРА ЦЕНТР” один, но тиера не входит в холдинг.
Спецы вышли из чата, остались 1 гендир и 2 блокировщика.

11-й хоп 109.239.134.66

route: 109.239.134.0/24
descr: Butlerova7 P2P Customer Network
origin: AS31500
mnt-by: MNT-GLOBAL-NET

и редирект по http идет на сайт магистрала
получается магистралов подтянули к блокировкам

Еще немного подробностей
Что считается QUIC initial.

  1. udp_length >=1200
  2. Старший бит первого байта установлен (long header)
  3. Байты 1…4 uint32 в network byte order - это версия QUIC. Сечется IETF QUIC и некоторые чуть более старые версии драфта

Например, такой пакет : 80 00 00 00 01 00 00 … 00 (1200 байт)
уже не проходит

У firefox в initial используются лишь несколько сотен байт в начале, остальное - паддинг нолями. Если бы уменьшить размер UDP на передающей стороне , то оно бы прошло
chromium имеет склонность фрагментировать и раздувать до большого размера нешифрованный блок за счет паддинга и пинга, что приводит к увеличению длины используемого шифрованного блока