Загадочные проблемы браузинга: почему некоторые сайты не грузятся в Chrome?

в 15:15, , рубрики: chrome, CloudFlare, dpi, ech, HTTPs SVC, wireshark, блокировки, не открывает сайт, ркн, системное администрирование

Привет!

Меня зовут Эрик, в данный момент я инженер технической поддержки в компании Shortcut. Недавно я столкнулся с интересным тикетом: пользователи жаловались, что некоторые сайты не открываются в Google Chrome, но при этом прекрасно работают в других браузерах.

Кажется, что если сайт работает в одном браузере, он должен работать и в другом. Но это не всегда так. Иногда Chrome упорно отказывается загружать страницы, которые спокойно открываются в Firefox или Edge. Недавно я столкнулся с таким случаем в работе и хочу рассказать, как я разобрался с проблемой.

Именно так выглядел тикет!

Некоторые сайты, такие как:

…не открываются в Google Chrome. Количество таких сайтов со временем увеличивается. Проблема проявляется в связке Cеть компании + DNS SkyDNS + Google Chrome. В других браузерах, например, Firefox, сайты открываются. Просим выявить причину проблемы и устранить её, так как пользователи используют Google Chrome.

Клиент обращался в техническую поддержку SkyDNS, а также к провайдеру, но это не принесло результатов – никто не смог помочь.

Первичный анализ

Траблшутить проблему начал с банальных вещей: естественно, проверил, какой ответ отдаёт DNS-сервер, выполнил ping до полученных адресов, проверил их доступность. Понятно, что эти действия сами по себе бессмысленны, так как сайт открывается в другом браузере, но некоторые вещи делаешь на автомате.

На этом этапе проверил IP-адреса, которые отдаёт DNS сервер — они оказались принадлежащими Cloudflare. Также в DNS-ответе для каждого из сайтов были IPv6-адреса. Небольшой поиск в интернете показал, что Chrome по умолчанию отдаёт предпочтение IPv6-адресам, и это натолкнуло меня на мысль проверить, что будет, если добавить в hosts IPv4-адреса вручную. Ведь hosts — это первое место, где ПК ищет соответствие домена и IP.

И вуаля — сайт открылся в Chrome!

Казалось бы, проблема найдена: Chrome выбирает IPv6-адреса вместо IPv4, а поскольку в сети не используется IPv6, сайты не загружаются. Однако другие сайты, которые также используют IPv6, открываются в Chrome без проблем. Значит, проблема не в IPv6.

Дальше я предположил, что Chrome выполняет дополнительные действия перед установлением соединения, и эти действия, скорее всего, связаны с DNS, так как сайт открывается при наличии записи в hosts. Для того чтобы выяснить, что именно происходит, я решил снять дампы трафика и проанализировать их.

Анализ дампа трафика, в чем проблема?

Исследование трафика при запросе в Firefox

В дампе, собранном при использовании Firefox, всё достаточно обычно: происходит запрос ресурсных записей типа A и AAAA (рис.1), после чего устанавливается соединение с использованием QUIC и TLS 1.3 (рис.2).

Рис.1 - Firefox DNS запросы A и AAAA записей.

Рис.1 - Firefox DNS запросы A и AAAA записей.
Рис.2 - Firefox использует QUIC и TLS1.3

Рис.2 - Firefox использует QUIC и TLS1.3

Исследование трафика при запросе в Chrome

Анализ дампов трафика в Wireshark показал, что Chrome перед установкой соединения запрашивает не только A-запись, но и HTTPS-запись (RFC 9460). Этот тип записи содержит параметры для установки HTTPS-соединения (Рис.3), в том числе Encrypted ClientHello (ECH) — механизм, который Роскомнадзор блокирует.

Подробнее про ECH

Encrypted ClientHello (ECH) — это механизм, который скрывает имя запрашиваемого сайта (SNI) в зашифрованном виде.

Зачем это нужно?

Обычный TLS (HTTPS) передаёт имя сайта открыто в поле SNI (Server Name Indication). Это позволяет провайдерам и государственным системам слежения (например, DPI) видеть, какой сайт ты посещаешь, даже если соединение зашифровано.

Как работает ECH?

1. Браузер запрашивает специальную HTTPS-запись (SVCB) у DNS.

2. В ответе DNS содержится публичный ключ сервера для шифрования ClientHello.

3. Браузер шифрует ClientHello и отправляет его на сервер.

4. Провайдер не может увидеть, какой сайт ты открываешь, так как данные уже зашифрованы.

Роскомнадзор использует DPI (Deep Packet Inspection) для анализа трафика и блокировки запрещённых сайтов. С ECH этот анализ становится невозможным, так как DPI не видит доменное имя.

Рис.3 - Chrome запрашивает HTTPS SVC-запись

Рис.3 - Chrome запрашивает HTTPS SVC-запись

Также в дампе были замечены множественные TCP Retransmission, что может указывать на блокировку посредством DPI (Рис.4).

Рис.4 - Chrome TCP Retransmission.

Рис.4 - Chrome TCP Retransmission.

Подтверждение версии о блокировке посредством DPI

Чтобы подтвердить данную версию, мы создали на MikroTik правило для заворачивания трафика до конкретного сайта в VPN-туннель. И вуаля — сайт стал открываться в Chrome.

Вывод: проблема в блокировке ECH

Firefox, скорее всего, не поддерживает Encrypted ClientHello (ECH) по умолчанию, поэтому сайты открываются без проблем. В то время как Chrome запрашивает записи HTTPS , так как это часть его алгоритма оптимизации соединений и поскольку Cloudflare предоставляет поддержку ECH своим пользователям, это приводит к возникновению проблем.

Так как ECH блокируется в России, я попробовал отключить его в Chrome. В версиях Chrome с 105-121 эта опция находилась в chrome://flags/#encrypted-client-hello. В более новых версиях (121+) её убрали из экспериментальных функций и сделали нативной, но её можно отключить через системные параметры.

Решение: отключение ECH

В Windows откройте реестр и перейдите в:

HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome

Создайте параметр DWORD с именем EncryptedClientHelloEnabled и значением 0. Если ключей GoogleChrome нет — создайте их.

В macOS:

sudo defaults write /Library/Preferences/com.google.Chrome EncryptedClientHelloEnabled -bool false

В сети компании благодаря Ringo MDM коллегам удалось оперативно внести эти изменения на всех хостах, независимо от используемой операционной системы. После чего все сайты которые раньше не открывались в Chrome стали доступны.

Альтернативные способы решения

Отключение ECH — это одно из решений. Также можно попробовать:

  • Использовать VPN.

  • Переключиться на альтернативный браузер.

  • Использовать DNS резолвер без HTTPS-записей

Итог

Эта ситуация хорошо показывает, как иногда браузеры могут стать жертвами сетевых ограничений. Надеюсь, теперь у вас есть инструменты, чтобы разобраться, если столкнётесь с похожей проблемой. А вы встречались с чем-то подобным?

Буду рад услышать ваши мысли в комментариях! 🚀

Автор: erikguru

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js