Signup Protection, проверка email и Domain Intelligence используют общий кредитный баланс. Как работают кредиты

Начать бесплатно

Блог

TLS-отпечатки для защиты регистрации

TLS-отпечаток описывает особенности установления соединения. Разберитесь, как Emvero сравнивает их с заявлением браузера и почему расхождение требует контекста.

Опубликовано

На этой странице

TLS fingerprinting использует особенности установления соединения, чтобы распознавать шаблоны, связанные с клиентским ПО. При регистрации они помогают проверить, согласуется ли заявление браузера с соединением. Они не устанавливают личность посетителя и не определяют, регистрировался ли этот человек раньше.

Находки TLS в Emvero фиксируют расхождения с заявлением браузера. Обе информационные: у них default_raises: false, и сами по себе они не требуют подтверждения email и не отклоняют регистрацию. Чтобы выбрать вес такой находки, нужно понимать, что именно сравнивалось.

Что показывает TLS-рукопожатие

При начале TLS-соединения клиент отправляет ClientHello с предлагаемыми возможностями. Среди них наборы шифров и расширения, например поддерживаемые версии протокола и группы обмена ключами. Сервер использует эти предложения при согласовании соединения. Структура описана в определении ClientHello в RFC 8446.

Метод построения отпечатка выбирает и обобщает признаки рукопожатия, чтобы сравнивать соединения ПО с похожим поведением. JA3 и JA4 — примеры таких методов. Один шаблон может описывать множество установок одной программы. Это не идентификатор, назначенный человеку.

В предложении Chromium о перестановке расширений описан случайный порядок расширений ClientHello, чтобы системы не зависели от неизменного рукопожатия. Отпечаток с сохранением порядка и отпечаток с его нормализацией могут вести себя по-разному. Считайте шаблон наблюдением, полученным по определенным правилам.

TLS-признаки и отпечатки браузера или устройства

TLS-признаки поступают из соединения. Отпечаток браузера может объединять другие наблюдаемые свойства, в том числе значения, измеренные кодом внутри браузера. В руководстве W3C об отпечатках пассивные наблюдения отделены от активных методов, например отрисовки графических шаблонов. Результат Canvas — пример такого входа. Обработка аудио дает другие данные; их рассматривает раздел о приватности в рабочем проекте Web Audio.

Эти данные могут участвовать в более широких попытках связать устройства или сессии. Находка согласованности TLS имеет более узкий смысл. Ответ регистрации Emvero не предоставляет постоянный Visitor ID или исходный отпечаток для использования как идентификатор аккаунта. Публичного поиска JA3/JA4 или теста отпечатка браузера также нет.

Прокси, завершающий TLS, создает отдельное соединение и собственный ClientHello к целевому серверу. Это описано в RFC 8446 о завершении TLS. Передача трафика через туннель сама по себе не устанавливает завершение TLS. Не следует считать, что любая VPN заменяет рукопожатие браузера.

Что Emvero сравнивает с заявлением браузера

Инфраструктура сбора наблюдает соединение, через которое страница запрашивает токен визита. Для TLS-сравнений используется User-Agent первого запроса этого соединения. Позже бэкенд передает токен в проверке регистрации; его API-соединение с Emvero отдельно от наблюдаемого визита.

Сервис сравнивает заявление с метками наблюдаемого шаблона рукопожатия. Метки происходят из совокупности соединений с этим шаблоном и их заявлений о ПО. Они описывают связь в наблюдаемом трафике, а не доверенное утверждение об установленной программе.

User-Agent и Client Hints тоже могут противоречить друг другу. Это отдельное сравнение HTTP-заявлений. Оно не делает ни одно заявление доказательством движка браузера и отличается от TLS-сравнений ниже.

Расхождение движка: fp_client_tls_mismatch

Движок, подразумеваемый User-Agent, не входит в набор движков, связанных с TLS-шаблоном соединения. Сравниваются заявление о движке и метки наблюдаемого набора, а не определяется точная марка браузера. Находка относится к классу identity и имеет default_raises: false.

Приложение может использовать собственный сетевой стек и передавать User-Agent, похожий на браузерный. Это дает такой же вид расхождения, как намеренно неверное заявление. Сама находка не различает эти причины.

Расхождение версии Chromium: fp_client_tls_version_mismatch

Эта находка сравнивает заявленную основную версию Chromium с диапазоном версий, связанным с TLS-шаблоном. Здесь «версия» относится к Chromium, а не к расхождению TLS 1.2 и TLS 1.3. Диапазон представляет эпоху версий, выведенную из наблюдаемого трафика. Он не определяет точную установленную версию браузера.

В сокращенной находке использованы вымышленные значения. Числа поясняют сравнение и не являются справочной картой текущих версий Chromium:

{
  "code": "fp_client_tls_version_mismatch",
  "class": "identity",
  "default_raises": false,
  "detail": {
    "direction": "claim_newer",
    "epoch": "131-150",
    "claimed_version": 153
  }
}

claim_newer означает, что заявление новее связанной эпохи. Это не означает, что сервис измерил на устройстве Chromium 150. Приложение может заявлять свежую версию Chrome, используя старый системный WebView, и получить такое расхождение. Поэтому находка версии тоже остается информационной.

Проверьте, выполнялось ли сравнение

Отсутствие находки расхождения может означать согласованность, но может означать и невозможность сравнения. Изучите not_evaluated и доступный статус сравнения, прежде чем считать отсутствие находки совпадением.

fp_client_tls_not_evaluated отмечает сравнение движка, которое не удалось завершить. fp_client_tls_version_not_evaluated делает то же для версии Chromium. Причиной может быть шаблон без меток, недоступность меток или User-Agent без пригодного заявления. Соответствующий статус передается в signals.client_claims.tls или signals.client_claims.tls_version, если эти объекты присутствуют.

claimed_engine и labeled_engine возвращаются как not_carried, потому что токен не несет исходные значения движков. Это ограничение подробностей ответа, отдельное от того, выполнялось ли сравнение. Статус сигналов unavailable относится к оценке в целом и не устанавливает безопасность визита.

Используйте TLS-находки в решении регистрации

По политике по умолчанию эти TLS-коды не входят в signal_codes как находки, повышающие действие. Другие свидетельства по-прежнему могут потребовать подтверждения, а email — привести к отказу. Читайте возвращенное внешнее action, а не выводите его из одной TLS-находки. В статье о результате регистрации разобрана связь находок и общей рекомендации.

Подтверждение и права аккаунта определяет ваше приложение. Используйте Signup Protection, когда в этом решении нужны свидетельства email и визита. Руководство по защите регистрации описывает последовательность формы, токена, серверного запроса и действия.

Подключите Signup Protection к форме регистрации.

Создайте аккаунт и ключ страницы, добавьте скрипт и серверный вызов. Применяйте полученное действие в приложении.