Penyematan Sertifikat dalam Aplikasi Seluler dan Desktop

TLS standar mempercayai sertifikat apa pun yang ditandatangani oleh salah satu dari sekitar 150 CA akar yang telah dipasang sebelumnya di OS. Jika salah satu CA akar dibobol atau dipaksa, penyerang dapat memperoleh sertifikat untuk domain apa pun dan mencegat lalu lintas TLS. Penyematan sertifikat membatasi kepercayaan pada sertifikat atau kunci publik tertentu, terlepas dari CA yang menandatanganinya. Aplikasi dengan penyematan menolak koneksi ke servernya kecuali server menyajikan sertifikat atau kunci yang benar-benar diharapkan. Perlindungan ini sangat berharga untuk aplikasi seluler karena pengguna tidak dapat memeriksa lalu lintas jaringan dan solusi MDM perusahaan mungkin memasang akar CA perusahaan.

Ada tiga tingkat perincian penyematan: (1) Sematan sertifikat penuh—sertifikat yang disandikan DER harus benar-benar cocok. Ini yang paling rapuh: penyematan akan rusak setiap kali sertifikat diperbarui. (2) Sematan kunci publik—hanya byte SubjectPublicKeyInfo (SPKI) yang dibandingkan. Penyematan tetap berfungsi setelah sertifikat diperbarui jika pasangan kunci yang sama dipertahankan. (3) Hash SPKI—simpan SHA-256(SPKI), bukan kunci mentahnya. Inilah pendekatan HTTP Public Key Pinning (HPKP) dan Android Network Security Config. Penyematan kunci publik/SPKI lebih disarankan: tetap berfungsi setelah rotasi CA dan pembaruan sertifikat, sekaligus tetap mendeteksi MITM dengan pasangan kunci yang berbeda.

Android (API 24+) menyediakan mekanisme penyematan deklaratif melalui XML Network Security Config. Berkas res/xml/network_security_config.xml menentukan sematan per domain: pin-set dengan digest="SHA-256" dan hash SPKI yang disandikan dalam base64. Aplikasi merujuk berkas ini di AndroidManifest.xml melalui android:networkSecurityConfig. Android menerapkan sematan pada semua koneksi HTTP yang dibuat melalui HttpsURLConnection standar dan OkHttp (saat menggunakan pengelola kepercayaan platform). pin-set memerlukan setidaknya satu sematan cadangan (kunci atau sematan CA yang berbeda) untuk mencegah penguncian akses jika kunci utama dibobol. Kedaluwarsa sematan (atribut expiration) memaksa aplikasi diperbarui sebelum sematan menjadi usang.

Aplikasi iOS menerapkan penyematan dalam delegasi NSURLSession. Metode delegasi URLSession(_:didReceive:completionHandler:) menerima objek kepercayaan server. Aplikasi memanggil SecTrustEvaluateWithError untuk memvalidasi rantai, lalu mengekstrak sertifikat daun dengan SecTrustGetCertificateAtIndex(trust, 0), mengekspor byte SPKI-nya, menghitung hash menggunakan SHA-256, dan membandingkannya dengan sematan yang tersimpan. TrustKit (pustaka sumber terbuka) membungkus pola ini dengan penyematan berbasis konfigurasi, yang mendukung beberapa sematan, pencocokan subdomain, dan mode hanya-laporan. App Transport Security (ATS) milik Apple terpisah dari penyematan—ATS menerapkan batas minimum versi TLS, tetapi tidak menyematkan kunci.

HTTP Public Key Pinning (HPKP, RFC 7469) berupaya menambahkan penyematan untuk peramban web melalui tajuk respons HTTP: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Peramban akan mengingat sematan selama durasi max-age dan menolak koneksi ke kunci yang tidak cocok. HPKP tidak lagi digunakan oleh Chrome sejak 2017 dan dihapus pada 2019 karena kegagalan yang sangat parah: satu kesalahan konfigurasi atau kehilangan kunci dapat mengunci pengguna secara permanen dari situs web tanpa jalur pemulihan. HPKP kini praktis tidak digunakan lagi pada peramban web; penyematan tingkat aplikasi dalam aplikasi seluler tetap layak karena pembaruan aplikasi dapat mengirimkan sematan baru.

OkHttp (yang banyak digunakan di Android) mendukung penyematan melalui CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Sematan kedua adalah sematan cadangan. OkHttp memverifikasi bahwa setidaknya satu sematan cocok dengan sertifikat mana pun dalam rantai server—sertifikat daun, perantara, atau akar. Hal ini memungkinkan penyematan pada CA perantara (tetap berfungsi saat sertifikat daun dirotasi) atau pada CA akar (tetap berfungsi saat sertifikat perantara dirotasi). OkHttp menampilkan SSLPeerUnverifiedException dengan pesan informatif yang mencantumkan hash SPKI aktual milik server, sehingga pengambilan sematan selama pengembangan menjadi mudah.

Penyematan meningkatkan tingkat kesulitan intersepsi lalu lintas, tetapi tidak sepenuhnya tidak dapat ditembus. Teknik umum untuk melewatinya pada perangkat seluler: (1) Hook Frida—menyisipkan JavaScript ke proses aplikasi untuk mengaitkan metode verifikasi sematan dan selalu mengembalikan true. (2) Alat SSLUnpinning—skrip Frida/Objection otomatis yang menargetkan pustaka penyematan umum (TrustKit, OkHttp, SecTrust asli). (3) ROM khusus—mendapatkan akses root pada perangkat dan memodifikasi tumpukan TLS. (4) Pengemasan ulang—mendekompilasi APK, memodifikasi konfigurasi penyematan, lalu mengemas ulang dengan sertifikat baru. (5) Patching memori—menambal bytecode verifikasi saat waktu jalan. Mitigasi: deteksi root/jailbreak, pengaburan kode, dan pemeriksaan integritas (SafetyNet/App Attest).

Risiko operasional terbesar dari penyematan sertifikat adalah penguncian akses oleh sistem sendiri: jika kunci produksi hilang atau sertifikat kedaluwarsa dan cadangannya tidak tersedia, pengguna terkunci hingga pembaruan aplikasi dirilis (berhari-hari hingga berminggu-minggu). Praktik terbaik: (1) Selalu sematkan setidaknya dua kunci—kunci saat ini dan kunci cadangan yang telah dibuat sebelumnya serta disimpan luring (di HSM atau lingkungan yang terisolasi dari jaringan). (2) Tetapkan tanggal kedaluwarsa sematan dan rilis pembaruan aplikasi sebelum tanggal tersebut. (3) Pantau kegagalan sematan melalui mode hanya-laporan sebelum menerapkannya secara wajib. (4) Pertahankan alur pembaruan aplikasi darurat (peninjauan dipercepat) untuk insiden rotasi sematan. (5) Sematkan pada tingkat CA perantara, bukan sertifikat daun, agar rotasi sertifikat daun dapat dilakukan tanpa pembaruan aplikasi.

Aplikasi desktop yang ditulis dengan Electron, Qt, atau kode asli dapat menerapkan penyematan menggunakan API tumpukan TLS-nya. Aplikasi Electron menggunakan peristiwa app.on("certificate-error") dan session.setCertificateVerifyProc() untuk menerapkan verifikasi khusus. Kode jaringan Qt menggunakan QSslSocket dengan panggilan balik verifikasi khusus. Aplikasi .NET menggunakan ServicePointManager.ServerCertificateValidationCallback. Aplikasi Windows asli menggunakan WinHTTP dengan pemeriksaan sertifikat manual. Aplikasi desktop menghadapi tantangan tambahan: intersepsi TLS tingkat OS melalui proksi perusahaan merupakan hal yang umum, dan pengguna mungkin mengharapkan fungsi proksi tetap berjalan—sehingga diperlukan keputusan kebijakan mengenai apakah penyematan hanya berlaku untuk titik akhir tertentu.

Penyematan sertifikat memperumit pengujian otomatis dan alur CI/CD. Pengujian integrasi yang melakukan panggilan HTTPS nyata ke server praproduksi harus menggunakan sertifikat pengujian yang hash SPKI-nya disematkan dalam konfigurasi pengujian. Pendekatan yang tersedia: (1) Varian kompilasi—varian debug/staging menyertakan sematan server praproduksi; varian rilis menyematkan server produksi. (2) Penggantian Network Security Config—Android mengizinkan konfigurasi sematan khusus debug. (3) Server tiruan—mencegat pada lapisan klien HTTP sebelum TLS, sehingga sepenuhnya melewati penyematan. (4) CA yang ditandatangani sendiri untuk CI—menerbitkan sertifikat pengujian dari CA CI yang akarnya hanya dipercaya dalam varian pengujian. Jangan pernah merilis kompilasi dengan penyematan yang dinonaktifkan di produksi.

Sematan sertifikat biasanya berupa hash kunci publik RSA atau EC. Saat migrasi pascakuantum dimulai, server akan beralih ke ML-DSA (CRYSTALS-Dilithium) atau kunci hibrida. Hash SPKI yang disematkan akan berubah karena jenis dan pengodean kunci berubah. Aplikasi yang menyematkan sertifikat daun atau kunci publik memerlukan pembaruan terkoordinasi: (1) Rilis versi aplikasi baru dengan hash SPKI pascakuantum sebagai sematan cadangan sebelum migrasi server. (2) Selesaikan migrasi server. (3) Rilis pembaruan untuk menghapus sematan klasik lama. Periode transisi memerlukan koordinasi yang cermat. Aplikasi yang menyematkan CA perantara atau akar akan lebih sedikit terdampak—hanya kunci CA yang berubah, dan belum tentu pada jadwal yang sama dengan sertifikat daun.

Mengapa penyematan nilai hash SubjectPublicKeyInfo (SPKI) lebih disarankan daripada penyematan sertifikat lengkap?

Penyematan sertifikat membatasi kepercayaan TLS pada sertifikat atau kunci publik tertentu, sehingga melindungi dari kompromi CA dan MITM. Penyematan nilai hash SPKI (SHA-256 dari SubjectPublicKeyInfo) lebih disarankan daripada penyematan sertifikat lengkap karena lebih tahan terhadap pembaruan. Android menggunakan XML Konfigurasi Keamanan Jaringan; iOS menggunakan delegasi URLSession dengan API SecTrust; OkHttp mendukung CertificatePinner. Selalu sertakan penyematan cadangan agar aplikasi tidak mengunci aksesnya sendiri. HPKP (tajuk HTTP peramban) tidak lagi digunakan. Penyematan dapat dilewati melalui kait Frida dan modifikasi ROM. Migrasi kunci pascakuantum memerlukan pembaruan aplikasi yang terkoordinasi untuk memperbarui nilai hash SPKI.