Простите, возможно не по теме немного, но подозреваю козни РКН. Есть мобильное приложение, до сегодняшней ночи работало все нормально, с ночи на разных провайдерах начались отвалы по таймауту. Причем рост ошибки с полуночи на разных версиях приложения, в т.ч. и совсем старых. На части провайдеров проблемы возникли не сразу, только к обеду. Через vpn приложение работает отлично.
От того к какому ip подключиться пытается приложение не зависит ничего. Что странно - проблема и для прода и для стейдж сервера воспроизводится. Сервера за cloudflare стоят.
Сама ошибка java.net.SocketTimeoutException: SSL handshake timed out
at com.google.android.gms.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
Caused by: android.system.ErrnoException: isConnected failed: EHOSTUNREACH (No route to host)
at libcore.io.IoBridge.isConnected(IoBridge.java:275)
Сниффер показывает следующее
Еще дополню - что в браузере при этом страничка расположенная по адресу сервера прекрасно открывается. И можно get запросы из браузера подергать - отдаются.
Стоит создать отдельную тему.
Через Globalcheck блокировки не видно.
Есть ответ сервера. Значит SNI не вызвал реакции. Если это был TLSv1.2 возможно блокировка по сертификату. При наличии SNI, возможно это что-то новенькое.
Да вот сертификат для проверки всякого странного тоже меняли. Что интересно - отвал у части провайдеров был постепенный. Мы там два сервера используем, один для статики, другой для апи. И сначала отвалилась статика, потом апи (хост адреса у них разные), при том что http клиент одинаково сконфигурированный использовался. При этом, повторюсь, через vpn все работает отлично, и сам api.author.today отлично открывается в браузере, что прям странно. Да и в списках reestr.rublacklist.net нас нет вроде.
Выложьте pcap
dump.pcap (7 КБ)
Конкретно на этом девайсе api.author.today работать начал, а вот на других девайсах по прежнему не работает. При том что это одна сеть. Но вот cm.author.today по прежнему те же признаки показывает. Выложил pcap.
Хотя вру немного. Если раньше хоть какие то ответы от сервера прилетали, сейчас к сожалению перестали, соответственно выше файл уже без ответов(( Фильтр в capture options по host, он по идее и на source и на destination смотрит.
dump2.pcap (3,0 КБ)
Снова с api стало повторяться, и с ответом уже в этот раз. Прикрепил второй файл.
Блокируют Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f), если он стоит на 4 месте в списке ciphersuites, в сочетании еще с каким-то фактором, в сторону IP-адресов Cloudflare.
Независимо от домена, похоже.
Репродьюсер (нужен curl с openssl)
curl -v https://bo0om.ru --tls-max 1.2 --ciphers ECDHE-RSA-AES128-GCM-SHA256
Угу, действительно, спасибо! Поменял cipherSuites - блокировка пропала.
Да, наблюдаем недоступность хостов за Cloudflare если доступ осуществляется через CURL/libcurl с дефолтными настройками под Windows(бекенд SChannel).
Началось у пользователей в 27.03.2024 00:00 UTC+3 с резким скачком вверх в 31.03.2024 00:00 UTC+3
del
не только на ip cloudflare, даже на зеркалах cloudflare воспроизводится
upd: а точнее на тех, где используется стандартный сертификат google trust services, на домен www.speedtest.net у меня блока нет (там другой сертификат)
В жертвы также можно записать: Parsec, ShareX, авторизация (по меньшей мере в Twitch) в OBS
Роскомнадзор в очередной раз умудрился поблочить половину сети.
пробуй решение Вся информация касательно бана Bancho · forum | osu!
В тот же вагон: разбирался в чем проблема с Plex, и нашел такую закономерность:
Если в cloudflare принудительно отключить TLS v1.3 для своего домена, то в Firefox сайт перестает открываться 
Но при этом конкретно Plex не открывается ни в Firefox, ни в Safari, ни в Chrome
Это моё решение для кастомного лаунчера финалки, да 
Увы, но сработает только в ситуациях когда используется виндовый http стек. В том случае был дотнет с принудительным даунгрейдом до TLS 1.2 перед запросом
Перепечатаю сюда на всякий, коль народ сюда тоже отправляют:
Как без использования VPN временно обойти ошибку лаучнера “XIVLauncher failed to check for updates”/сломанное меню плагинов даламуда:
- Открыть Powershell из под админа
Disable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256Это отключит один из наборов шифров TLS (Cipher suite - Wikipedia), что потенциально может что-нибудь сломать (а может и не сломать). Не думаю что это может создать какие-нибудь проблемы в безопасности, так как этот набор не в списке рекомендуемых (но все еще в списке безопасных)
Откатить всегда можно следующей командой:
Enable-TlsCipherSuite -Name TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ShareX и OBS это помогло. Но не Parsec’у, т.к. он, скорее всего, запросы делает альтернативными путями
Поправка по датировке: первый случай зафиксирован в 21.03.2024 08:55 UTC+3 у провайдера Ростелеком
vrchat.com туда же
Аналогично: cloudflare, но при этом сертификат не от GTS а от LE. Тоже отключен 1.3 на стороне CF.
А для vrchat.com есть решение помимо VPN? Пробовал отключать шифр TLS как в примере выше, но не помогло.
del
Странно, что TLS Server Hello в принципе дошёл при блокировке какого-то алгоритма.
Судя по всему, блокировка возникает только если в TLS Server Hello указан запрещённый Cipher Suite
curl -v https://bo0om.ru --tls-max 1.3 --ciphers ECDHE-RSA-AES128-GCM-SHA256 - подключает
curl -v https://bo0om.ru --tls-max 1.2 --ciphers ECDHE-RSA-AES128-GCM-SHA256 - не подключает
Вы проверяли используемый в результате шифронабор через дамп или из репорта curl в строчке: SSL connection using TLSv?
There are new ciphersuites that only work in TLSv1.3. The old ciphersuites cannot be used for TLSv1.3 connections and the new ones cannot be used in TLSv1.2 and below.
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
А да, странно что curl в принципе не выкинул ошибку
Оставил сообщение на форуме cloudflare: https://community.cloudflare.com/t/russia-blocks-tls-v1-2-requests-to-cloudflare-edges/636460
Причина, похоже, всё же не совсем в cipher’ах. Наиболее вероятно то, что цензурирующей системе не нравится что-то в ответе сервера, а не в запросе клиента. Я воспроизвёл проблему на своём сервере (не IP Cloudflare), проксируя запросы к Cloudflare.
Это объясняет, почему с TLS 1.3 нет проблем (у TLS 1.2 и 1.3 ответы прилично различаются), и почему изменение Cipher’ов исправляет проблему (ответ сервера меняется, возможно, просто сравниваются определённые байты на определённых местах). Кроме того, проблема не проявляется при подключении к community.cloudflare.com, а там используется другая цепочка сертификатов.
Поотлаживайте, у кого есть время и желание.
Вероятно проблема не в фильтрации Client Hello, а в фильтрации Server Hello. Когда в нем первым шифром идет ECDHE-RSA-AES128-GCM-SHA256 - соединение блокируется. Для TLSv1.3 шифры другие поэтому и проблема исчезает.
Поэтому изменение порядка шифров тоже может излечить проблему при условии что CF выбирает первый поддерживаемый из списка.
Кажется, заработало. vrchat.com и app.plex.tv начали открываться сами по себе.
Ага, похоже откатили. У нас прошлые версии приложения тоже заработали.
Да, начали поэтапно откатывать начиная с 18:10 UTC+3
del
Это была сигнатура для Lantern. Сервера опознают по шифру, количеству сертификатов в цепочке и возможно их размеру. УЦ разные, к ним привязки нет. Результат вы видели.