Certificate Pinning (sertifikatni bog‘lash) — bu mobil ilova server sertifikati oldindan ma’lum namunaga mos keladiganligini tekshiradigan va oddiygina CA zanjiridagi har qanday sertifikatga ishonmaydigan xavfsizlik texnikasidir. Yuzlab sertifikatlashtirish markazlariga tayanadigan oddiy TLS tekshiruvidan farqli o‘laroq, pinning ishonchni bitta aniq sertifikat yoki uning ochiq kalitiga toraytiradi. OWASP Mobile Security Testing Guide (2024) ma’lumotlariga ko‘ra, Certificate Pinning joriy qilinishi sertifikat almashtirish bilan bog‘liq Man-in-the-Middle hujumlarining 100% stsenariylarini yopadi. OWASP MSTG, 2024
Asosiy fikrlar
Certificate Pinning — bu ilova server sertifikatining namunasini saqlaydigan (yoki “tikadigan” — pin) va har bir ulanishda olingan sertifikatni ushbu namuna bilan taqqoslaydigan xavfsizlik mexanizmidir. Agar sertifikat mos kelmasa — hatto u ishonchli sertifikatlashtirish markazi tomonidan rasman imzolangan bo‘lsa ham — ulanish uziladi. Bu hujumchi buzilgan CA orqali soxta sertifikat olgan hujumlardan himoya qiladi (DigiNotar 2011 yoki Comodo 2011 da bo‘lgani kabi).
Pinning jarayoni uch bosqichdan iborat: ishonchli namunadan sertifikat yoki ochiq kalitning barmoq izini (fingerprint) olish; bu izni ilova kodi yoki resurslarida saqlash; TLS-handshake bosqichida taqqoslash. Dasturchi butun sertifikatning SHA-256 izini yoki faqat ochiq kalitning izini (Public Key Pinning) mahkamlashi mumkin. Ikkinchi yondashuv afzal: sertifikat uzaytirilganda ochiq kalit ko‘pincha bir xil qoladi va ilova server bilan aloqani yo‘qotmaydi. OWASP tavsiyasiga ko‘ra minimal pinlar soni — 2: bitta joriy va bitta zaxira kalitlar rotatsiyasi holati uchun. OkHttp va TrustKit kabi zamonaviy kutubxonalar qo‘shimcha dasturchi xarajatisiz har bir TLS ulanishida belgilangan pinlarni tekshirish jarayonini avtomatlashtiradi. Pinning standart TLS tekshiruvini almashtirmasligini, balki to‘ldirishini tushunish muhim: avval oddiy handshake sertifikat zanjiri validatsiyasi bilan amalga oshiriladi, so‘ngra qo‘shimcha pinning tekshiruvi o‘tkaziladi. Bunday ikki darajali himoya CA buzilishi, shu jumladan sertifikatlarni xato berish holatlari va sertifikatlashtirish markazlari infratuzilmasiga hujumlar bilan bog‘liq zaifliklarni bartaraf qiladi.
Certificate Pinning ni joriy qilishning bir necha yondashuvlari mavjud, har biri o‘z saqlash va tekshirish xususiyatlariga ega. Usulni tanlash ilova arxitekturasiga, sertifikatlarni yangilash chastotasiga va moslashuvchanlik talablariga bog‘liq.
| Pinning turi | Nima saqlanadi | Moslashuvchanlik | Foydalanish namunasi |
|---|---|---|---|
| Certificate Pinning | Butun X.509 sertifikati | Past | 1–2 yilga qattiq sertifikat |
| Public Key Pinning | Ochiq kalit (SPKI) | O‘rta | OWASP tomonidan tavsiya etilgan yondashuv |
| Hash Pinning | SHA-256 izi | O‘rta | OkHttp da mashhur (certificatePinner) |
| CA Pinning | Oraliq CA | Yuqori | Korporativ ilovalar |
Eng muvozanatli usul Public Key Pinning hisoblanadi, OWASP va Google tomonidan tavsiya etilgan. Aniq sertifikat (har 1–2 yilda o‘zgaradigan) o‘rniga ilova SubjectPublicKeyInfo izini — ochiq kalitning abstraksiyasini saqlaydi. Agar sertifikat bir xil kalit bilan uzaytirilsa (key reuse), pin amalda qoladi. Agar kalit o‘zgarsa — dasturchi ilova yangilanishiga oldindan zaxira pin qo‘shadi. Mobil loyihalarda min/max pins strategiyasi qo‘llaniladi: kamida 2 pin (shu jumladan zaxira) va ko‘pi bilan 4 pin, shishish va tekshirish vaqtining oshishini oldini olish uchun.
Muayyan pinning turini tanlash ilova arxitekturasiga va talablariga bog‘liq. Bitta domen orqali REST API bilan ishlaydigan umumiy mobil ilovalar uchun OkHttp yoki TrustKit orqali ikkita pinli Public Key Pinning maqbuldir. O‘z sertifikatlashtirish markaziga ega korporativ ilovalar uchun CA Pinning mos keladi — mijoz sertifikatlari o‘zgarganda yangilashni talab qilmaydi, chunki ishonch oxirgi sertifikatga emas, CA ga bog‘liq. IoT va tizimlashtirilgan (embedded) tizimlar uchun to‘liq sertifikatni mahkamlash bilan Certificate Pinning tavsiya etiladi: qurilmalar kamdan-kam yangilanadi, shuning uchun butun ishonch zanjiri ustidan nazorat muhimdir. Pinlarning amal qilish muddatlarini kuzatish — majburiy amaliyot: sertifikat muddati tugashidan 30, 14 va 7 kun oldin ogohlantirishlarni sozlang, joriy sertifikat yaroqsiz bo‘lgunga qadar yangi pinlar bilan ilova yangilanishini chiqarishga ulgurish uchun. Yangi pinlar bilan yangilanishlarni chiqarishni avtomatlashtirish uchun Firebase Remote Config yoki ilovalar do‘konida yangi versiyasini nashr qilmasdan pinlar ro‘yxatini dinamik yangilashga imkon beradigan o‘z konfiguratsiya API sizdan foydalanish tavsiya etiladi.
Certificate Pinning mobil ilova xavfsizligini sezilarli darajada oshiradi, ammo dasturlash jamoasiga operativ yukni yuklaydi. Himoya afzalliklari va noto‘g‘ri joriy qilishda ulanish bloklanishi xavfini muvozanatlash muhim.
Asosiy afzallik — CA buzilishi holatlarini ham o‘z ichiga olgan Man-in-the-Middle hujumlaridan himoya qilishdir. Pinning hujumchi tomonidan chiqarilgan soxta sertifikatlarni yaroqsiz holga keltiradi: hatto CA soxtani imzolagan bo‘lsa ham, ilova uni rad etadi. Qo‘shimcha afzallik — trafikni tekshirish uchun sertifikatlarni almashtiradigan korporativ proksi-serverlardan himoya. Google Security Blog (2023) ma’lumotlariga ko‘ra, pinning li ilovalar faqat standart TLS tekshiruvidan foydalanadigan ilovalarga nisbatan trafikni ushlash orqali buzilish ehtimoli 86% kam.
Pinning ning asosiy kamchiligi — o‘zini bloklash xavfi: ilova yangilanishi chiqqunga qadar server sertifikati o‘zgarsa (uzaytirish, provayder almashtirish, kalitlar rotatsiyasi), foydalanuvchilar serverga kirishni yo‘qotadi. Qo‘shimcha kamchiliklar: sozlash qiyinligi (har bir sozlamalar o‘zgarishida pinlarni yangilash kerak), TrustKit dan foydalanganda APK hajmining 5–15 KB ga oshishi va yangi versiyasiz o‘zgarishlarni tez qaytarib bo‘lmasligi. Xavflarni minimallashtirish uchun zaxira pinlar, har 2–3 oyda avtomatik rotatsiya va ilova ham eski, ham yangi sertifikatni qabul qiladigan yengillik davri (grace period) qo‘llaniladi. Shuningdek, pinning yoqilgan holda dasturlash vaqtida tarmoq so‘rovlarini sozlash uchun proksi vositalardan (Burp Suite, Charles) foydalanib bo‘lmasligini hisobga olish muhim — ishlab chiqish versiyalari uchun pinning BuildConfig.DEBUG bayrog‘i orqali o‘chirilishi kerak, QA testlari esa himoya yoqilgan holda nashr imzosi bilan o‘tkazilishi lozim. Ba’zi jamoalar ishlab chiqish bosqichida ham himoyani saqlash uchun alohida pinning sertifikati bilan staging domenidan foydalanadi.
Certificate Pinning ni Android da OkHttp — tarmoq so‘rovlari uchun standart kutubxona — yordamida joriy qilish misolini ko‘rib chiqamiz. OkHttp ochiq kalitlarning SHA-256 heshlarini qabul qiladigan o‘rnatilgan CertificatePinner ni taqdim etadi.
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()
Yuqoridagi kodda api.example.com domeni uchun ikkita pin qo‘shamiz: asosiy (joriy sertifikat) va zaxira (rotatsiya holati uchun). OkHttp avtomatik ravishda server sertifikati belgilangan SHA-256 izlaridan biriga mos kelishini tekshiradi. Sertifikatning SHA-256 izini olish uchun buyruq ishlatiladi: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Izlarni kodda ochiq holda emas, balki shifrlangan yoki yashirilgan holda saqlash muhim: MobSF statik tahlili DEX fayllarida yalang‘och SHA-256 satrlarini osongina topadi. Pinlarni AES orqali shifrlangan res/raw resurslarida saqlash va ilova ishga tushganda mahalliy kod (NDK/JNI) orqali shifrini ochish tavsiya etiladi.
iOS da Certificate Pinning uchun asosiy vosita ochiq manbali TrustKit kutubxonasidir. OkHttp dan farqli o‘laroq, TrustKit Info.plist orqali deklarativ tarzda sozlanadi, bu esa ilovani qayta kompilyatsiya qilmasdan pinlarni o‘zgartirish imkonini beradi. Konfiguratsiya domenlar lug‘ati va ochiq kalitlarning SHA-256 izlari massivini o‘z ichiga oladi. TrustKit avtomatik ravishda NSURLSession so‘rovlarini tutib oladi va ma’lumotlarni uzatish boshlanishidan oldin sertifikatlarni tekshiradi. TrustKit ning asosiy xususiyati — pin tekshirish hisobotlarini qo‘llab-quvvatlashi: kutubxona pin mos kelmasa belgilangan endpoint ga hisobot yuborishi mumkin, bu esa sertifikat anomaliyalariga tezkor munosabat bildirish imkonini beradi. Apple iOS 14 dan boshlab Info.plist da mahalliy NSPinnedDomains mexanizmini ham taqdim etadi, ammo TrustKit yanada moslashuvchan sozlash, hisobotlarni qo‘llab-quvvatlash va tizim yangilanishisiz pinlarni issiq almashtirish imkoniyati tufayli afzal tanlov bo‘lib qolmoqda. TrustKit URLSession bilan didReceiveChallenge delegati orqali integratsiyalanadi, pin tekshiruvi muvaffaqiyatli bo‘lganda .performDefaultHandling va mos kelmasa .cancelAuthenticationChallenge qaytaradi. Pin tekshirish hisobotlarini kuzatish uchun xatolar chastotasini tahlil qiladigan alohida endpoint sozlash tavsiya etiladi: agar hisobotlar soni keskin oshsa — bu MitM hujumini yoki zudlik bilan pin yangilashni talab qiladigan sertifikat muddatining yaqinlashayotgan tugashini ko‘rsatishi mumkin.
Ko‘p so‘raladigan savollar
Certificate Pinning — bu telefondagi do‘stning barmoq izini saqlashga o‘xshaydi: serverning “to‘g‘ri” sertifikati qanday ko‘rinishini eslab qolasiz va kimdir “rasmiy” markazdan guvohnoma ko‘rsatsa ham, endi hech kimga ishonmaysiz.
Oddiy HTTPS yuzlab markazlardan istalgan CA tomonidan imzolangan istalgan sertifikatga ishonadi. Certificate Pinning “yuqoridan” tekshiruv qo‘shadi: sertifikat nafaqat amalda bo‘lishi, balki ilova kodida mahkamlagan aniq sertifikat bo‘lishi kerak.
2–3 pin saqlash tavsiya etiladi: joriy va yangi sertifikat uchun zaxira pin. Sertifikat o‘zgarishidan 1–2 oy oldin kelajakdagi sertifikat pini qo‘shilgan yangi ilova versiyasini chiqaring. O‘zgarishdan so‘ng eski pin keyingi nashrdan olib tashlanadi.
Ha, mumkin. Pinning Let's Encrypt ni ham o‘z ichiga olgan istalgan sertifikatlar bilan ishlaydi. Bepul sertifikatlarning qisqa amal qilish muddati (3 oy) borligini esda tutish muhim, shuning uchun zaxira pinlar strategiyasi va avtomatik rotatsiya majburiy bo‘ladi.
Pinning ni test qilish uchun Burp Suite yoki mitmproxy dan foydalaning. Agar pinning to‘g‘ri sozlangan bo‘lsa, proksi vosita trafikni ushlay olmaydi — ulanish handshake bosqichida uziladi. Integratsiya testlari uchun OkHttp dan MockWebServer dan foydalaning.
Xulosa
Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz
IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.