SSL Pinning: mahiyyəti, mexanizmi və MITM hücumlarından qorunma

SSL Pinning nədir?

SSL Pinning — təhlükəsizlik mexanizmidir, burada mobil və ya veb tətbiq etibarlı sertifikatı və ya serverin açıq açarını yadda saxlayır və sertifikatı yadda saxlanılanla uyğun gəlməyən istənilən əlaqəni rədd edir. Standart HTTPS sxemində müştəri sertifikatı kök CA-ya qədər etibar zənciri vasitəsilə yoxlayır — istənilən CA istənilən domen üçün sertifikat imzalaya bilər. SSL Pinning bu zəif nöqtəni aradan qaldırır: yüzlərlə CA-ya güvənmək əvəzinə, tətbiq yalnız bir konkret sertifikata güvənir.

Standart yoxlamanın problemi ondadır ki, yüzlərlə kök CA-dan hər hansı biri sizin domeniniz üçün etibarlı sertifikat verə bilər — təsadüfən və ya məcburiyyət altında. Öz kök sertifikatı olan korporativ proxy-ə çıxış əldə edən hücumçu, brauzer xəbərdarlığı olmadan MITM hücumu həyata keçirə bilər. SSL Pinning bu boşluğu bağlayır: CA saxta sertifikat versə belə, tətbiq onu rədd edəcək, çünki iz qeydə alınanla uyğun gəlmir.

Mobil tətbiqlərdə SSL Pinning xüsusilə vacibdir, çünki cihazlar tez-tez qorunmayan şəbəkələrdə işləyir — ictimai Wi-Fi, trafik yoxlaması olan korporativ proxy-lər, yoluxmuş giriş nöqtələri. Verizon Mobile Security Index (2025)-ə görə, mobil tətbiqlərdə məlumat sızmalarının 60%-dən çoxu nəqliyyat səviyyəsində trafikin ələ keçirilməsi ilə bağlıdır.

Mobil inkişafda SSL Pinning nə üçün lazımdır

Mobil tətbiqlər həssas məlumatlar ötürür — autentifikasiya tokenləri, ödəniş məlumatları, istifadəçilərin şəxsi məlumatları. Əlavə qorunma olmadan HTTPS cihazda kök sertifikatın əvəz edilməsi ilə kompromizə edilə bilər — məsələn, korporativ profil və ya zərərli tətbiq quraşdırıldıqdan sonra. SSL Pinning zəmanət verir ki, cihazda saxta kök CA quraşdırılsa belə, tətbiq sertifikatı öz ağ siyahısına əsasən yoxlamağa davam edəcək.

SSL Pinning necə işləyir?

SSL Pinning prosesi üç mərhələdən ibarətdir: izin əldə edilməsi, qoşulma zamanı yoxlama və xətanın idarə edilməsi. İnkişaf mərhələsində mühəndis server sertifikatının SHA-256 izini alır (openssl x509 -fingerprint -sha256) və onu tətbiq koduna və ya konfiqurasiya faylına yerləşdirir. Hər HTTPS sorğusunda tətbiq alınan sertifikatın izini hesablayır və onu yadda saxlanılanla müqayisə edir — dəyərlər uyğun gəlmirsə, əlaqə kəsilir.

Birinci mərhələ — qurma mərhələsində pinning: tərtibatçı server sertifikatlarını əvvəlcədən bilir və onların heşlərini yerləşdirir. İkinci mərhələ — ilk qoşulmada pinning (trust on first use, TOFU): tətbiq ilk sorğuda sertifikatı yadda saxlayır və bütün sonrakı sorğuları yoxlamaq üçün istifadə edir. TOFU dinamik mühitlər üçün əlverişlidir, lakin ilk hücumda həssasdır — əgər ilk əlaqə artıq ələ keçirilibsə, saxta sertifikat etibarlı olaraq qəbul ediləcək.

Kritik detal — ehtiyat izlər (backup pins). Sertifikatların istifadə müddəti var və onlar dəyişdirildikdə, yenilənməmiş tətbiq serverlə əlaqəni itirəcək. Mühəndislər 2–3 əlavə iz əlavə edir — məsələn, ehtiyat sertifikatın izi və kök CA-nın izi. Əsas sertifikat dəyişərsə, tətbiq backup pins-ə əsasən yoxlayır və əlaqə işləməyə davam edir.

# Sertifikatın SHA-256 izinin əldə edilməsi
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

SSL Pinning növləri

Pinning tətbiqinin iki əsas yanaşması var: bütöv sertifikata bağlama (certificate pinning) və açıq açara bağlama (public key pinning). Hər yanaşmanın təhlükəsizlik və istifadə rahatlığına təsir edən güclü tərəfləri və məhdudiyyətləri var.

Certificate Pinning

Sertifikata bağlama — ən sərt üsuldur. Tətbiq etibarlı sertifikatın surətini və ya onun SHA-256 izini saxlayır və hər HTTPS əlaqəsində server sertifikatı ilə müqayisə edir. Bu üsul maksimum təhlükəsizlik təmin edir, lakin rotasiya zamanı problemlər yaradır — sertifikatlar adətən 1–2 il müddətində etibarlıdır, bundan sonra tətbiqin məcburi yenilənməsi tələb olunur. Nəzarət olunan yeniləmə dövrü olan kritik sistemlər üçün tövsiyə olunur.

Public Key Pinning

Açıq açarın fiksasiyası — daha çevik yanaşma. Bütöv sertifikat əvəzinə tətbiq yalnız serverin RSA və ya ECDSA açıq açarını yadda saxlayır. Açar, şirkət eyni açar cütündən istifadə edərsə, sertifikatın yenidən verilməsində dəyişməz qala bilər. Bu, tətbiq yeniləmələrinin tezliyini azaldır. Lakin açar kompromizə edilərsə, bütün müştərilərdə kaskad dəyişdirmə tələb olunacaq.

iOS-da SSL Pinning

Apple platformasında SSL Pinning URLSession delegatı vasitəsilə tətbiq olunur. Tərtibatçı URLSessionDelegate protokolunu tətbiq edən sinif yaradır və didReceive challenge metodunu ləğv edir, burada server sertifikatını yadda saxlanılan izlərə qarşı əl ilə yoxlayır. Alternativ yanaşma — konfiqurasiyanı sadələşdirən Alamofire ServerTrustManager ilə istifadə.

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Nümunədə, nümayəndə URLSession-dan autentifikasiya sorğusu alır, challenge-dan serverTrust çıxarır və sertifikatın SHA-256 izini yadda saxlanılanla müqayisə edir. İz uyğun gələrsə — əlaqə davam edir, əks halda challenge rədd edilir. İstehsal üçün bir neçə backup pins yoxlaması və monitorinq üçün xəta qeydiyyatı əlavə etmək tövsiyə olunur.

iOS-da Network Security Config

iOS 14-dən etibarən Apple Info.plist vasitəsilə Certificate Pinning üçün daxili dəstək əlavə etdi. Tərtibatçı NSAppTransportSecurity açarında NSPinnedDomains alt lüğəti ilə etibarlı sertifikatları göstərir. Bu yanaşma kod yazmağı tələb etmir, lakin daha az çevikdir — pins-i dinamik dəyişdirmək və ya yoxlama xətalarını qeyd etmək mümkün deyil.

Android-də SSL Pinning

Android-də SSL Pinning tətbiqinin üç əsas üsulu var: OkHttp kitabxanasının CertificatePinner vasitəsilə, Network Security Config XML vasitəsilə və HttpsURLConnection-da xüsusi yoxlama vasitəsilə. OkHttp — Retrofit və digər HTTP müştərilərində istifadə olunan ən populyar və tövsiyə olunan yanaşmadır.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // ehtiyat pin
    .build()

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

OkHttp konfiqurasiyasında tərtibatçı domeni və bir və ya bir neçə SHA-256 izini göstərir. İlk izdə OkHttp server sertifikatını göstərilən pins ilə müqayisə edir. Uyğunluq yoxdursa, müştəri SSLPeerUnverifiedException atır. Backup pin məcburidir — onsuz sertifikat dəyişdikdə API sorğuları dərhal uğursuz olmağa başlayacaq.

Android-də Network Security Configuration

Android API 24-dən etibarən XML konfiqurasiyası vasitəsilə deklarativ Certificate Pinning dəstəkləyir. res/xml/network_security_config.xml faylı domenlərin və onların izlərinin siyahısını ehtiva edir. Bu üsul statik konfiqurasiyalar üçün əlverişlidir, lakin TOFU və ya anomaliyaların qeydiyyatı ilə xüsusi yoxlama məntiqini tətbiq etməyə imkan vermir.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

SSL Pinning-in üstünlükləri və çatışmazlıqları

SSL Pinning mobil tətbiqin təhlükəsizliyini əhəmiyyətli dərəcədə artırır, lakin əməliyyat mürəkkəbliyi gətirir. Əsas üstünlük — kök CA-lar kompromizə edilsə belə MITM hücumlarından qorunma. Tətbiq yalnız tərtibatçı tərəfindən açıq şəkildə göstərilən sertifikatlara güvənir, bütün ictimai sertifikat mərkəzləri infrastrukturuna deyil. Bu, xüsusilə maliyyə tətbiqləri, mesajlaşma proqramları və həssas məlumatları olan tətbiqlər üçün kritikdir.

Əsas çatışmazlıq — sertifikat rotasiyasının mürəkkəbliyi. Sertifikat müddəti bitərsə və ya ləğv edilərsə, tətbiqi yeniləməyən istifadəçilər əlaqəni itirir. Bu, backup pins və tədricən yeniləmə mexanizmi ilə həll olunur: yeni tətbiq köhnə və yeni sertifikatı bilir, istifadəçilər tam yeniləndikdən sonra köhnə pin koddan silinir. Minimum 2 backup pins qoymaq tövsiyə olunur — biri cari sertifikat üçün, biri gələcək üçün.

Başqa bir kompromis — pinning-i söndürmədən trafikin sazlanması üçün ictimai proxy-lərdən (Charles Proxy, Burp Suite) istifadə edə bilməmək. Bu, inkişaf mərhələsində şəbəkə sorğularının sazlanmasını çətinləşdirir. Həll — şərti kompilyasiya: debug qurmasında pinning söndürülür, release-də isə aktivdir. OWASP keçid üçün BuildConfig.DEBUG bayrağından istifadə etməyi tövsiyə edir.