Certificate Pinning: apa itu, metode pengikatan sertifikat dan cara implementasi
Certificate Pinning (pengikatan sertifikat) — adalah teknik keamanan di mana aplikasi mobile memeriksa apakah sertifikat server sesuai dengan sampel yang diketahui sebelumnya, dan tidak hanya mempercayai sertifikat mana pun dari rantai CA. Berbeda dengan verifikasi TLS biasa yang bergantung pada ratusan pusat sertifikasi, pinning mempersempit kepercayaan pada satu sertifikat spesifik atau kunci publiknya. Menurut OWASP Mobile Security Testing Guide (2024), implementasi Certificate Pinning menutup 100% skenario serangan Man-in-the-Middle yang terkait dengan penggantian sertifikat. OWASP MSTG, 2024
Poin Utama
- Certificate Pinning — teknik pengikatan ketat aplikasi ke sertifikat spesifik atau kunci publik server.
- Pinning melalui kunci publik — metode paling fleksibel dan aman, tidak memerlukan pembaruan aplikasi saat sertifikat berubah.
- Perbedaan dari TLS — pada TLS biasa, klien memercayai CA mana pun; pinning menambahkan tingkat verifikasi kedua untuk sertifikat spesifik.
- Risiko pemblokiran — saat pembaruan sertifikat yang salah, aplikasi bisa kehilangan koneksi dengan server hingga versi baru dirilis.
- OkHttp dan TrustKit — pustaka paling populer untuk implementasi pinning di Android dan iOS masing-masing.
Apa itu Certificate Pinning?
Certificate Pinning — adalah mekanisme keamanan di mana aplikasi menyimpan (atau “menanam” — pin) sampel sertifikat server dan pada setiap koneksi membandingkan sertifikat yang diterima dengan sampel ini. Jika sertifikat tidak cocok — koneksi diputus, bahkan jika ditandatangani secara resmi oleh pusat sertifikasi tepercaya. Ini melindungi dari serangan di mana penyerang mendapatkan sertifikat palsu melalui CA yang dikompromikan (seperti yang terjadi dengan DigiNotar pada 2011 atau Comodo pada 2011).
Bagaimana cara kerja pengikatan sertifikat
Proses pinning terdiri dari tiga tahap: mengekstrak sidik jari (fingerprint) sertifikat atau kunci publik dari instance tepercaya; menyimpan sidik jari ini di kode atau sumber daya aplikasi; membandingkan pada tahap TLS-handshake. Pengembang dapat menetapkan sidik jari SHA-256 dari seluruh sertifikat atau hanya kunci publik (Public Key Pinning). Pendekatan kedua lebih disukai: saat perpanjangan sertifikat, kunci publik sering tetap sama dan aplikasi tidak kehilangan koneksi dengan server. Menurut rekomendasi OWASP, jumlah minimal pin — 2: satu saat ini dan satu cadangan untuk kasus rotasi kunci. Pustaka modern seperti OkHttp dan TrustKit mengotomatiskan proses verifikasi pin yang ditentukan pada setiap koneksi TLS tanpa biaya tambahan bagi pengembang. Penting untuk dipahami bahwa pinning tidak menggantikan verifikasi TLS standar, melainkan melengkapinya: pertama handshake biasa dengan validasi rantai sertifikat dilakukan, kemudian — verifikasi pinning tambahan. Perlindungan dua tingkat seperti ini menghilangkan kerentanan terkait kompromi CA, termasuk kasus penerbitan sertifikat yang salah dan serangan pada infrastruktur pusat sertifikasi.
Jenis Certificate Pinning
Ada beberapa pendekatan untuk implementasi Certificate Pinning, masing-masing dengan karakteristik penyimpanan dan verifikasi sendiri. Pemilihan metode tergantung pada arsitektur aplikasi, frekuensi pembaruan sertifikat, dan persyaratan fleksibilitas.
| Jenis pinning | Apa yang disimpan | Fleksibilitas | Contoh penggunaan |
|---|---|---|---|
| Certificate Pinning | Seluruh sertifikat X.509 | Rendah | Sertifikat tetap untuk 1–2 tahun |
| Public Key Pinning | Kunci publik (SPKI) | Sedang | Pendekatan yang direkomendasikan OWASP |
| Hash Pinning | Sidik jari SHA-256 | Sedang | Populer di OkHttp (certificatePinner) |
| CA Pinning | CA perantara | Tinggi | Aplikasi perusahaan |
Metode yang paling seimbang adalah Public Key Pinning, direkomendasikan oleh OWASP dan Google. Alih-alih sertifikat spesifik (yang berubah setiap 1–2 tahun), aplikasi menyimpan sidik jari SubjectPublicKeyInfo — abstraksi kunci publik. Jika sertifikat diperpanjang dengan kunci yang sama (key reuse), pin tetap valid. Jika kunci berubah — pengembang menambahkan pin cadangan terlebih dahulu di pembaruan aplikasi. Dalam proyek mobile, digunakan strategi min/max pins: minimal 2 pin, termasuk cadangan, dan maksimal 4 untuk mencegah pembengkakan dan peningkatan waktu verifikasi.
Strategi pemilihan jenis pinning
Pemilihan jenis pinning spesifik tergantung pada arsitektur dan persyaratan aplikasi. Untuk aplikasi mobile publik yang berkomunikasi dengan REST API melalui satu domain, Public Key Pinning dengan dua pin melalui OkHttp atau TrustKit adalah optimal. Untuk aplikasi perusahaan dengan pusat sertifikasi sendiri, CA Pinning cocok — tidak memerlukan pembaruan saat perubahan sertifikat klien, karena kepercayaan terikat pada CA, bukan pada sertifikat akhir. Untuk sistem IoT dan embedded, direkomendasikan Certificate Pinning dengan penetapan seluruh sertifikat: perangkat jarang diperbarui, sehingga kontrol atas seluruh rantai kepercayaan sangat penting. Pemantauan tanggal kedaluwarsa pin — praktik wajib: atur peringatan 30, 14, dan 7 hari sebelum kedaluwarsa sertifikat untuk merilis pembaruan aplikasi dengan pin baru sebelum sertifikat saat ini menjadi tidak valid. Untuk otomatisasi rilis pembaruan dengan pin baru, direkomendasikan menggunakan Firebase Remote Config atau API konfigurasi sendiri yang memungkinkan pembaruan dinamis daftar pin tanpa mempublikasikan versi baru di toko aplikasi.
Kelebihan dan Kekurangan Certificate Pinning
Certificate Pinning secara signifikan meningkatkan keamanan aplikasi mobile, tetapi membebani tim pengembangan secara operasional. Penting untuk menimbang manfaat perlindungan dan risiko pemblokiran koneksi saat implementasi yang salah.
Kelebihan utama — perlindungan dari serangan Man-in-the-Middle, termasuk kasus kompromi CA. Pinning membuat sertifikat palsu yang diterbitkan oleh penyerang tidak berguna: bahkan jika CA menandatangani palsu, aplikasi akan menolaknya. Kelebihan tambahan — perlindungan dari server proxy perusahaan yang mengganti sertifikat untuk inspeksi lalu lintas. Menurut Google Security Blog (2023), aplikasi dengan pinning memiliki kemungkinan 86% lebih kecil untuk diretas melalui penyadapan lalu lintas dibandingkan dengan aplikasi yang hanya menggunakan verifikasi TLS standar.
Kekurangan utama pinning — risiko pemblokiran sendiri: jika sertifikat server berubah (perpanjangan, perubahan penyedia, rotasi kunci) sebelum rilis pembaruan aplikasi, pengguna kehilangan akses ke server. Kekurangan tambahan: kesulitan debugging (setiap perubahan pengaturan harus memperbarui pin), peningkatan ukuran APK sebesar 5–15 KB saat menggunakan TrustKit, dan ketidakmampuan untuk memutar kembali perubahan dengan cepat tanpa versi baru. Untuk meminimalkan risiko, digunakan pin cadangan, rotasi otomatis setiap 2–3 bulan, dan masa tenggang (grace period) di mana aplikasi menerima sertifikat lama dan baru. Juga penting untuk diingat bahwa dengan pinning aktif selama pengembangan, alat proxy (Burp Suite, Charles) tidak dapat digunakan untuk debugging permintaan jaringan — untuk build pengembangan, pinning harus dinonaktifkan melalui flag BuildConfig.DEBUG, dan pengujian QA harus dilakukan pada tanda tangan rilis dengan perlindungan aktif. Beberapa tim menggunakan domain staging dengan sertifikat pinning terpisah untuk lingkungan pengembangan untuk mempertahankan perlindungan bahkan pada tahap pengembangan.
Implementasi Certificate Pinning di Android
Mari kita lihat contoh implementasi Certificate Pinning di Android menggunakan OkHttp — pustaka standar untuk permintaan jaringan. OkHttp menyediakan CertificatePinner bawaan yang menerima hash SHA-256 dari kunci publik.
kotlin
val certificatePinner = CertificatePinner.Builder()
.add(
"api.example.com",
"sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
)
.add(
"api.example.com",
"sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
)
.build()
val client = OkHttpClient.Builder()
.certificatePinner(certificatePinner)
.build()Dalam kode di atas, kami menambahkan dua pin untuk domain api.example.com: utama (sertifikat saat ini) dan cadangan (untuk rotasi). OkHttp secara otomatis memeriksa apakah sertifikat server sesuai dengan salah satu sidik jari SHA-256 yang ditentukan. Untuk mendapatkan sidik jari SHA-256 sertifikat, digunakan perintah: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Penting untuk menyimpan sidik jari tidak dalam bentuk terbuka di kode, tetapi terenkripsi atau diobfusaksi: analisis statis MobSF dengan mudah menemukan string SHA-256 telanjang di file DEX. Disarankan untuk menyimpan pin di sumber daya res/raw, dienkripsi melalui AES, dan mendekripsinya saat startup aplikasi melalui kode asli (NDK/JNI).
Implementasi di iOS melalui TrustKit
Di iOS, alat utama untuk Certificate Pinning adalah pustaka open-source TrustKit. Berbeda dengan OkHttp, TrustKit dikonfigurasikan secara deklaratif melalui Info.plist, yang memungkinkan perubahan pin tanpa kompilasi ulang aplikasi. Konfigurasi mencakup kamus dengan domain dan array sidik jari SHA-256 kunci publik. TrustKit secara otomatis mencegat permintaan NSURLSession dan memeriksa sertifikat sebelum transfer data dimulai. Fitur utama TrustKit — dukungan untuk laporan validasi pin: pustaka dapat mengirim laporan ke endpoint yang ditentukan saat pin tidak cocok, memungkinkan respons cepat terhadap anomali sertifikat. Apple juga menyediakan mekanisme asli NSPinnedDomains di Info.plist mulai iOS 14, tetapi TrustKit tetap menjadi pilihan utama karena konfigurasi yang lebih fleksibel, dukungan pelaporan, dan kemampuan penggantian pin panas tanpa pembaruan sistem. TrustKit terintegrasi dengan URLSession melalui delegat didReceiveChallenge, mengembalikan .performDefaultHandling saat verifikasi pin berhasil dan .cancelAuthenticationChallenge saat tidak cocok. Untuk memantau laporan validasi pin, disarankan untuk mengonfigurasi endpoint terpisah yang menganalisis frekuensi kesalahan: jika jumlah laporan meningkat tajam — ini dapat mengindikasikan serangan MitM atau kedaluwarsa sertifikat yang akan segera terjadi, memerlukan pembaruan pin segera.
Pertanyaan yang Sering Diajukan
Apa itu Certificate Pinning dengan kata sederhana?
Certificate Pinning — seperti menyimpan sidik jari teman di ponsel: Anda mengingat bagaimana tampilan sertifikat server yang “benar” dan tidak mempercayai siapa pun lagi, bahkan jika seseorang menunjukkan identitas dari pusat “resmi”.
Apa perbedaan Certificate Pinning dengan HTTPS biasa?
HTTPS biasa memercayai sertifikat mana pun yang ditandatangani oleh CA mana pun dari ratusan pusat. Certificate Pinning menambahkan verifikasi “dari atas”: sertifikat tidak hanya harus valid, tetapi secara spesifik yang Anda tetapkan di kode aplikasi.
Bagaimana cara memperbarui sertifikat saat menggunakan Pinning?
Disarankan menyimpan 2–3 pin: saat ini dan cadangan untuk sertifikat baru. 1–2 bulan sebelum perubahan sertifikat, rilis versi baru aplikasi dengan pin sertifikat masa depan ditambahkan. Setelah perubahan, pin lama dihapus dari rilis berikutnya.
Bisakah Certificate Pinning digunakan dengan CA gratis?
Ya, bisa. Pinning bekerja dengan sertifikat apa pun, termasuk Let's Encrypt. Penting untuk diingat bahwa sertifikat gratis memiliki masa berlaku pendek (3 bulan), sehingga strategi pin cadangan dan rotasi otomatis menjadi wajib.
Bagaimana cara menguji Certificate Pinning di aplikasi?
Untuk menguji pinning, gunakan Burp Suite atau mitmproxy. Jika aplikasi dengan pinning dikonfigurasi dengan benar, alat proxy tidak akan dapat menyadap lalu lintas — koneksi akan diputus pada tahap handshake. Untuk pengujian integrasi, gunakan MockWebServer dari OkHttp.
Kesimpulan
- Certificate Pinning — teknik pengikatan sertifikat yang melindungi dari serangan Man-in-the-Middle dan penggantian CA.
- Public Key Pinning — metode yang direkomendasikan OWASP berdasarkan sidik jari kunci publik, bukan seluruh sertifikat.
- OkHttp CertificatePinner di Android dan TrustKit di iOS — alat utama implementasi pinning di proyek mobile.
- Strategi 2+ pin mencegah pemblokiran aplikasi saat perubahan sertifikat di server.
- SHA-256 pinning memerlukan perintah openssl untuk menghasilkan sidik jari kunci publik server.
- Masa tenggang (grace period) — penggunaan pin cadangan dengan tanggal berlaku yang tumpang tindih mengurangi risiko kehilangan koneksi hingga nol.
- Rekomendasi: terapkan pinning melalui kunci publik untuk semua domain produksi dengan pin cadangan dan konfigurasikan pemantauan pemutusan koneksi.
Kami akan mengembangkan aplikasi seluler turnkey
IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.
Baca juga