Certificate Pinning: bu nədir, mexanizmi və bərkitmə üsulları

Certificate Pinning nədir?

Certificate Pinning — tətbiqin etibarlı sertifikatın izini (fingerprint) saxladığı və HTTPS bağlantısı qurmaq üçün yeganə meyar kimi istifadə etdiyi təhlükəsizlik texnikasıdır. Standart TLS modelində müştəri server sertifikatının etibarlı kök CA tərəfindən imzalandığını yoxlayır — sistemdə əvvəlcədən quraşdırılmış yüzlərlə mərkəzdən hər hansı biri. Certificate Pinning bu zənciri birbaşa yoxlama ilə əvəz edir: sertifikat saxlanılmış nümunəyə uyğun olmalı və ya gözlənilən açıq açarı ehtiva etməlidir.

Standart modelin problemi CA kompromatlaşması hadisələrindən sonra aydın oldu — DigiNotar (2011), Comodo (2011), TrustCor (2022). Əgər CA domeniniz üçün saxta sertifikat verirsə, brauzer və ya tətbiq onu etibarlı qəbul edir. Certificate Pinning bu hücumun qarşısını alır: hətta mükəmməl imzalanmış saxta sertifikat da rədd ediləcək, çünki onun izi tətbiqdə bərkidilmiş izlə uyğun gəlmir.

Pinning termini ingiliscə pin — «sancaq» və ya «bərkidici» sözündən gəlir: tərtibatçı etibarlı sertifikatı bərkidir və ondan hər hansı kənarlaşma bağlantını bloklayır. Mitre CWE-295 tədqiqatına görə, düzgün olmayan sertifikat yoxlaması mobil tətbiqlərdə ən təhlükəli təhlükəsizlik səhvlərinin top-10 siyahısında qalır və Certificate Pinning onun qarşısının alınmasının birbaşa üsuludur.

Certificate Pinning-in tarixi və təkamülü

Əvvəlcə Certificate Pinning brauzerlərdə HPKP (HTTP Public Key Pinning) mexanizmi vasitəsilə istifadə olunurdu, RFC 7469-da standartlaşdırılmışdır. Tərtibatçı gözlənilən açarların heşləri ilə HTTP Public-Key-Pins başlığı göndərirdi və brauzer onları müəyyən müddətə yadda saxlayırdı. Lakin HPKP təhlükəli oldu: konfiqurasiyada bir səhv saytı aylarla bloklaya bilərdi. 2018-ci ildə Chrome HPKP dəstəyini dayandırdı və indi standart proqram təminatı reallaşdırması oldu — mobil tətbiq daxilində və ya brauzer genişlənməsində.

Certificate Pinning necə işləyir?

Certificate Pinning prosesi üç əsas mərhələni əhatə edir: izin hesablanması, bağlantı zamanı yoxlama və xətanın işlənməsi. Hazırlıq mərhələsində tərtibatçı istehsal serverinin sertifikatının və ya açıq açarının SHA-256 heşini alır. GDPR və PCI DSS uyğun tətbiqlər üçün zəncirdə aralıq CA ların izlərini də bərkitmək tələb olunur.

Hər HTTPS sorğusunda tətbiq TLS autentifikasiyası callback-ni ələ keçirir, server sertifikatını çıxarır və onun SHA-256 heşini hesablayır. Bu heş saxlanılmış etibarlı izlər siyahısı ilə müqayisə edilir. Uyğunluq tapılarsa — bağlantı davam edir. Tapılmazsa — tətbiq bağlantını kəsməli və təcavüzkara tətbiq detallarını açıqlamadan xəta barədə məlumat verməlidir.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

Funksiya serverdən X509Certificate obyekti və gözlənilən heşi qəbul edir. Əvvəlcə sertifikatın açıq açarı çıxarılır, SHA-256 heşi hesablanır və Base64-ə kodlanır. Nəticə gözlənilən izlə müqayisə edilir. İstehsalda rotasiyanı dəstəkləmək üçün 2–3 izdən ibarət massivlə yoxlama əlavə etməyə dəyər.

Certificate Pinning vs Public Key Pinning

Pinning tətbiq edərkən hansı kriptoqrafik obyektin bərkidiləcəyini seçmək lazımdır. Certificate Pinning X.509 sertifikatının özünə — onun seriya nömrəsinə, qüvvədəolma müddətinə və bütün zəncirinə bağlanır. Public Key Pinning sertifikat daxilində yalnız açıq açarı bərkidir, qalan sahələri nəzərə almır. Seçim əməliyyat xərclərinə əhəmiyyətli dərəcədə təsir edir.

Public Key Pinning — əksər layihələr üçün üstünlük verilən seçimdir. Serverlərin açıq açarları adətən sertifikatın yenidən buraxılmasında dəyişməz qalır — şirkət sadəcə köhnə açarı yeni sertifikatla imzalayır. Bu o deməkdir ki, açar cütü dəyişməyibsə, tətbiq sertifikat dəyişikliyindən sonra yenilənmə tələb etmir. Certificate Pinning isə tərtibatçının həm serveri, həm də müştəri kodunu tam idarə etdiyi ssenarilər üçün tövsiyə olunur, məsələn, ciddi yeniləmə dövrü olan korporativ tətbiqlərdə.

Trust On First Use (TOFU)

TOFU — Certificate Pinning-in əvvəlcədən konfiqurasiya edilmədiyi, lakin sertifikatı ilk bağlantıda yadda saxladığı strategiyadır. Bu yanaşma hansı serverə qoşulacağını əvvəlcədən bilməyən tətbiqlər üçün əlverişlidir. Dezavantaj — ilk hücuma qarşı zəiflik: ilk bağlantı ələ keçirilərsə, saxta sertifikat etibarlı qəbul ediləcək. TOFU SSH bağlantılarında və bəzi P2P protokollarında tətbiq olunur.

iOS və Android-də reallaşdırma

Hər iki platformada Certificate Pinning şəbəkə steki səviyyəsində TLS bağlantısının ələ keçirilməsi ilə reallaşdırılır. iOS-da URLSession delegate və ya Alamofire ServerTrustManager istifadə olunur. Android-də üstünlük verilən üsul — məşhur HTTP müştərilərinə daxil olan və hər domen üçün çoxlu iz konfiqurasiyasını dəstəkləyən OkHttp CertificatePinner-dir.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Swift funksiyasında serverTrust-dan sertifikatlar zənciri çıxarılır, hər biri üçün SHA-256 heşi hesablanır və nəticə gözlənilənlə müqayisə edilir. Zəncirdəki bütün sertifikatlar üzərində keçid aralıq CA səviyyəsində pinning-i reallaşdırmağa imkan verir — aralıq sertifikat uyğun gələrsə, bağlantı qəbul edilir. Bu, leaf sertifikatlarının rotasiyasında çeviklik verir.

Android üçün TrustManager (xüsusi)

Əgər tətbiq OkHttp istifadə etmirsə, Certificate Pinning xüsusi X509TrustManager vasitəsilə reallaşdırıla bilər. Bu üsul daha çox kod tələb edir, lakin yoxlama prosesi üzərində tam nəzarət verir. TrustManager checkServerTrusted metodunu ləğv edir, burada tərtibatçı əl ilə server sertifikatlarını yoxlayır və etibarlılıq qərarı verir. Yalnız OkHttp kitabxanasının mövcud olmadığı xüsusi ssenarilər üçün tövsiyə olunur.

Certificate Pinning tətbiqində səhvlər

Ən çox yayılmış səhv — ehtiyat pinlərin olmamasıdır. Tərtibatçı bir sertifikat izi qoyur və onun müddəti bitdikdə istifadəçilər kütləvi şəkildə bağlantını itirirlər. Minimal icazə verilən konfiqurasiya — iki iz: cari sertifikat və ehtiyat. Optimal — üç: cari, ehtiyat və kök CA izi fallback kimi.

İkinci səhv — pinlərin kodda açıq şəkildə saxlanmasıdır. APK və ya IPA-ya çıxışı olan təcavüzkar izləri asanlıqla çıxarıb əvəz edə bilər. Heşlərin obfuskasiyası tövsiyə olunur: sətri hissələrə bölmək, şifrələmə ilə resurslarda saxlamaq və ya runtime vasitəsilə hesablamaq. Android üçün sətir sabitlərinin obfuskasiyası ilə ProGuard effektivdir.

Üçüncü səhv — development sertifikatı səviyyəsində pinning-dir. Development və istehsal sertifikatları adətən fərqlidir, lakin tərtibatçılar tez-tez release quruluşunda pinləri dəyişməyi unudurlar. Nəticə — istehsal tətbiqi serverə qoşula bilmir. Həll — BuildConfig və ya flavour-spesifik resurslar vasitəsilə debug və release üçün ayrıca pin konfiqurasiyası.

• Ignoring certificate chain — aralıq CA-ları nəzərə almadan yalnız leaf sertifikatının yoxlanması, rotasiyada bağlantını qırır
• Hardcoded dates — yenilənmədən sonra dəyişməyən sərt kodlaşdırılmış sertifikat bitmə tarixləri
• No monitoring — Certificate Pinning xətaları üçün alertlərin olmaması, nəticədə problemlər yalnız istifadəçilərdən aşkarlanır
• TOFU olmadan yoxlama — əlavə yoxlama olmadan Trust On First Use istifadəsi, ilk MITM hücumuna saxta sertifikatı bərkitməyə imkan verir