Certificate pinning: закрепление сертификата и связанные риски

Обычная проверка сертификата основана на доверии ко множеству центров сертификации: подойдёт любой сертификат, подписанный любым центром из списка устройства. Значит, ошибочная или злонамеренная выдача сертификата на ваш домен любым из сотен центров сработает. Certificate pinning сужает круг доверия. Приложение заранее знает, какой сертификат, какой открытый ключ или какой издатель допустим для его сервера, и отвергает всё остальное, даже если подпись формально верна.

В результате подмена трафика с помощью поддельного, но формально валидного сертификата перестаёт работать. Клиент видит несоответствие закреплённому значению и разрывает соединение.

Есть несколько вариантов, и от выбора зависит устойчивость. Можно закрепить конкретный сертификат сервера, но тогда каждое продление требует обновить приложение. Чаще закрепляют хеш открытого ключа, ведь при продлении можно оставить тот же ключ. Ещё один вариант — закрепить промежуточный или корневой сертификат, что гибче, но защищает слабее, потому что доверие остаётся ко всему, что под ним выдано.

Надёжная практика предполагает резервный закреплённый ключ, который заранее сгенерирован и хранится отдельно. Если основной ключ придётся срочно менять, приложение примет запасной без выпуска экстренного обновления.

Основы построения пути доверия описаны на странице про цепочку доверия.

Наиболее частое применение — мобильные приложения банков, мессенджеров и других чувствительных сервисов. Разработчик знает свой сервер, поэтому может встроить в приложение ожидаемый ключ. В системах Android и iOS для этого есть штатные механизмы конфигурации сети.

В веб-браузерах у идеи была своя история. Существовал заголовок HTTP Public Key Pinning, HPKP, который позволял сайту закреплять ключи в браузере посетителя. Его признали слишком рискованным и удалили из основных браузеров, так как ошибка могла навсегда закрыть доступ к собственному сайту. Вместо него развивались журналы Certificate Transparency и записи CAA в DNS.

Главная опасность — самоблокировка. Если ключ поменялся, а приложение с закреплённым значением не обновлено, оно перестаёт подключаться к серверу. Пользователи старых версий видят ошибки, и вы не можете исправить это на стороне сервера. Для сайтов с HPKP этот эффект длился весь срок действия закрепления.

Второе неудобство связано с отладкой и защитой. Анализ трафика приложения собственным прокси, который применяют разработчики и специалисты по безопасности, ломается, потому что прокси выдаёт свой сертификат. Корпоративные средства проверки трафика с подменой сертификата тоже не сработают, и это осознанное следствие.

Наконец, закрепление не защищает от компрометации самого устройства: при достаточных правах злоумышленник может отключить проверку или изменить приложение, и мы не считаем закрепление панацеей.

Обычному пользователю посмотреть закрепление в приложении нельзя, но признаки заметны: если поставить на устройство собственный сертификат для просмотра трафика, обычные сайты в браузере откроются, а приложение с закреплением сообщит об ошибке сети. Это нормально и означает, что закрепление работает.

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

Если полное закрепление слишком рискованно, есть более мягкие меры. Записи CAA в DNS сообщают, какие центры вправе выдавать сертификаты на домен, и добросовестные центры их проверяют. Мониторинг журналов Certificate Transparency оповещает, когда на ваше имя выдан неожиданный сертификат, и позволяет отреагировать быстро. Для собственных приложений применяют закрепление ключа промежуточного центра с запасными вариантами и удалённым обновлением конфигурации. Выбор зависит от того, насколько чувствительны данные и насколько вы контролируете обновления клиентов.