SSL Pinning: что это и когда использовать

Что такое SSL Pinning?

SSL pinning (пиннинг сертификатов) — это техника безопасности, при которой приложение принимает только определённые сертификаты или публичные ключи при подключении к серверу, а не доверяет любому сертификату, подписанному доверенным центром сертификации (CA).

В стандартном TLS доверие иерархическое: браузер или ОС доверяют набору корневых CA (~150 на большинстве систем), и любой сертификат, подписанный ими (или их посредниками), принимается. Это удобно, но создаёт большую поверхность атаки. Если хотя бы один CA скомпрометирован, злоумышленники могут выпустить валидные сертификаты для любого домена.

Пиннинг сужает поверхность атаки, жёстко задавая ожидаемый сертификат или ключ в приложении. Если сервер предъявляет другой сертификат — даже подписанный доверенным CA — соединение отклоняется.

Зачем нужен пиннинг

Стандартная модель доверия через CA имеет известные слабости:

• Компрометация CA — в 2011 году DigiNotar был взломан, и были выпущены поддельные сертификаты для Google, Yahoo, Mozilla. Злоумышленники использовали их для MITM-атак против иранских пользователей
• Давление государства — государственные органы могут заставить CA в своей юрисдикции выпускать сертификаты для слежки
• Ошибочная выдача — CA случайно выдавали сертификаты неавторизованным сторонам (инциденты Symantec, 2015–2017)
• Корпоративные прокси — компании устанавливают корневые CA на устройства сотрудников для перехвата SSL/TLS проверку-трафика

Пиннинг защищает от всех этих сценариев, позволяя приложению независимо верифицировать личность сервера.

Что можно «закрепить»

Существует несколько стратегий пиннинга с разными компромиссами:

Пиннинг публичного ключа — самый распространённый выбор: обеспечивает сильную безопасность и переживает обновления сертификата, если генерировать новые сертификаты с той же ключевой парой или закреплять резервные ключи.

Методы реализации

HTTP Public Key Pinning (HPKP) — устарел

HPKP был механизмом пиннинга через проверку HTTP-заголовков в браузерах:

Public-Key-Pins:
  pin-sha256="base64+primary==";
  pin-sha256="base64+backup==";
  max-age=5184000;
  includeSubDomains

HPKP устарел в 2018 году и удалён из Chrome 72. Причины: риск «окирпичивания» сайтов при ошибке в настройке (перманентный отказ в обслуживании), сложность ротации ключей и появление Certificate Transparency как альтернативы.

Пиннинг в мобильных приложениях

Пиннинг наиболее распространён в мобильных приложениях, где вы контролируете клиент:

// Android — OkHttp certificate pinning
CertificatePinner pinner = new CertificatePinner.Builder()
    .add("api.example.com",
         "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .add("api.example.com",
         "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBB=") // резервный
    .build();

OkHttpClient client = new OkHttpClient.Builder()
    .certificatePinner(pinner)
    .build();

Certificate Transparency как альтернатива

Certificate Transparency требует от CA логировать каждый выданный сертификат в публичные, аудируемые журналы. Браузеры проверяют наличие сертификатов в CT-логах. Это не предотвращает ложную выдачу, но делает её обнаруживаемой. С 2018 года Chrome требует CT-логирование для всех новых сертификатов.

Когда использовать пиннинг

Пиннинг уместен когда:

• Мобильные приложения, общающиеся с вашим API документацию — вы контролируете и клиент, и сервер, можете координировать ротацию ключей
• Высокобезопасные приложения — банкинг, здравоохранение, государственные системы, где MITM-атаки — реальная угроза
• IoT-устройства — встроенные системы, подключающиеся к конкретным серверам
• Внутренние сервисы — межсервисная коммуникация в вашей инфраструктуре (mutual TLS с пиннингом)

Пиннинг НЕ подходит для:

• Публичных сайтов — вы не контролируете, какие сертификаты принимают пользователи
• Приложений, подключающихся к сторонним API — невозможно предсказать ротацию сертификатов
• Ситуаций без зрелого управления ключами — ошибка пиннинга может вызвать полный отказ

Риски и подводные камни

• «Окирпичивание» — если закреплённые сертификаты истекут без резервных пинов, приложение не сможет подключиться. Для мобильных — нужно обновление через магазин приложений, потенциально дни простоя
• Сложность ротации ключей — нужно закреплять минимум два ключа (основной + резервный) и иметь план ротации
• Сложность отладки — ошибки пиннинга выглядят как обычные TLS-ошибки. Добавляйте информативные сообщения
• Конфликты с CDN — CDN вроде Cloudflare терминируют TLS своими сертификатами. Пиннинг к сертификату origin сломается
• Обход на рутированных устройствах — на рутированных устройствах пиннинг можно отключить инструментами вроде Frida

Лучшие практики

• Закрепляйте публичный ключ (SPKI-хэш), а не полный сертификат
• Всегда включайте минимум один резервный пин от другого CA
• Реализуйте отчёты об ошибках пиннинга для обнаружения проблем до аварий
• Планируйте ротацию ключей до развёртывания пиннинга
• Мониторьте ваш домен с помощью Enterno.io для обнаружения изменений сертификатов и истечения сроков
• Для мобильных приложений предусмотрите механизм удалённого обновления пинов без обновления приложения

Заключение

SSL pinning — мощная техника безопасности, сужающая модель доверия за пределы иерархии CA. Наиболее эффективен для мобильных приложений и внутренних сервисов. Однако вносит операционную сложность — ошибки конфигурации могут вызвать аварии хуже тех атак, от которых защищают. Используйте пиннинг когда модель угроз это оправдывает, всегда закрепляйте резервные ключи и комбинируйте с мониторинг сайтов Certificate Transparency.