Certificate Pinning: какво е това, методи за закрепване на сертификати и как да внедрим

Предимства и недостатъци на Certificate Pinning

Certificate Pinning значително повишава сигурността на мобилното приложение, но налага оперативно натоварване на екипа за разработка. Важно е да се претеглят ползите от защитата и риска от блокиране на връзката при неправилно внедряване.

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

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

Внедряване на 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: основен (текущ сертификат) и резервен (за случай на ротация). 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 — поддръжка на доклади за валидиране на пинове: библиотеката може да изпраща доклади до посочен endpoint при несъвпадение на pin, което позволява бърза реакция на аномалии в сертификатите. Apple също предоставя роден механизъм NSPinnedDomains в Info.plist от iOS 14, но TrustKit остава предпочитаният избор поради по-гъвкава конфигурация, поддръжка на доклади и възможност за гореща смяна на пинове без актуализация на системата. TrustKit се интегрира с URLSession чрез делегата didReceiveChallenge, връщайки .performDefaultHandling при успешна проверка на pin и .cancelAuthenticationChallenge при несъвпадение. За мониторинг на докладите за валидиране на пинове се препоръчва конфигуриране на отделен endpoint, който анализира честотата на грешките: ако броят на докладите рязко се увеличи — това може да показва MitM атака или предстоящо изтичане на сертификат, изискващо незабавно актуализиране на пиновете.