Принцип Доверия (Trust) в HTTPS
Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.
В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну.
Почему решил написать
Я, вообще, по специальности Android разработчик, и не особо шарю в криптографии и протоколах защиты информации. Поэтому когда мне пришлось столкнуться с этим непосредственно, я был немного в шоке от размера пропасти в моих теоретических знаниях.
Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — «Вот это Библия». Поэтому у меня это «немного разобраться» заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.
Что значит защищенный канал связи?
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
В этой статье я хотел бы рассказать подробно только о механизме Доверия.
Что значит Доверие (Trust)?
Вы можете доверять вашему собеседнику только если точно знаете, что он — тот, за кого себя выдает.
Самый простой пример — вы знаете собеседника лично, более сложный — вы знаете кого-то кто лично знает вашего предполагаемого собеседника и этот кто-то гарантирует что собеседнику можно доверять.
Жизненный пример
Представим, Вы хотите купить квартиру.
Для этого Вы находите Риэлтора, который занимается продажей квартир.
Риэлтор говорит, что он работает с неким Застройщиком, и предлагает квартиру от этого Застройщика.
Застройщик говорит, что жилье, которое он строит будет, сдано, и те кто заплатил за него деньги Риэлтору, получит его в собственность, и легальность строительства и право собственности будет обеспечена Государством.
Итого у нас есть 4 субъекта Вы, Риэлтор, Застройщик, Государство.
Для того чтобы сделка успешно состоялась и никто никого не обманул Государство создало законы, определяющие документы, которые гарантируют легальность сделок, и механизм печати или подписи, который гарантирует подлинность этих документов.
У Вас есть примеры этих документов и печатей, вы можете их взять у Государства.
Вы имеете право требовать у Риэлтора оригиналы документов на строительство.
Риэлтор берет документы Застройщика, которые подкреплены документами Государства и убеждается, что квартиры можно продавать — они легальны.
Застройщик же в свою очередь получает документы у Государства.
Т.е. теперь вы можете смело вести диалог только с Риэлтором, основываясь на его документах, скрепленных печатями Застройщика и Государства!
Доверие в HTTPS
А теперь поменяем имена действующих лиц из Жизненного примера.
Вы = Клиент (Client)
Риэлтор = Сервер (Server)
Застройщик = Промежуточный Центр Сертификации (Intermediate CA)
Государство = Главный Центр Сертификации (Root CA)
Главный Центр Сертификации (Root Certificate Authority, CA) — общепризнанная известная компания, которой международные организации выдали полномочия заведовать сертификатами и подписями, короче этой компании доверяют все.
Она может давать некоторые полномочия Промежуточным центрам Сертификации (Intermediate CA), и они будут подписывать документы от имени Главного Центра.
Перейдем к математике
Были упомянуты слова: подпись, сертификат и т.д. Как это реализовать? В помощь приходит асимметричное шифрование.
Чтобы не вдаваться в подробности и не объяснять дискретную математику и криптографию, уясним пару вещей:
1) Коротко и о главном об асимметричном шифровании.
Есть 2 ключа — Публичный и Приватный (Public Key and Private Key). Собственно, ключи — это просто большие числа.
Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ.
И наоборот:
Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ.
Приватный ключ никому не дается, Публичный — собственно, публичный.
2) Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключом Подписчика (Issuer). Если ее можно расшифровать Публичным Ключом Подписчика, то можно с уверенностью утверждать, что именно Подписчик ее шифровал.
COMODO Certification Authority
Identity: COMODO Certification Authority
Verified by: COMODO Certification Authority
Expires: 31.12.29
Subject Name
C (Country): GB
ST (State): Greater Manchester
L (Locality): Salford
O (Organization): COMODO CA Limited
CN (Common Name): COMODO Certification Authority
Issuer Name
C (Country): GB
ST (State): Greater Manchester
L (Locality): Salford
O (Organization): COMODO CA Limited
CN (Common Name): COMODO Certification Authority
Issued Certificate
Version: 3
Serial Number: 4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3D
Not Valid Before: 2006-12-01
Not Valid After: 2029-12-31
Certificate Fingerprints
SHA1: 66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7B
MD5: 5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75
Public Key Info
Key Algorithm: RSA
Key Parameters: 05 00
Key Size: 2048
Key SHA1 Fingerprint: 11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3
Public Key: 30 82 01 0A 02 82 01 01 00 D0 40 8B 8B 72 E3 91 1B F7 51 C1 1B 54 04 98 D3 A9 BF C1 E6 8A 5D 3B 87 FB BB 88 CE 0D E3 2F 3F 06 96 F0 A2 29 50 99 AE DB 3B A1 57 B0 74 51 71 CD ED 42 91 4D 41 FE A9 C8 D8 6A 86 77 44 BB 59 66 97 50 5E B4 D4 2C 70 44 CF DA 37 95 42 69 3C 30 C4 71 B3 52 F0 21 4D A1 D8 BA 39 7C 1C 9E A3 24 9D F2 83 16 98 AA 16 7C 43 9B 15 5B B7 AE 34 91 FE D4 62 26 18 46 9A 3F EB C1 F9 F1 90 57 EB AC 7A 0D 8B DB 72 30 6A 66 D5 E0 46 A3 70 DC 68 D9 FF 04 48 89 77 DE B5 E9 FB 67 6D 41 E9 BC 39 BD 32 D9 62 02 F1 B1 A8 3D 6E 37 9C E2 2F E2 D3 A2 26 8B C6 B8 55 43 88 E1 23 3E A5 D2 24 39 6A 47 AB 00 D4 A1 B3 A9 25 FE 0D 3F A7 1D BA D3 51 C1 0B A4 DA AC 38 EF 55 50 24 05 65 46 93 34 4F 2D 8D AD C6 D4 21 19 D2 8E CA 05 61 71 07 73 47 E5 8A 19 12 BD 04 4D CE 4E 9C A5 48 AC BB 26 F7 02 03 01 00 01
Subject Key Identifier
Key Identifier: 0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FF
Critical: No
Key Usage
Usages: Digital signature
Critical: Yes
Basic Constraints
Certificate Authority: Yes
Max Path Length: Unlimited
Critical: Yes
Extension
Identifier: 2.5.29.31
Value: 30 40 30 3E A0 3C A0 3A 86 38 68 74 74 70 3A 2F 2F 63 72 6C 2E 63 6F 6D 6F 64 6F 63 61 2E 63 6F 6D 2F 43 4F 4D 4F 44 4F 43 65 72 74 69 66 69 63 61 74 69 6F 6E 41 75 74 68 6F 72 69 74 79 2E 63 72 6C
Critical: No
Signature
Signature Algorithm: SHA1 with RSA
Signature Parameters: 05 00
Signature: 3E 98 9E 9B F6 1B E9 D7 39 B7 78 AE 1D 72 18 49 D3 87 E4 43 82 EB 3F C9 AA F5 A8 B5 EF 55 7C 21 52 65 F9 D5 0D E1 6C F4 3E 8C 93 73 91 2E 02 C4 4E 07 71 6F C0 8F 38 61 08 A8 1E 81 0A C0 2F 20 2F 41 8B 91 DC 48 45 BC F1 C6 DE BA 76 6B 33 C8 00 2D 31 46 4C ED E7 9D CF 88 94 FF 33 C0 56 E8 24 86 26 B8 D8 38 38 DF 2A 6B DD 12 CC C7 3F 47 17 4C A2 C2 06 96 09 D6 DB FE 3F 3C 46 41 DF 58 E2 56 0F 3C 3B C1 1C 93 35 D9 38 52 AC EE C8 EC 2E 30 4E 94 35 B4 24 1F 4B 78 69 DA F2 02 38 CC 95 52 93 F0 70 25 59 9C 20 67 C4 EE F9 8B 57 61 F4 92 76 7D 3F 84 8D 55 B7 E8 E5 AC D5 F1 F5 19 56 A6 5A FB 90 1C AF 93 EB E5 1C D4 67 97 5D 04 0E BE 0B 83 A6 17 83 B9 30 12 A0 C5 33 15 05 B9 0D FB C7 05 76 E3 D8 4A 8D FC 34 17 A3 C6 21 28 BE 30 45 31 1E C7 78 BE 58 61 38 AC 3B E2 01 65
Что же происходит на каждом из субъектов
1) Начнем с Root CA
2) Этот Self Signed Certificate раздается клиентам
3) Подтверждение своей аутентичности
Если не вдаваться в детали, то этот пункт одинаков для Сервера и Промежуточных Центров Аутентификации
В итоге, имеем Self Signed Certificate на клиенте и Signed Server Certificate на сервере, т.е. клиент знает и доверяет СА и СА прогарантировал аутентичность сервера.
4) Непосредственно диалог
Теперь глянем что же происходит при обращении клиента к серверу. Для этого используем Network dump от Wireshark.
Мы видим сообщения:
Client Hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message
Ниже показано, что эти сообщения с собой несут:
Как видим, вместе с Server Hello Клиенту приходит Цепочка Сертификатов Сервера (Server Certificate).
Как клиент проверяет подлинность Сертификата. Как это происходит:
1) Клиент смотрит, есть ли у него Root CA для верхнего сертификата в цепочке,
если нет — спускается по цепочке ниже, при чем каждый раз перепроверяет, действительно ли подписан сертификат предыдущим в цепочке. (Это просто — цифровая подпись нижнего должна расшифровываться публичным ключом верхнего).
Если не нашел, значит у Клиента и Сервера нет общего знакомого CA, доверять серверу нельзя.
2) если есть — Клиент берет Публичный Ключ своего сертификата и пробует расшифровать подпись сертификата, пришедшего с Сервера.
Примечание
Протокол TLS также поддерживает механизм доверия Сервера к клиенту. Как видно из рис 5, в ответ на Server Hello, может прийти сертификат клиента, и сервер тоже может удостовериться, что CA гарантировал его аутентичность.
Заключение
Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог. При чем, сразу же есть все для дальнейшего шифрования сообщений — приватный ключ на стороне сервера, и его публичный ключ на клиенте, который был прислан с сертификатом сервера. Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключом сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного. Механизмы выбора протокола шифрования и обеспечения целостности сообщений — это огромная область математики и криптографии, но, к счастью для пользователя, она уже реализована под капотом SSL. Все что надо — чтобы на клиенте и сервере были совместимые версии SLL, шифров, криптопровайдеров.
В конце хотелось бы сказать, что протоколы безопасной коммуникации:
Но главный, и пожалуй, достаточный, аргумент за — HTTPS и TLS действительно безопасны, насколько это возможно.
Использование TLS fingerprinting для выявления угроз
В статье хотим рассказать про технологию TLS fingerprinting, про которую недостаточно материалов в русскоязычном сегменте. Попробуем это исправить. Статья частично переводит тематические материалы авторов описываемых методов (тут и тут), а также содержит описание практической реализации от Акрибии.
Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.
Использование TLS само по себе благо, так как с его помощью шифруются данные. Но с обратной стороны создатели вредоносов используют его же, чтобы скрываться в шифрованном трафике (в данной статье как раз будет уклон в эту сторону) и затруднять их обнаружение и нейтрализацию.
Чтобы инициировать сеанс TLS, клиент отправляет «пакет» приветствия серверу после трёхстороннего установления связи TCP. Этот «пакет» и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.
Поскольку согласование шифрования TLS передаётся в открытом виде, то можно отследить и идентифицировать клиентские приложения.
В этом и суть технологии TLS fingerprinting, если кратко. А теперь немного подробнее.
TLS fingerprinting
Суть технологии в захвате элементов пакета приветствия клиента, которые остаются статичными от сеанса к сеансу для каждого клиента. На их основе можно создать «отпечаток пальца» для распознавания конкретного клиента в последующих сеансах. Записываются следующие поля:
Кроме того, данные собираются из трех конкретных расширений (если они доступны):
алгоритм для шифрования данных;
хэш функция для проверки содержимого.
Использование такого набора данных позволяет с большой точностью идентифицировать используемый клиент (например, браузер).
Пакет приветствия клиента — это первый пакет в любом TLS-соединении. Это позволяет принимать решение о последующих мерах в начале сеанса до того, как потребуется подмена протокола или эмуляция.
Можно захватывать пакеты приветствия клиента TLS с высокой степенью точности по всем портам с абсолютно нулевым требованием для захвата обоих направлений потока. Это означает, что датчики в среде с асимметричной маршрутизацией или с ограничениями ресурсов, потенциально вызывающими отбрасывание пакетов, все равно могут собирать пакеты приветствия клиента, независимо от того, были ли они скрыты из-за работы на нестандартных портах.
Пакеты приветствия клиента возникают достаточно редко, поэтому дополнительная обработка хэшей не повлечет значительных затрат.
Наиболее очевидное использование TLS Fingerprinting – пассивное обнаружение. Технология позволяет обнаруживать широкий спектр потенциально нежелательного трафика, не требуя доступа к конечным точкам. Можно обнаруживать как конкретные вредоносы по их поведению и/или обращениям к командным центрам, так и обычный софт, используемый не по назначению или в обход действующих правил.
Например, к серверу Exchange могут обращаться только почтовые клиенты или браузер, если используется OWA, поэтому соединение из скрипта на Python будет подозрительным.
Итого: TLS Fingerprinting предназначен для быстрой идентификации известных TLS-соединений и отслеживания неизвестных TLS-соединений. Входные данные принимаются либо посредством прослушивания трафика, либо при чтении PCAP файлов.
Есть несколько готовых реализаций, наиболее поддерживаемых комьюнити:
пассивный метод с использованием хэшей JA3 и JA3S;
активный инструмент снятия отпечатков пальцев с сервера TLS – хэши JARM.
JA3 и JA3S
Метод JA3 используется для сбора десятичных значений байтов для следующих полей в пакете приветствия клиента: версия TLS, набор шифров, список расширений протоколов TLS, эллиптические кривые и форматы эллиптических кривых. Затем он объединяет эти значения вместе по порядку, используя символ «,» для разграничения каждого поля и «-» для разграничения каждого значения в каждом поле.
Порядок полей следующий:
Если в ClientHello нет расширений TLS, поля остаются пустыми:
Эти строки затем хэшируются MD5. Пример отпечатка JA3:
JA3S – это хэш идентификации сервера. Метод JA3S заключается в сборе десятичных значений байтов для следующих полей в пакете приветствия сервера: версия TLS, набор шифров и список расширений протоколов TLS. После сбора значений, происходит процесс объединения этих значений вместе по порядку, используя «,» для разграничения каждого поля и «-» для разграничения каждого значения в каждом поле.
Порядок полей, следующий:
Если в Server Hello нет расширений TLS, поля остаются пустыми.
Эти строки затем хэшируются MD5 для создания 32-символьного отпечатка пальца.
Это отпечаток JA3S:
JA3 и JA3S – это методы снятия отпечатков TLS. JA3 отслеживает способ, которым клиентское приложение обменивается данными через TLS, а JA3S отслеживает ответ сервера. Вместе они создают отпечаток криптографического согласования между клиентом и сервером.
Теперь перейдем к описанию активного метода JARM.
JARM работает, активно отправляя 10 пакетов приветствия клиента TLS на целевой сервер и фиксируя определенные атрибуты ответов приветствия сервера. Затем агрегированные ответы сервера TLS хэшируются определенным образом для получения отпечатка JARM. JARM отправляет разные версии, шифры и расширения TLS в разном порядке для сбора уникальных ответов. Хэш JARM представляет собой гибридный нечеткий хэш, он использует комбинацию обратимого и необратимого алгоритма хеширования для создания 62-символьного отпечатка.
Отпечатки JARM можно использовать:
убедиться, что все серверы в группе имеют одинаковую конфигурацию TLS;
сгруппировать разрозненные серверы в сети Интернет по конфигурации, указав, например, что сервер может принадлежать Google, Yandex или Apple;
определить приложения или инфраструктуру по умолчанию;
выявить командные центры и других вредоносные серверы в сети Интернет.
Первые 30 символов состоят из шифра и версии TLS, выбранных сервером для каждого из 10 отправленных приветствий клиента. «000» означает, что сервер отказался согласовывать приветствие с этим клиентом. Остальные 32 символа представляют собой усеченный хэш SHA256 совокупных расширений, отправленных сервером, без учета данных сертификата x509. При сравнении отпечатков JARM, если первые 30 символов совпадают, но последние 32 отличаются, это будет означать, что серверы имеют очень похожие конфигурации, принимают одинаковые версии и шифры, но используют различные расширения, что не позволяет их считать полностью идентичными.
Исторически так сложилось, что индустрия кибербезопасности была сосредоточена в основном на индикаторах компрометации (IOC) и индикаторах атаки (IOA). То есть когда вредоносное ПО/хост и т.п. будут кем-то обнаружены, исследователи или вендоры платформ TI вычленяют уникальные или не очень признаки выявленного вредоноса или атаки типа IP, домена, хэша файла и т.п. и публикуют их в «чёрных списках». Проблема в том, что к этому моменту вредоносное ПО уже распространено, и специалисты ИБ автоматически переходят в оборону.
Интернет-сканирование JARM в сочетании с другими метаданными и историческим анализом даёт возможность упреждающей идентификации IOC для новых вредоносов. Например, можно сканировать Интернет с помощью JARM, сопоставлять известные результаты JARM с историей домена, IP и репутацией вместе с данными сертификата для создания черного списка. Это позволяет перейти к возможности программного создания высокоточных списков блокировки до того, как первая вредоносная программа будет распространена.
Можно использовать JARM автоматически сканируя все хосты назначения, детектируемые в сети компании, для обогащения событий, и использовать сводную таблицу, чтобы не сканировать одни и те же хосты несколько раз. Затем можно запускать запросы заведомо плохих JARM или использовать список для корреляции.
Чтобы упростить процесс, можно использовать готовое решение. В настоящее время хэши JARM умеют считать продукты Palo Alto Networks и используют их API для обогащения целевого JARM.
Примеры реализации
Если нет возможности или желания использовать готовые решения от Palo Alto и пр., можно реализовать в своей инфраструктуре свое средство мониторинга трафика, например, на основе Zeek (ранее назывался Bro) – популярного open-source продукта, заточенного специально для этого.
Zeek собирает огромное количество информации из первоначального согласования TLS, т.к. оно обрабатывается в открытом виде. Таким образом, хотя мы не можем видеть всё, что связано с шифрованием TLS, мы всё же можем получить общее представление о том, что происходит.
Zeek умеет выполнять снятие отпечатков TLS с помощью хэша JA3\JA3S.
Если у нас уже есть Zeek, в него попадает трафик, то для полноценного мониторинга нам понадобится SIEM (можно обойтись и без SIEM, но тогда обрабатывать логи Zeek’а придется вручную). Допустим, SIEM у нас все же есть. Помимо инструментов обработки трафика и событий Zeek нам еще потребуются списки готовых хэшей, чтобы было с чем сравнивать.
В случае в JA3 – все просто. Есть готовый инструмент, к которому можно обращаться по API для проверки выявленного хэша JA3 и принятия решения – нормально это или не очень.
Хэши JA3S, соответствующие вредоносам, достать чуть сложнее. Есть, например, небольшая подборка тут, есть и еще, нужно только искать или считать самостоятельно.
С хешами JARM еще немного сложнее, если у вас нет Palo Alto, их нужно собирать по разрозненным отчетам аналитиков или считать самостоятельно и вести собственные белые и черные списки. Но на github тоже попадаются тематические подборки, например, эта. Мы ее задействуем в дальнейшем при проработке правил по JARM.
Далее приведем некоторые описания правил, которые мы реализуем у себя. Также есть неплохой доклад от Splunk с примерами алгоритмов и правил мониторинга по хэшам JA3/JA3S. Доступен здесь. Правила можно адаптировать под любую SIEM.
Выявление признака конкретного вредоноса по хэшам JA3\JA3S. Вот, например, готовые значения для Emotet и TrickBot:
Выявления нового хэша JA3, ранее не появляющегося в сети.
Список клиентского ПО в любой сети, как правило, достаточно статичен, и, если появится что-то новенькое – это однозначно повод разобраться. Правда, это может быть новая версия уже известного ПО, тогда ее нужно добавить в белый список.
Выявления хэшей JA3 не из белого списка.
Общее правило, которое позволит обратить внимание на любую активность, которая явно не помечена заранее как разрешенная. Сюда могут попасть, как новые ранее неизвестные клиентские устройства или приложения, так и вредоносы, попавшие к вам в сеть. В любом случае – трекать это стоит.
Выявления хэшей JA3\JA3S из чёрного списка.
Это правило нацелено на выявление хэшей заведомо вредоносного ПО.
Выявление обращений к C&C по хэшам JARM.
При выявлении обращения к TLS-серверу, неизвестному нам или ранее не появляющемуся в логах, необходимо посчитать его JARM хэш (можно вручную, можно скриптом или с использованием SOAR), при совпадении с хэшем, соответствующим известному C&C серверу, блокируем соединение, изолируем хост и расследуем инцидент.
Выявление JA3 хэшей, не характерных для системы.
При появлении на хостах с Windows JA3 хэшей, характерных для Linux или смартфонов (Android/IOS), стоит обратить внимание на такие хосты. Это может являться признаком работы вредоносов (ну или запущенного эмулятора/виртуалки в режиме NAT). Кейс особенно заслуживает внимание, если выявлен на рабочей станции обычного пользователя, далекого от мира IT.
Выявление JA3 хэшей, характерных для разных браузеров одного семейства.
Сейчас достаточно сложно на один хост поставить две разные версии Firefox или Chrome (виртуальные машины в режиме NAT не в счёт). Такое выявление может свидетельствовать о том, что злоумышленники пытались адаптироваться под установленный софт, но после обновления софта не успели или забыли обновить свой Fingerprint. Хост лучше изолировать и провести расследование.
Выявление JA3 хэшей, характерных для популярных сетевых библиотек языков программирования.
Ни для кого не секрет, что сейчас ВПО пишется не только на C/C++. Часто встречаются образцы, которые написаны на Python или Golang. Стандартные библиотеки, такие как requests (для python) или http (для Golang), имеют характерные отпечатки в рамках нескольких версий. В случае выявления такого хэша на рабочем месте разработчиков, вероятно, это нормально. Но, если хэши «всплывут» на рабочем компьютере рядового пользователя, то точно следует провести тщательную проверку, так как с большой вероятностью это будет свидетельством активности вредоноса. Также стоит поддерживать списки актуальных JA3 хэшей для популярных сетевых библиотек, чтобы минимизировать ложные срабатывания.
Важно: Список хэшей JARM (и JA3S тоже) необходимо регулярно пополнять новыми выявленными C&C серверами, полученную самостоятельно или от сторонних исследователей.
При использовании средств защиты сети, которые умеют вычислять хэши JARM самостоятельно и на лету, соединения с серверами из черных списков можно и нужно блокировать автоматически.
В завершении хотим подчеркнуть, что развитие и популяризация технологии TLS Fingerprinting, по нашему мнению, совсем не за горами, и способствует этому внедрение TLS 1.3.
В версиях стандарта TLS до 1.3 у клиента была возможность сообщать, к какому серверу он хочет обратиться — SNI (Server Name Indication). Чаще всего в HTTPS для этого использовалось поле HOST, чтобы на одном IP и порту могли работать несколько HTTPS-сайтов. Соответственно и так, без всяких fingerprint, было видно, кто куда идет. Понятно, что речь идёт про легитимные обращения, атакующие всегда могли подделать SNI.
В стандарте TLS 1.3 появилась возможность шифровать имя запрашиваемого сайта – Encrypted SNI (ESNI), и безопасники потеряли возможность видеть, куда идёт обращение.
Правда ESNI уже запретили в Китае, и были попытки блокировок в России. Однако ESNI стал часто встречаться, в том числе в инструментах злоумышленников, и без TLS fingerprinting становится сложно понимать, куда происходят обращения в сети.
Авторы статьи:
Михаил Кравченко, SOC-аналитик;
Александр Минин, руководитель направления Threat Intelligence @AAMinin;
Анна Шестакова, руководитель направления мониторинга ИБ.