SSL Pinning: esensi, mekanisme dan perlindungan dari serangan MITM

Apa itu SSL Pinning?

SSL Pinning — adalah mekanisme keamanan di mana aplikasi mobile atau web mengingat sertifikat tepercaya atau kunci publik server dan menolak koneksi apa pun yang sertifikatnya tidak cocok dengan yang tersimpan. Dalam skema HTTPS standar, klien memverifikasi sertifikat melalui rantai kepercayaan hingga CA akar — CA mana pun dapat menandatangani sertifikat untuk domain apa pun. SSL Pinning menghilangkan kelemahan ini: alih-alih mempercayai ratusan CA, aplikasi hanya mempercayai satu sertifikat tertentu.

Masalah verifikasi standar adalah bahwa salah satu dari ratusan CA akar dapat menerbitkan sertifikat yang valid untuk domain Anda — secara tidak sengaja atau di bawah paksaan. Penyerang yang mendapatkan akses ke proxy perusahaan dengan sertifikat akarnya sendiri dapat melakukan serangan MITM tanpa peringatan browser. SSL Pinning menutup kerentanan ini: bahkan jika CA menerbitkan sertifikat palsu, aplikasi akan menolaknya, karena sidik jari tidak cocok dengan yang tercatat.

Dalam aplikasi mobile, SSL Pinning sangat penting karena perangkat sering beroperasi di jaringan yang tidak aman — Wi-Fi publik, proxy perusahaan dengan inspeksi lalu lintas, titik akses yang terinfeksi. Menurut Verizon Mobile Security Index (2025), lebih dari 60% kebocoran data di aplikasi mobile terkait dengan penyadapan lalu lintas di tingkat transportasi.

Mengapa SSL Pinning diperlukan dalam pengembangan mobile

Aplikasi mobile mentransmisikan data sensitif — token autentikasi, informasi pembayaran, data pribadi pengguna. Tanpa perlindungan tambahan, HTTPS dapat dikompromikan melalui penggantian sertifikat akar di perangkat — misalnya, setelah menginstal profil perusahaan atau aplikasi berbahaya. SSL Pinning menjamin bahwa bahkan jika CA akar palsu diinstal di perangkat, aplikasi akan terus memverifikasi sertifikat berdasarkan daftar putihnya sendiri.

Bagaimana cara kerja SSL Pinning?

Proses SSL Pinning terdiri dari tiga tahap: mendapatkan sidik jari, verifikasi saat koneksi, dan penanganan kesalahan. Pada tahap pengembangan, insinyur mendapatkan sidik jari SHA-256 sertifikat server (openssl x509 -fingerprint -sha256) dan menyematkannya ke dalam kode aplikasi atau file konfigurasi. Pada setiap permintaan HTTPS, aplikasi menghitung sidik jari sertifikat yang diterima dan membandingkannya dengan yang tersimpan — jika nilainya tidak cocok, koneksi diputus.

Tahap pertama — pinning pada tahap pembangunan: pengembang sudah mengetahui sertifikat server sebelumnya dan menyematkan hash mereka. Tahap kedua — pinning pada koneksi pertama (trust on first use, TOFU): aplikasi mengingat sertifikat pada permintaan pertama dan menggunakannya untuk memverifikasi semua permintaan berikutnya. TOFU nyaman untuk lingkungan dinamis, tetapi rentan pada serangan pertama — jika koneksi pertama sudah disadap, sertifikat palsu akan diterima sebagai tepercaya.

Detail kritis — sidik jari cadangan (backup pins). Sertifikat memiliki masa berlaku, dan saat diganti, aplikasi yang tidak diperbarui akan kehilangan koneksi ke server. Insinyur menambahkan 2–3 sidik jari tambahan — misalnya, sidik jari sertifikat cadangan dan sidik jari CA akar. Jika sertifikat utama berubah, aplikasi memeriksa berdasarkan backup pins, dan koneksi terus berfungsi.

# Mendapatkan sidik jari SHA-256 sertifikat
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

Jenis SSL Pinning

Ada dua pendekatan utama untuk implementasi pinning: pengikatan ke seluruh sertifikat (certificate pinning) dan pengikatan ke kunci publik (public key pinning). Setiap pendekatan memiliki kekuatan dan keterbatasan yang mempengaruhi keamanan dan kemudahan pemeliharaan.

Certificate Pinning

Pengikatan ke sertifikat — metode yang paling ketat. Aplikasi menyimpan salinan sertifikat tepercaya atau sidik jari SHA-256-nya dan membandingkannya dengan sertifikat server pada setiap koneksi HTTPS. Metode ini memberikan keamanan maksimum, tetapi menimbulkan masalah saat rotasi — sertifikat biasanya berlaku 1–2 tahun, setelah itu diperlukan pembaruan paksa aplikasi. Direkomendasikan untuk sistem kritis dengan siklus pembaruan terkendali.

Public Key Pinning

Fiksasi kunci publik — pendekatan yang lebih fleksibel. Alih-alih seluruh sertifikat, aplikasi hanya mengingat kunci publik RSA atau ECDSA server. Kunci dapat tetap tidak berubah saat penerbitan ulang sertifikat, jika perusahaan menggunakan pasangan kunci yang sama. Ini mengurangi frekuensi pembaruan aplikasi. Namun, jika kunci dikompromikan, diperlukan penggantian berantai di semua klien.

SSL Pinning di iOS

Di platform Apple, SSL Pinning diimplementasikan melalui delegat URLSession. Pengembang membuat kelas yang mengimplementasikan protokol URLSessionDelegate dan menimpa metode didReceive challenge, di mana ia secara manual memeriksa sertifikat server terhadap sidik jari yang tersimpan. Pendekatan alternatif — menggunakan Alamofire dengan ServerTrustManager, yang menyederhanakan konfigurasi.

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

Dalam contoh, delegat menerima permintaan autentikasi dari URLSession, mengekstrak serverTrust dari challenge dan membandingkan sidik jari SHA-256 sertifikat dengan yang tersimpan. Jika sidik jari cocok — koneksi dilanjutkan, jika tidak challenge ditolak. Untuk produksi, perlu menambahkan pemeriksaan beberapa backup pins dan pencatatan kesalahan untuk pemantauan.

Network Security Config di iOS

Mulai iOS 14, Apple menambahkan dukungan bawaan untuk Certificate Pinning melalui Info.plist. Pengembang menentukan sertifikat tepercaya di kunci NSAppTransportSecurity dengan subkamus NSPinnedDomains. Pendekatan ini tidak memerlukan penulisan kode, tetapi kurang fleksibel — tidak dapat mengubah pin secara dinamis atau mencatat kesalahan verifikasi.

SSL Pinning di Android

Di Android ada tiga cara utama untuk mengimplementasikan SSL Pinning: melalui CertificatePinner dari pustaka OkHttp, melalui Network Security Config di XML, dan melalui pemeriksaan kustom di HttpsURLConnection. OkHttp — pendekatan paling populer dan direkomendasikan, digunakan di Retrofit dan klien HTTP lainnya.

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

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

Dalam konfigurasi OkHttp, pengembang menentukan domain dan satu atau beberapa sidik jari SHA-256. Pada sidik jari pertama, OkHttp membandingkan sertifikat server dengan pin yang ditentukan. Jika tidak ada kecocokan, klien melemparkan SSLPeerUnverifiedException. Pin cadangan wajib — tanpa itu, saat sertifikat berubah, permintaan API akan segera mulai gagal.

Network Security Configuration di Android

Android mendukung Certificate Pinning deklaratif melalui konfigurasi XML mulai API 24. File res/xml/network_security_config.xml berisi daftar domain dan sidik jarinya. Metode ini nyaman untuk konfigurasi statis, tetapi tidak memungkinkan implementasi TOFU atau logika pemeriksaan kustom dengan pencatatan anomali.

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

Kelebihan dan kekurangan SSL Pinning

SSL Pinning secara signifikan meningkatkan keamanan aplikasi mobile, tetapi menimbulkan kompleksitas operasional. Kelebihan utama — perlindungan terhadap serangan MITM bahkan jika CA akar dikompromikan. Aplikasi hanya mempercayai sertifikat yang secara eksplisit ditentukan oleh pengembang, bukan seluruh infrastruktur pusat sertifikasi publik. Ini sangat penting untuk aplikasi keuangan, aplikasi perpesanan, dan aplikasi dengan data sensitif.

Kekurangan utama — kompleksitas rotasi sertifikat. Jika sertifikat kedaluwarsa atau dicabut, pengguna tanpa pembaruan aplikasi kehilangan koneksi. Ini diatasi melalui pin cadangan dan mekanisme pembaruan bertahap: aplikasi baru mengetahui sertifikat lama dan baru, dan setelah pembaruan penuh pengguna, pin lama dihapus dari kode. Disarankan untuk menyertakan minimal 2 pin cadangan — satu untuk sertifikat saat ini, satu untuk masa depan.

Kompromi lainnya — ketidakmampuan menggunakan proxy publik untuk debugging lalu lintas (Charles Proxy, Burp Suite) tanpa menonaktifkan pinning. Ini mempersulit debugging permintaan jaringan pada tahap pengembangan. Solusi — kompilasi bersyarat: di build debug pinning dinonaktifkan, di build release diaktifkan. OWASP merekomendasikan penggunaan flag BuildConfig.DEBUG untuk peralihan.