Я нашел причину — Android-приложение meduza в режиме обхода блокировок обращается к Firebase (firestore.googleapis.com) при запуске.
Блокируют сочетание TLS ciphersuites + server_name + supported_groups средствами ТСПУ. Как я понимаю, оно стандартное, из Firebase SDK.
meduza-firebase.pcap (11.6 KB)
Столкнулся с той же проблемой. Заметил, что на некоторых операторах начали зависать обращения к firestore документам и отваливаться транзакции. Меняешь сеть или используешь vpn - проблема уходит. Налицо блокировки. Начал копать и разбираться. Приложение на Flutter. Работает нативно на android и ios, и есть web версия.
Любопытно, что на операторе, на котором нативные flutter (AOT) версии блокируются, web версия работает! Первое предположение было, что может как-то хитро разные IP используются, для натива и web, отсюда и разное поведение (с блокировкой и без) Забегая вперед - нет, IP адреса одинаковые. [64.233.165.95] Ну и это же логично, их же выдает DNS по UDP, а там user-agent’a нет.
Первое что потребовалось, это исключить влияние Flutter. Сделал тестовый проект на Android. Чистое Android приложение на kotlin с последними версиями библиотек - симптомы те же.
В логах немного разные ошибки в зависимости от провайдера, видимо зависит от того как провайдеры рубят коннекшен, или не рубят его. все не сохранилось, вот одна из них такая:
Caused by: io.grpc.StatusException: UNAVAILABLE: Channel shutdownNow invoked
Когда сеть без блокировок firestore работает по gRPC и создание документа выглядит так:
POST https://firestore.googleapis.com/google.firestore.v1.Firestore/Write HTTP/2.0
user-agent: grpc-java-okhttp/1.52.1
...
POST https://firestore.googleapis.com/google.firestore.v1.Firestore/Commit HTTP/2.0
user-agent: grpc-java-okhttp/1.52.1
...
Начал снимать TCP DUMP на разных провайдерах и анализировать их.
в том числе запечатлел нюанс, что web версия на “плохом” операторе работает и не блочится
tele2_not_blocked.pcap (9,8 КБ)
wifi_blocked.pcap (1,2 КБ)
web_wifi_not_blocked_long.pcap (13,4 КБ)
Обнаружил, что при handshake после “Client Hello” сервер не отвечает “Server Hello”. Handshake просто прерывается.
Далее начал искать по ключевым словам “Client Hello” и наткнулся на этот сайт и это обсуждение.
Надеюсь мои наблюдения будут полезны.
У меня два вопроса:
Дополню, сейчас речь об од wifi сети оператора ufanet, который блочит работу с firestore.
Но как было замечено, блочатся только наивные приложения android и ios (Flutter).
То же самое приложение запущенное в браузере, web версия (Fluter) - не блочится.
Девайс тот же самый, приложение нативное и web работает с одним и тем же firestore, сеть одна и та же.
пакет Client Hello для handshake собираются немного по разному:
сравнить весь кусок wifi_hello_native_and_web - Diff Checker
У вас в дампе подтверждение для “Client Hello” приходит через 0.3 мс. Подтверждал явно не сервер.
Можете показать дампы для iOS?
Так, я сейчас уехал из дома на квартиру, поэтому сеть другая.
Но dom.ru тоже блочит.
mac подключен проводом к роутеру. share internet через wifi.
ios подключен к маку по wifi на созданный hotspot
на маке запущен wireshark
ip срезолвился другой 209.85.233.95
дамп domru_widi_blocked_ios_through_mac.pcapng (15,5 КБ)
Интересно TLS_CHACHA20_POLY1305_SHA256 идет первым, хотя в коде grpc++ он третий. В сборке отдельно от SDK, он таки третий.
Причина в железе, run-time условие:
// Order the bulk ciphers. First the preferred AEAD ciphers. We prefer
// CHACHA20 unless there is hardware support for fast and constant-time
// AES_GCM. Of the two CHACHA20 variants, the new one is preferred over the
// old one.
железка была iPhone xs, iOS 16.7.1
В сети пишут, что начиная с 5 iPhone используемые процессоры имеют поддержку AES инструкций.
Но в BoringSSL по факту игнорируют эту поддержку. Можно при сборке отдельно включить, но тогда приложение может упасть на древних гаджетах, если поддерживаются.
То есть нет ситуации, что где-то есть пользователи у которых отсутствуют блокировки по причине железа, у всех будет едино. Но вот есть ситуация, когда невозможно воспроизвести блокировку вне блокируемой платформы, даже если можно собрать тот же код. Тот, да не тот.
Возможно я не до конца понял Вас, но вот мои наблюдения насчет устройств:
На всех наблюдаемых устройствах (и android и iOS) блокировка на “плохих” операторах присутствует, если запускать нативную версию приложения. Как Flutter так и обычные. А вот если запустить веб версию (Fluttre) приложения блокировки нет.
Если есть подозрения, что поведение может отличаться в зависимости от устройств, обоснуйте причины и я проведу серию тестов на устройствах, до которых могу дотянуться.
Если говорить про Apple оборудование, вот такие устройства есть рядом.
iphone xs
iphone 12
iphone 13 pro max
iphone 14
ipad pro (не M)
ipad air 4
Можно попробовать приложение еще на маке запустить
Android оборудование тоже есть разнообразное.
А если на уровне приложения задать прокси, то повляет ли это на модерацию приложения в Apple/Google? Не будет проблем с тем, что трафик проксируется?
У нас всё норм на обеих платформах прошло.
У меня на обеих платформах все норм. Крутится уже 2 недели, 4 апдейта
Можете пожалуйста привести пример кода для обеих платформ?..
А вообще возможно кто то на флаттер это реализовал, можете скинуть?
Там выше, на 15 дней назад необходимо ленту отмотать. Есть примеры кода
Медуза добавила новый способ обхода блокировок Важнейшее объявление: мы придумали еще один хитрый способ, помогающий читать «Медузу» в России без VPN. Мы называем его волшебным! — Meduza
Они используют для своих ссылок домен storage.googleapis.com
Ждем ответа от РКН
Товарищи, никто в последние 3 дня не сталкивался с проблемами доступа к firebase? Очень похоже, что опять началось. И обход со squid сервером перестал работать. Пока есть 2 пользователя Питер - Билайн, Екатерингбург - Теле2. VPN помогает.