Certificate Pinning: що це, способи прив’язки сертифікатів та як реалізувати

Переваги та недоліки Certificate Pinning

Certificate Pinning суттєво підвищує безпеку мобільного застосунку, але накладає operational-навантаження на команду розробки. Важливо зважити переваги захисту та ризики блокування з’єднання при неправильній реалізації.

Головна перевага — захист від Man-in-the-Middle атак, включаючи випадки компрометації CA. Pinning робить непотрібними підроблені сертифікати, випущені зловмисником: навіть якщо CA підписав підробку, застосунок її відхилить. Додатковий плюс — захист від корпоративних проксі-серверів, що підмінюють сертифікати для інспекції трафіку. За даними Google Security Blog (2023), застосунки з pinning мають на 86% менше шансів бути зламаними через перехоплення трафіку порівняно із застосунками, що використовують лише стандартну TLS-перевірку.

Основний недолік pinning — ризик самоблокування: якщо сертифікат сервера змінюється (продовження, зміна провайдера, ротація ключів) до виходу оновлення застосунку, користувачі втрачають доступ до сервера. Додаткові мінуси: складність налагодження (при кожній зміні налаштувань потрібно оновлювати піни), збільшення розміру APK на 5–15 KB при використанні TrustKit та неможливість швидко відкотити зміни без нового релізу. Для мінімізації ризиків застосовують backup-піни, автоматичну ротацію через 2–3 місяці та grace-період, коли застосунок приймає і старий, і новий сертифікат. Важливо також враховувати, що при розробці з увімкненим pinning неможливо використовувати проксі-інструменти (Burp Suite, Charles) для налагодження мережевих запитів — для dev-збірок pinning має бути вимкнений через BuildConfig.DEBUG флаг, а QA-тестування має проводитися на релізній сигнатурі з увімкненим захистом. Деякі команди використовують staging-домен з окремим pinning-сертифікатом для dev-середовища, щоб зберегти захист навіть на етапі розробки.

Реалізація Certificate Pinning в Android

Розглянемо приклад впровадження Certificate Pinning на Android з використанням OkHttp — стандартної бібліотеки для мережевих запитів. OkHttp надає вбудований CertificatePinner, який приймає SHA-256 хеші публічних ключів.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

У коді вище ми додаємо два піни для домену api.example.com: основний (поточний сертифікат) і backup-пін (на випадок ротації). OkHttp автоматично перевіряє, що сертифікат сервера збігається з одним із зазначених SHA-256 відбитків. Для отримання SHA-256 відбитка сертифіката використовується команда: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Важливо зберігати відбитки не у відкритому вигляді в коді, а зашифрованими або обфускованими: статичний аналіз MobSF легко знаходить голі SHA-256 рядки в DEX-файлах. Рекомендується зберігати піни в ресурсах res/raw, зашифровані через AES, і розшифровувати їх при старті застосунку через нативний код (NDK/JNI).

Реалізація на iOS через TrustKit

На iOS основним інструментом Certificate Pinning є бібліотека TrustKit із відкритим вихідним кодом. На відміну від OkHttp, TrustKit налаштовується декларативно через Info.plist, що дозволяє змінювати піни без перекомпіляції застосунку. Конфігурація включає словник із доменами та масивом SHA-256 відбитків публічних ключів. TrustKit автоматично перехоплює NSURLSession-запити і перевіряє сертифікати до початку передачі даних. Критична особливість TrustKit — підтримка pin validation reports: бібліотека може надсилати звіти на зазначений endpoint при неспівпадінні піна, що дозволяє оперативно реагувати на аномалії сертифікатів. Apple також надає нативний механізм NSPinnedDomains в Info.plist починаючи з iOS 14, але TrustKit залишається кращим вибором через більш гнучке налаштування, підтримку звітів та можливість гарячої заміни пінів без оновлення ОС. Важливо зазначити, що TrustKit інтегрується з URLSession через didReceiveChallenge делегат, повертаючи .performDefaultHandling при успішній перевірці піна та .cancelAuthenticationChallenge при неспівпадінні. Для моніторингу звітів pin validation рекомендується налаштувати окремий endpoint, який аналізує частоту помилок: якщо кількість звітів різко зростає — це може вказувати на атаку MitM або швидке закінчення сертифіката, що потребує негайного оновлення пінів.