Комментарии 50
Причина, похоже, всё же не совсем в этом. Наиболее вероятно то, что цензурирующей системе не нравится что-то в ответе сервера, а не в запросе клиента. Я воспроизвёл проблему на своём сервере (не IP Cloudflare), проксируя запросы к Cloudflare.
Это объясняет, почему с TLS 1.3 нет проблем (у TLS 1.2 и 1.3 ответы прилично различаются), и почему изменение Cipher'ов исправляет проблему (ответ сервера меняется, возможно, просто сравниваются определённые байты на определённых местах).
Тревожный сигнал. На этом фоне радует, что добавление ECH в openssl, кажется, сдвинулось с мёртвой точки.
Подключения с ECH уже полностью режут в Китае, и если я правильно помню, Роскомнадзор чем-то таким тоже баловался. Так что не сильно поможет.
Пока сайты с ECH - исключения, а не правило, возможно. Но надеюсь, что когда технология достигнет повсеместного внедрения, кишка заблокировать 80% интернета кое у кого всё-таки станет тонка.
QUIC вот в России работает. Именно в России на ВК. На сайты которые не в России - упс. Да, срабатывает fallback.
Вот чтобы было если бы fallback'а не было? решили бы блочить все равно?
Теперь, когда уже можно никому не объяснять основания блокировок (это я про ТСПУ), может быть что угодно. Но блокировка протокола HTTPS, из-за которой перестанут работать вполне легитимные сайты - это будет пробитие нового дна.
Самое что интересное:
в теме на ntc указано на каком сайте это поймали. Российская компания (ладно - ИП), намеренно старающаяся соблюдать законы. И все равно задело. Надо будет почитать реакцию аудитории (не очень то технически продвинутой в среднем) там если скажут _на сайте_ откуда были "сетевые проблемы".
сам ntc тоже НЕ открывается напрямую (ДомРу)
у многих мобильных приложений теперь при детекте впн (Adguard и прочие локальные VPN тоже считаются) - плашка про VPN и объяснение почем это ж очень очень плохо. Ну натренируют пользователей еще больше тупо не верить :(.
И все равно задело.
Не в первый раз уже. Но прошлые разы блокировками нас цепляло либо краем, только часть пользователей, либо относительно быстро откатывали, либо (когда один из ip выданных нам cloudflare в реестре оказался) решалось сменой ip.
Вот кстати что я больше опасаюсь что из-за каких то других причин вы блокировочный функционал Cloudflare начнете намного более жестко использовать. Потому что у меня ситуация когда я могу к вам в течении минут с IP нескольких разных стран стукнутся (при этом часть IP будут хостеров, при этом мобильное приложение будет вообще с других IP лезть, при этом к разным поддоменам - с разных) - вполне нормальная. Спасибо партии за это :(
при детекте впн (Adguard и прочие локальные VPN тоже считаются) - плашка про VPN
Вот точно! Заметил на приложении Мегафона и МТС. И ещё кто-то на Adguard ругается
Ну мобильные операторы логично ругаются, они не понимают настоящий ли пользователь входит в аккаунт, обычно заходим в личный кабинет через мобильный интернет и срабатывает автовход потому как все прозрачно и понятно для оператора..
А толку? У меня несколько номеров мегафона (причем не все симки - мегафон) и почти всегда - захожу через WiFi. Им не поже.
Ну и разумеется домашняя сеть сейчас интересно организована...пока что просто много чего улетает по разным критериям(Antifilter по BGP, ручные маршруты для блоков адресов, по DNS, по геопривязке адресов по мнению Maxmind, просто по автономкам, сеть просто в стадии перестройки) в VPN.
ВТБ ругается причем двумя путями:
если просто есть VPN (вообще любой) включенный но дает работать.
блокирующий экран с предложением отключить - это в случае когда до сервера не достучатся, реально не достучатся (если реально дело не в VPN - затем будет экран про недоступность сервера).
Пора иметь в качестве рабочей гипотезы, что дна нет.
Уже столько раз пробивали, что считать бесполезно.
Так они работать не перестанут же, ведь соединения без ECH всё равно будут приниматься для обратной совместимости. Будет ровно такая же ситуация как и с QUIC.
Поправьте меня, если я не прав - но имхо, какого-то прозрачного для пользователя фоллбэка там не предполагается.
Если клиент отправил в пакете ClientHello сообщение о том, что поддерживает ECH extension и со стороны сервера ECH реализован, дальнейший хэндшейк либо будет проходить с использованием ECH, либо соединение будет разорвано.
Ну да, поэтому либо клиент попытается установить соединение ещё раз, теперь без ECH, либо пользователь его удалит и перейдёт на более старую версию.
Потенциально есть еще вариант: клиент это Chrome, сервер это google.com/youtube.com или что-то еще такое. Перейти на старую версию можно..но через несколько версий можно получить от кучи сайтов требование обновить браузер. При этом если google.com не работает в новой версии Chrome - с точки зрения очень многих пользователей - виноват будет не гугл а провайдер, если провайдер начнет говорить что они не причем - очень быстро появятся публичные доказательства что без впн не работает а с впн работает а значит виноват НЕ гугл и провайдер нагло врет (даже если реально тут ТСПУ). Если упираться - будет очень публичный скандал (и заголовки будут "$ПровайдерName/РКН заблокировали Youtube хотя обещали этого НЕ делать"). А после этого - придется например блокировать еще и авито :), за рекламу услуг по по установки VPN. Ну и думаем что там за VPN будут :).
Если же клиент это Google Play Services - удачи откатывать вообщем. И заголовки будут про андроид целиком.
Осталось только, чтобы сайты его поддерживали, а я вот недавно оооочень долго искал сайт с ECH и нашел только тестовые варианты.
О, я в телевизоре))
З.Ы. Вообще печально конечно это все. По сути сутки приложение в РФ без vpn не работало (и старые версии до сих пор так и не работают, благо обновление в сторы быстро пропустили).
При том что аудитория у нас полностью русскоязычная только.
З.З.Ы. @ValdikSS спасибо конечно большое. Сами бы долго разбирались в чем причина.
Причина, похоже, всё же не совсем в этом. Наиболее вероятно то, что цензурирующей системе не нравится что-то в ответе сервера, а не в запросе клиента. Я воспроизвёл проблему на своём сервере (не IP Cloudflare), проксируя запросы к Cloudflare.
Это объясняет, почему с TLS 1.3 нет проблем (у TLS 1.2 и 1.3 ответы прилично различаются), и почему изменение Cipher'ов исправляет проблему (ответ сервера меняется, возможно, просто сравниваются определённые байты на определённых местах).
Хм, интересно что, конечно. Чую не последний раз что то такое происходит. В любом случае в следующей версии всё на 1.3 переведу. В тему на форуме еще постараюсь отписаться с дампом, кажется к другому серверу с сертификатом от let's encrypt и с измененными cipher'ами продолжает блочить.
Upd. А хотя, нет смысла выкладывать, если это именно в ответах сервера что то не нравится им. Их мы ведь не увидим в данном случае (доступа к серверу у меня нет).
Чувствую, мы идем к появлению целой новой отрасли мониторинга, пытающейся вычислить "что и как блокируется" в реальном времени.
А чем прикол делать такую блокировку? В мобилках она работает, потому что клиент выбирает указанный шифр как более оптимальный для слабых устройств.По идее можно его попробовать вообще на клиенте отключить.
Скорее всего целились в фингерпринт какого-то определенного приложения. Например, в Китае и Иране блокируют фингерпринт TLS-библиотеки языка Go, потому что на нём написаны популярные прокси-клиенты.
Что именно пытались заблокировать тут пока не понятно, возможно просто руки из жопы.
Отвалились впн.....следим за ситуацией
Какие именно?
Отвалились, но странно
Билайн, 2 телефона на андроид и комп с виндой
2 телефона подключаются к впн, но не резолвятся доменные имена, если отключить ВПН, зайти на ya.ru и включить обратно, все работает только для ya.ru
На Винде с ВПН все ОК.
Немного иначе с vds провайдера. На Винде все ОК, а на телефонах сайт iphoster.net не резолвится ни в какую. Только если использовать сторонний ВПН.
Обычный WireGuard(Нидерланды) пока работает... проблем нет )
У меня внезапно перестал работать speedtest-cli на windows. Если добавляю -vv, то он как раз пишет, что не может получить конфигурацию, которую хочет загрузить через cf из-за таймаута.
При этом всё остальное, включая утилиту для Linux, работает отлично
Не работало не только ночью, но и днём. Иногда помогала перезагрузка браузера, иногда приходилось открывать другой браузер. Причем на разных компьютерах могли работать разные комбинации
Также не было возможности использовать Parsec и для его работы требовалось отключить данный шифр:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Мы натолкнулись на эти грабли 1 апреля - перестал отвечать эндпоинт одного из клиентов. При этом по логам самого клиента - запросы до них даже не доходили. Подвисало на этапе TLS handshake с адресом как раз Cloudflare. Причем Cloudflare выдавал два разных IP по доменному имени. По одному из адресов коннект проходил, по другому нет. Сломали весь мозг совместно с саппортом клиента, в итоге решили, что виноват Clouflare и забили. А тут вон оно как обернулось.
Хабр тоже ее использует? У меня картинки с habrastorage перестали загружаться.
Тоже столкнулись с проблемой, не работало мобильное приложение на устройствах c Android 9 и ниже с ошибками SslHandshake и SocketTimeout. Началось 2024-03-31 08:00 (примерно), закончилось 2024-04-01 19:20 по мск.
Слушайте, трафик OpenVPN тоже стал блокироваться??
Примерно с того же срока перестало у NEWLINK работать, но пока работает на Skynet.
Пока решили с сетевиками через проксю пустить OpenVPN трафик.
Роскомнадзор, вероятно, начал блокировать подключения к Cloudflare по TLS fingerprint