Короткий ответ
Да — браузеры по‑разному «ведут» TLS/SSL и HTTP‑сессию, и это вполне способно приводить к тому, что какие‑то middlebox/файрволы/WAF или плохо настроенный сервер начнут блокировать одни клиенты и пропускать другие. То, что удаление ряда заголовков в curl исправило 403, практически однозначно указывает на ошибочную/чересчур жёсткую логику на стороне сервера/прокси/фильтра, а не на «ошибку» стандарта.
Что именно различается (и почему это важно)
- TLS ClientHello (JA3/«TLS‑fingerprint»). ClientHello содержит список версий, шифров, кривых, расширений и их порядок — это даёт узнаваемый отпечаток (JA3). Разные браузеры имеют разные наборы и порядок -> разные JA3. DPI/WAF используют эти отпечатки для распознавания клиентов и VPN.
- TLS‑расширения. ALPN (HTTP/2 vs HTTP/1.1), SNI, signature_algorithms, supported_groups, key_share (особенно для TLS1.3), early_data (0‑RTT), status_request (OCSP stapling) и т. п. Наличие/отсутствие конкретного расширения или его значение меняет поведение сервера/прокси.
- QUIC/HTTP/3. Chrome и Firefox по‑разному поддерживают/включают QUIC. QUIC — это UDP‑сессия с собственным «TLS‑похожим» рукопожатием; многие DPI/провайдеры всё ещё плохо её понимают и либо блокируют, либо ошибочно обрабатывают.
- Порядок и размеры TLS‑записей / TCP‑стек. Пакетные особенности и промежутки в передаче тоже используются как признаки прокси/VPN.
- HTTP‑заголовки/клиент‑хинты. Chromium добавляет Sec‑Fetch‑*, Client Hints (Sec‑CH‑UA*, Sec‑CH‑UA‑Platform), более «современные» Accept/Encoding и т.п. Такие заголовки сами по себе ничего «не нарушают», но WAF/скрипты на сервере могут считать их подозрительными и блокировать.
- Поведение уровня приложения. Разные браузеры по‑разному ведут куки, редиректы, preflight (CORS), keep‑alive и т. п. Это тоже может вызывать отличие в том, как сервер реагирует.
Почему это приводит к блокировкам/таймаутам
- DPI или провайдеры сопоставляют TLS‑/QUIC‑отпечатки с известными VPN/прокси и блокируют/замедляют трафик с тех отпечатков.
- Некорректно настроенные WAF/антибот‑правила на сайте могут решать, что комбинация заголовков + TLS‑fingerprint — «бот» или «атакующий» и отвечать 403/регенерацией/таймаутом.
- Некоторые прокси плохо обрабатывают HTTP/2 мультиплексирование или QUIC, из‑за чего отдельные запросы обрываются или получают 403.
Почему «существуют стандарты» но всё равно отличаются
Стандарты (TLS, HTTP) описывают, что можно обменивать, но дают выбор опций: какие шифры поддерживать, какие расширения включать, какие ALPN предлагать, в каком порядке. Реализации (Chrome, Firefox, curl, OpenSSL/BoringSSL/ NSS) делают разные опции по умолчанию — это и создаёт различия, которые распознаёт DPI/WAF.
Что показывает ваш эксперимент с curl
Если «Copy as cURL» из DevTools даёт 403, а простая curl‑запрос без ряда заголовков — 200, это значит:
- Сервер (или фронтящий его WAF/proxy) принимает/блокирует по набору HTTP‑заголовков — то есть правило по‑умолчанию слишком жёсткое или ошибочно написано.
- Это не обязательно «баг» в браузере — скорее баг/неправильная конфигурация на стороне сервера/защитного ПО или некорректная работа промежуточного устройства.
Практические шаги для диагностики
Для пользователя:
- Попробуйте отключить HTTP/2/HTTP/3 в браузере (в Chrome флаги, в Firefox network.http.http2.enabled / network.http.http3.enabled) — если проблема уходит, виноват прокси/WAF плохо работающий с HTTP/2/3 или QUIC.
- Попробуйте запустить Chrome с --disable-quic или --disable-http2 (тест) и посмотреть поведение.
- Сравните curl‑запросы: используйте curl -v --http1.1 и по очереди добавляйте заголовки из «Copy as cURL», чтобы найти «проблемный» заголовок.
- Посмотрите TLS‑ClientHello (tcpdump/wireshark) и сравните JA3. Существуют инструменты/сайты для расчёта JA3.
Для администратора сайта / владельца сервера:
- Проверьте логи WAF (Cloudflare, nginx mod_security, ISP‑фронт) — что именно вызывает 403.
- Убедитесь, что правила блокировки не полагаются на сочетание клиент‑фингерпринтов + заголовков (особенно на Sec‑CH/Client Hints).
- Тестируйте с разными комбинациями ALPN/TLS версий и с HTTP/2/3. Убедитесь, что прокси корректно обрабатывает HTTP/2 мультиплексирование и QUIC.
- Сделайте правила менее жёсткими или явно разрешите известные браузерные отпечатки, либо обновите сигнатуры WAF.
- Логируйте полные заголовки запросов и TLS‑информацию при 403, чтобы увидеть причину блокировки.
Короткие команды для теста
- Принудить HTTP/1.1: curl -v --http1.1 'https://example.com'
- Убрать заголовки, скопированные из DevTools (пример): curl -v 'https://mirkvartir.ru/...' -H 'User-Agent: ...' -H 'Accept: text/html' (не добавлять Sec‑Fetch* и Sec‑CH‑UA*)
- Посмотреть ClientHello: tcpdump -s 0 -w dump.pcap port 443 and host example.com, открыть в Wireshark.
Итог
Различия между Chromium и Firefox в TLS/HTTP — нормальное явление (разные наборы шифров, расширений, ALPN, QUIC и разные HTTP‑заголовки). На практике это даёт разные отпечатки, которые DPI/WAF/прокси могут узнавать и блокировать. То, что удаление заголовков из curl устраняет 403, указывает на некорректную или избыточно агрессивную фильтрацию/логику на стороне сервера/защиты — лучше править правила WAF/прокси или, если вы — пользователь, временно пользоваться браузером, с которым сайт корректно работает, и сообщить админам сайта/провайдеру о проблеме.