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