SSL Pinning: esensya, mekanismo at proteksyon laban sa mga pag-atake ng MITM

Ano ang SSL Pinning?

SSL Pinning — ay isang mekanismo ng seguridad kung saan ang isang mobile o web app ay naaalala ang pinagkakatiwalaang certificate o pampublikong key ng server at tinatanggihan ang anumang koneksyon na ang certificate ay hindi tumutugma sa nakaimbak. Sa karaniwang HTTPS scheme, ini-verify ng client ang certificate sa pamamagitan ng trust chain hanggang sa root CA — sinumang CA ay maaaring pumirma ng certificate para sa anumang domain. Tinatanggal ng SSL Pinning ang kahinaang ito: sa halip na magtiwala sa daan-daang CA, ang app ay nagtitiwala lamang sa isang partikular na certificate.

Ang problema ng karaniwang verification ay na ang alinman sa daan-daang root CA ay maaaring mag-isyu ng wastong certificate para sa iyong domain — hindi sinasadya o sa ilalim ng pagpilit. Ang isang attacker na nakakuha ng access sa corporate proxy na may sariling root certificate ay maaaring magsagawa ng MITM attack nang walang babala ng browser. Isinasara ng SSL Pinning ang kahinaang ito: kahit na mag-isyu ang CA ng pekeng certificate, tatanggihan ito ng app, dahil hindi tugma ang fingerprint sa naitala.

Sa mga mobile app, ang SSL Pinning ay lalong mahalaga dahil ang mga device ay madalas na gumagana sa hindi secure na mga network — pampublikong Wi-Fi, corporate proxy na may inspeksyon ng trapiko, mga infected na access point. Ayon sa Verizon Mobile Security Index (2025), higit sa 60% ng mga pagtagas ng data sa mobile app ay nauugnay sa pagharang ng trapiko sa antas ng transportasyon.

Bakit kailangan ang SSL Pinning sa mobile development

Ang mga mobile app ay nagpapadala ng sensitibong data — mga token ng authentication, impormasyon ng pagbabayad, personal na data ng mga user. Kung walang karagdagang proteksyon, ang HTTPS ay maaaring makompromiso sa pamamagitan ng pagpapalit ng root certificate sa device — halimbawa, pagkatapos mag-install ng corporate profile o malicious app. SSL Pinning ay ginagarantiyahan na kahit na ang isang pekeng root CA ay naka-install sa device, ang app ay patuloy na susuriin ang certificate ayon sa sarili nitong white list.

Paano gumagana ang SSL Pinning?

Ang proseso ng SSL Pinning ay binubuo ng tatlong yugto: pagkuha ng fingerprint, pagsuri sa koneksyon, at paghawak ng error. Sa yugto ng pag-develop, ang engineer ay kumukuha ng SHA-256 fingerprint ng server certificate (openssl x509 -fingerprint -sha256) at ini-embed ito sa code ng app o configuration file. Sa bawat HTTPS request, kinakalkula ng app ang fingerprint ng natanggap na certificate at inihahambing ito sa nakaimbak — kung hindi tugma ang mga halaga, ang koneksyon ay pinutol.

Unang yugto — pinning sa yugto ng build: alam na ng developer ang mga certificate ng server at ini-embed ang kanilang mga hash. Ikalawang yugto — pinning sa unang koneksyon (trust on first use, TOFU): naaalala ng app ang certificate sa unang request at ginagamit ito para i-verify ang lahat ng kasunod na request. Ang TOFU ay maginhawa para sa mga dynamic na kapaligiran, ngunit mahina sa unang pag-atake — kung ang unang koneksyon ay naharang na, ang pekeng certificate ay tatanggapin bilang pinagkakatiwalaan.

Kritikal na detalye — mga backup na fingerprint (backup pins). Ang mga certificate ay may expiration date, at kapag pinalitan ang mga ito, ang hindi na-update na app ay mawawalan ng koneksyon sa server. Ang mga engineer ay nagdaragdag ng 2–3 karagdagang fingerprint — halimbawa, fingerprint ng backup certificate at fingerprint ng root CA. Kung magbago ang pangunahing certificate, susuriin ng app ayon sa backup pins, at ang koneksyon ay patuloy na gagana.

# Pagkuha ng SHA-256 fingerprint ng certificate
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

Mga uri ng SSL Pinning

Mayroong dalawang pangunahing diskarte sa implementasyon ng pinning: pagtali sa buong certificate (certificate pinning) at pagtali sa pampublikong key (public key pinning). Bawat diskarte ay may mga kalakasan at limitasyon na nakakaapekto sa seguridad at kadalian ng pagpapanatili.

Certificate Pinning

Pagtali sa certificate — ang pinakamahigpit na paraan. Ang app ay nag-iimbak ng kopya ng pinagkakatiwalaang certificate o SHA-256 fingerprint nito at inihahambing sa server certificate sa bawat HTTPS na koneksyon. Ang paraang ito ay nagbibigay ng maximum na seguridad, ngunit lumilikha ng problema sa rotasyon — ang mga certificate ay karaniwang may bisa ng 1–2 taon, pagkatapos nito ay kinakailangan ang sapilitang pag-update ng app. Inirerekomenda para sa mga kritikal na sistema na may kontroladong cycle ng pag-update.

Public Key Pinning

Fixasyon ng pampublikong key — isang mas flexible na diskarte. Sa halip na buong certificate, ang app ay naaalala lamang ang RSA o ECDSA pampublikong key ng server. Ang key ay maaaring manatiling hindi nagbabago sa muling pag-isyu ng certificate, kung ang kumpanya ay gumagamit ng parehong key pair. Binabawasan nito ang dalas ng pag-update ng app. Gayunpaman, kung ang key ay nakompromiso, kakailanganin ang cascade replacement sa lahat ng client.

SSL Pinning sa iOS

Sa platform ng Apple, ang SSL Pinning ay ini-implement sa pamamagitan ng URLSession delegate. Ang developer ay lumilikha ng klase na nag-i-implement ng URLSessionDelegate protocol at nag-o-override ng method na didReceive challenge, kung saan manu-manong sinusuri ang server certificate laban sa mga nakaimbak na fingerprint. Alternatibong diskarte — paggamit ng Alamofire na may ServerTrustManager, na nagpapasimple ng configuration.

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)
        }
    }
}

Sa halimbawa, ang delegate ay tumatanggap ng authentication request mula sa URLSession, kinukuha ang serverTrust mula sa challenge at inihahambing ang SHA-256 fingerprint ng certificate sa nakaimbak. Kung tugma ang fingerprint — ang koneksyon ay ipinagpapatuloy, kung hindi ay tinatanggihan ang challenge. Para sa produksyon, dapat magdagdag ng pagsuri ng maraming backup pins at pag-log ng error para sa pagsubaybay.

Network Security Config sa iOS

Simula iOS 14, nagdagdag ang Apple ng built-in na suporta para sa Certificate Pinning sa pamamagitan ng Info.plist. Tinutukoy ng developer ang mga pinagkakatiwalaang certificate sa key na NSAppTransportSecurity na may sub-dictionary na NSPinnedDomains. Ang diskarteng ito ay hindi nangangailangan ng pagsulat ng code, ngunit hindi gaanong flexible — hindi maaaring dynamic na baguhin ang mga pins o mag-log ng mga error sa pagsuri.

SSL Pinning sa Android

Sa Android mayroong tatlong pangunahing paraan upang i-implement ang SSL Pinning: sa pamamagitan ng CertificatePinner ng OkHttp library, sa pamamagitan ng Network Security Config sa XML, at sa pamamagitan ng custom na pagsuri sa HttpsURLConnection. OkHttp — ang pinakasikat at inirerekomendang diskarte, na ginagamit sa Retrofit at iba pang HTTP client.

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

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

Sa configuration ng OkHttp, tinutukoy ng developer ang domain at isa o higit pang SHA-256 fingerprint. Sa unang fingerprint, inihahambing ng OkHttp ang server certificate sa mga tinukoy na pins. Kung walang tugma, ang client ay nagtatapon ng SSLPeerUnverifiedException. Ang backup na pin ay sapilitan — kung wala ito, kapag nagbago ang certificate, ang mga API request ay agad na magsisimulang mabigo.

Network Security Configuration sa Android

Sinusuportahan ng Android ang declarative Certificate Pinning sa pamamagitan ng XML configuration simula API 24. Ang file na res/xml/network_security_config.xml ay naglalaman ng listahan ng mga domain at kanilang mga fingerprint. Ang paraang ito ay maginhawa para sa mga static na configuration, ngunit hindi pinapayagan ang implementasyon ng TOFU o custom na logic ng pagsuri na may pag-log ng mga anomalya.

<!-- 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>

Mga kalamangan at kahinaan ng SSL Pinning

Ang SSL Pinning ay makabuluhang nagpapataas ng seguridad ng mobile app, ngunit nagdadala ng operational complexity. Pangunahing kalamangan — proteksyon laban sa MITM attacks kahit na nakompromiso ang root CA. Ang app ay nagtitiwala lamang sa mga certificate na tahasang tinukoy ng developer, hindi sa buong imprastraktura ng mga pampublikong certification center. Ito ay lalong kritikal para sa mga financial app, mga mensahero at app na may sensitibong data.

Pangunahing kahinaan — complexity ng rotasyon ng certificate. Kung ang certificate ay mag-expire o ma-revoke, ang mga user na walang update ng app ay mawawalan ng koneksyon. Nalulutas ito sa pamamagitan ng backup pins at mekanismo ng gradual na pag-update: alam ng bagong app ang luma at bagong certificate, at pagkatapos ng kumpletong pag-update ng mga user, ang lumang pin ay tinatanggal mula sa code. Inirerekomenda na maglagay ng minimum na 2 backup pins — isa para sa kasalukuyang certificate, isa para sa hinaharap.

Isa pang kompromiso — hindi paggamit ng pampublikong proxy para sa debugging ng trapiko (Charles Proxy, Burp Suite) nang hindi inaalis ang pinning. Ito ay nagpapahirap sa debugging ng network request sa yugto ng pag-develop. Solusyon — conditional compilation: sa debug build ang pinning ay naka-off, sa release build ay naka-on. Inirerekomenda ng OWASP ang paggamit ng flag na BuildConfig.DEBUG para sa paglipat.