Закрепление сертификатов в мобильных и настольных приложениях

Стандартный TLS доверяет любому сертификату, подписанному одним из примерно 150 корневых CA, предустановленных в OS. Если какой-либо корневой CA будет скомпрометирован или принуждён к выдаче сертификата, злоумышленник сможет получить сертификат для любого домена и перехватывать трафик TLS. Закрепление сертификатов ограничивает доверие конкретным сертификатом или открытым ключом независимо от того, какой CA его подписал. Приложение с закреплением отклоняет соединения со своими серверами, если сервер не предъявляет точно ожидаемый сертификат или ключ. Такая защита особенно ценна для мобильных приложений, где пользователи не могут проверять сетевой трафик, а корпоративные решения MDM могут устанавливать корневые сертификаты предприятия.

Существует три уровня детализации закрепления: (1) Полное закрепление сертификата — должен совпадать точный сертификат в кодировке DER. Это наиболее хрупкий вариант: он нарушается при любом продлении сертификата. (2) Закрепление открытого ключа — сравниваются только байты SubjectPublicKeyInfo (SPKI). Оно переживает продление сертификата, если сохраняется та же пара ключей. (3) Хеш SPKI — вместо необработанного ключа сохраняется SHA-256(SPKI). Такой подход используется в закреплении открытого ключа HTTP (HPKP) и конфигурации безопасности сети Android. Предпочтительно закреплять открытый ключ / SPKI: это переживает смену CA и продление сертификата, сохраняя возможность обнаружить MITM с другой парой ключей.

Android (API 24+) предоставляет декларативный механизм закрепления через XML конфигурации безопасности сети. Файл res/xml/network_security_config.xml задаёт закрепления для каждого домена: pin-set с digest="SHA-256" и хешем SPKI в кодировке base64. Приложение ссылается на этот файл в AndroidManifest.xml через android:networkSecurityConfig. Android применяет закрепления ко всем HTTP-соединениям, созданным через стандартные HttpsURLConnection и OkHttp (при использовании системного диспетчера доверия). Элемент pin-set требует как минимум одно резервное закрепление (другой ключ или закрепление CA), чтобы предотвратить блокировку приложения при компрометации основного ключа. Истечение срока закрепления (атрибут expiration) заставляет приложения обновиться до того, как закрепления устареют.

Приложения iOS реализуют закрепление через делегаты NSURLSession. Делегатный метод URLSession(_:didReceive:completionHandler:) получает объект доверия сервера. Приложение вызывает SecTrustEvaluateWithError для проверки цепочки, затем извлекает конечный сертификат с помощью SecTrustGetCertificateAtIndex(trust, 0), экспортирует его байты SPKI, хеширует их с помощью SHA-256 и сравнивает с сохранённым закреплением. TrustKit (библиотека с открытым исходным кодом) оборачивает этот шаблон, предоставляя закрепление на основе конфигурации, поддержку нескольких закреплений, сопоставление поддоменов и режим только отчётов. App Transport Security (ATS) Apple отделена от закрепления: ATS устанавливает минимальные версии TLS, но не закрепляет ключи.

Закрепление открытых ключей HTTP (HPKP, RFC 7469) должно было добавить закрепление в веб-браузерах с помощью заголовков HTTP-ответа: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Браузер запоминал закрепление на срок, указанный в max-age, и отклонял соединения с несовпадающими ключами. Chrome объявил HPKP устаревшим в 2017 году и удалил его в 2019 году из-за катастрофических сбоев: одна ошибка конфигурации или потеря ключа могли навсегда заблокировать пользователям доступ к веб-сайту без возможности восстановления. Сейчас HPKP фактически не используется в веб-браузерах; закрепление на уровне приложения в мобильных приложениях остаётся жизнеспособным, поскольку обновления приложения могут содержать новые закрепления.

OkHttp (широко используемый в Android) поддерживает закрепление через CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Второе закрепление является резервным. OkHttp проверяет, что хотя бы одно закрепление совпадает с любым сертификатом в цепочке сервера — конечным, промежуточным или корневым. Это позволяет закрепить промежуточный CA (что переживает смену конечного сертификата) или корневой CA (что переживает смену промежуточного сертификата). OkHttp выдаёт SSLPeerUnverifiedException с полезным сообщением, содержащим фактические хеши SPKI сервера, поэтому извлечь закрепление во время разработки несложно.

Закрепление повышает сложность перехвата трафика, но не является непреодолимым. Распространённые методы обхода на мобильных устройствах: (1) Перехваты Frida — внедрить JavaScript в процесс приложения, перехватить метод проверки закрепления и безусловно вернуть true. (2) Инструменты снятия SSL-закрепления — автоматизированные сценарии Frida/Objection, нацеленные на распространённые библиотеки закрепления (TrustKit, OkHttp, встроенный SecTrust). (3) Модифицированная ROM — получить права суперпользователя на устройстве и изменить стек TLS. (4) Перепаковка — декомпилировать APK, изменить конфигурацию закрепления и перепаковать приложение с новым сертификатом. (5) Изменение памяти — изменить байт-код проверки во время выполнения. Меры защиты: обнаружение root-доступа или джейлбрейка, обфускация кода, проверки целостности (SafetyNet/App Attest).

Наибольший эксплуатационный риск закрепления сертификатов — самоблокировка: если производственный ключ утерян или срок действия сертификата истёк, а резерв недоступен, пользователи не смогут войти в приложение, пока не выйдет обновление (от нескольких дней до нескольких недель). Рекомендуемые методы: (1) Всегда закрепляйте как минимум два ключа — текущий ключ и заранее созданный резервный ключ, хранящийся в автономном режиме (HSM или изолированная от сети система). (2) Устанавливайте дату истечения срока закрепления и выпускайте обновления приложения до этой даты. (3) Отслеживайте сбои закрепления в режиме только отчётов до включения принудительной проверки. (4) Поддерживайте аварийный процесс выпуска обновлений приложения (с ускоренной проверкой) для инцидентов, связанных с ротацией закреплений. (5) Закрепляйте сертификат на уровне промежуточного CA, а не конечного сертификата, чтобы менять конечный сертификат без обновления приложения.

Настольные приложения, написанные с использованием Electron, Qt или собственного кода, могут реализовать закрепление через программные интерфейсы своего стека TLS. Приложения Electron используют событие app.on("certificate-error") и session.setCertificateVerifyProc() для реализации настраиваемой проверки. Сетевой код Qt использует QSslSocket с настраиваемой функцией обратного вызова для проверки. Приложения .NET используют ServicePointManager.ServerCertificateValidationCallback. Собственные приложения Windows используют WinHTTP с ручной проверкой сертификатов. Настольные приложения сталкиваются с дополнительными проблемами: перехват TLS на уровне OS через корпоративные прокси широко распространён, а пользователи могут ожидать, что работа через прокси сохранится, поэтому необходимо решить на уровне политики, применяется ли закрепление только к определённым конечным точкам.

Закрепление сертификатов усложняет автоматизированное тестирование и конвейеры CI/CD. Интеграционные тесты, выполняющие реальные вызовы HTTPS к тестовым серверам, должны использовать тестовые сертификаты, хеши SPKI которых закреплены в тестовой конфигурации. Возможные подходы: (1) Варианты сборки — отладочная или тестовая сборка содержит закрепления тестового сервера, а сборка для выпуска — закрепления производственного сервера. (2) Переопределения конфигурации безопасности сети — Android разрешает конфигурацию закреплений только для отладки. (3) Сервер-заглушка — перехватывать запросы на уровне HTTP-клиента до TLS, полностью обходя закрепление. (4) Самоподписанный CA для CI — выпускать тестовые сертификаты от CA для CI, корневому сертификату которого доверяют только тестовые сборки. Никогда не поставляйте в производство сборку с отключённым закреплением.

Закрепления сертификатов обычно представляют собой хеши открытых ключей RSA или EC. Когда начнётся переход к постквантовой криптографии, серверы перейдут на ML-DSA (CRYSTALS-Dilithium) или гибридные ключи. Хеши закреплённых SPKI изменятся, поскольку изменятся тип и кодировка ключа. Приложения, закрепляющие конечные сертификаты или открытые ключи, потребуют согласованных обновлений: (1) Выпустите новую версию приложения с постквантовым хешем SPKI в качестве резервного закрепления до миграции сервера. (2) Завершите миграцию сервера. (3) Выпустите обновление, удаляющее старое классическое закрепление. Переходный период требует тщательной координации. Приложения, закрепляющие промежуточные или корневые CA, пострадают меньше — изменится только ключ CA, причём не обязательно одновременно с ключами конечных сертификатов.

Почему закрепление хеша SubjectPublicKeyInfo (SPKI) предпочтительнее закрепления полного сертификата?

Закрепление сертификатов ограничивает доверие TLS конкретным сертификатом или открытым ключом, защищая от компрометации CA и MITM. Закрепление хеша SPKI (SHA-256 от SubjectPublicKeyInfo) предпочтительнее закрепления полного сертификата, поскольку оно устойчивее к перевыпуску сертификата. Android использует XML-конфигурацию безопасности сети; iOS — делегат URLSession с API SecTrust; OkHttp поддерживает CertificatePinner. Всегда включайте резервное закрепление, чтобы не заблокировать себе доступ. HPKP (заголовок HTTP в браузере) устарел. Закрепление можно обойти с помощью перехватов Frida и модификаций ROM. Постквантовая миграция ключей требует согласованных обновлений приложений для обновления хешей SPKI.