SSL/TLS: konsep kunci dan protokol dalam pemrograman

Apa itu SSL/TLS?

SSL (Secure Sockets Layer) dan TLS (Transport Layer Security) — protokol kriptografi yang menjamin transmisi data yang aman melalui jaringan. SSL, dikembangkan oleh Netscape pada tahun 1990-an, dinyatakan usang setelah versi 3.0 karena kerentanan POODLE dan BEAST. TLS, penerusnya, telah melalui versi 1.0, 1.1, 1.2, dan 1.3 — saat ini hanya TLS 1.2 dan TLS 1.3 yang dianggap terkini. Semua platform mobile modern mewajibkan penggunaan TLS untuk koneksi jaringan, dan App Store serta Google Play memeriksanya pada tahap review.

Mengapa TLS diperlukan untuk aplikasi mobile

Tanpa TLS, lalu lintas antara aplikasi dan server dikirimkan sebagai teks biasa — siapa pun di jaringan Wi-Fi yang sama dapat mencegat nama pengguna, kata sandi, token, dan data pribadi pengguna menggunakan Wireshark atau tcpdump. TLS mengenkripsi semua data yang dikirimkan (enkripsi di tingkat transport) dan memverifikasi keaslian server melalui rantai sertifikat X.509. Menurut IETF (2018), TLS 1.3 hanya menggunakan cipher AEAD modern (AES-GCM, ChaCha20-Poly1305), mengecualikan algoritma usang seperti RC4 dan 3DES.

HTTPS dan TLS

HTTPS (HTTP Secure) — adalah HTTP melalui TLS. Ketika aplikasi mobile membuat permintaan melalui https://, pertama-tama ia membuat koneksi TLS dengan server, kemudian mengirimkan header HTTP dan body permintaan melalui saluran terenkripsi. Tanpa HTTPS, tidak ada API serius yang boleh berfungsi — ini adalah higiene keamanan dasar. Menurut OWASP (2026), koneksi tidak aman termasuk dalam 3 kerentanan teratas aplikasi mobile.

Bagaimana TLS Handshake bekerja

TLS Handshake — proses pembentukan koneksi aman antara klien dan server. Para pihak menyepakati versi protokol, memilih cipher suite, bertukar kunci melalui kriptografi asimetris, dan memverifikasi sertifikat. Dalam TLS 1.2, handshake memerlukan 2 Round Trip Time (2 RTT): klien → server dengan ClientHello, server → klien dengan ServerHello dan Certificate, kemudian pesan akhir Finished. TLS 1.3 mempersingkat proses ini menjadi 1 RTT.

Tahapan detail handshake TLS 1.2

Tahap pertama: ClientHello — klien mengirimkan versi TLS yang didukung, daftar cipher suite, dan angka acak. Server merespons dengan ServerHello, memilih versi dan cipher suite, mengirimkan sertifikat X.509-nya (Certificate) dan pesan ServerHelloDone. Klien memverifikasi sertifikat melalui rantai otoritas sertifikasi tepercaya (CA), menghasilkan pre-master secret, mengenkripsinya dengan kunci publik dari sertifikat, dan mengirimkannya ke server dalam ClientKeyExchange. Setelah itu, kedua pihak menghasilkan kunci sesi dan bertukar pesan ChangeCipherSpec dan Finished. Sejak saat ini, semua data dienkripsi secara simetris.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Contoh penanganan URLAuthenticationChallenge di iOS melalui URLSessionDelegate. Metode ini dipanggil pada setiap TLS Handshake, memungkinkan aplikasi untuk memverifikasi sertifikat server secara khusus. Untuk produksi, tambahkan verifikasi sertifikat melalui SecTrustEvaluateWithError dan bandingkan dengan sidik jari yang disimpan sebelumnya — hanya setelah itu panggil useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — pembaruan besar pertama protokol dalam 10 tahun. Peningkatan utama: handshake dikurangi menjadi 1 RTT (0 RTT untuk koneksi ulang), cipher suite usang (RSA key exchange, CBC-mode) dihapus, forward secrecy wajib (PFS), dan perlindungan terhadap serangan downgrade melalui signed transcript. Menurut Qualys SSL Labs (2026), TLS 1.3 memberikan perlindungan bahkan saat kunci jangka panjang server dikompromikan berkat PFS.

0-RTT (Zero Round Trip Time) — fitur TLS 1.3 yang memungkinkan klien mengirim data segera bersama ClientHello saat koneksi ulang melalui PSK (Pre-Shared Key). Ini mempercepat pemuatan layar berikutnya dalam aplikasi mobile, terutama saat sering mengirim permintaan ke server yang sama. Namun, data 0-RTT tidak dilindungi dari serangan replay — dapat dicegat dan dikirim ulang. Gunakan 0-RTT hanya untuk permintaan idempoten (GET, PUT) tanpa efek samping.

TLS di iOS: App Transport Security

App Transport Security (ATS) — mekanisme Apple yang mewajibkan koneksi HTTPS dengan TLS 1.2 atau lebih tinggi, diaktifkan secara default sejak iOS 9. ATS memblokir semua koneksi HTTP dan HTTPS dengan TLS di bawah 1.2. Pengembang dapat mengonfigurasi pengecualian di Info.plist melalui NSAppTransportSecurity untuk domain tertentu, tetapi Apple merekomendasikan untuk meminimalkan pengecualian dan menggunakan HTTPS di mana saja. Pelanggaran persyaratan ATS adalah alasan penolakan aplikasi saat review App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Konfigurasi ATS di Info.plist. NSAllowsArbitraryLoads diatur ke false — semua koneksi harus menggunakan HTTPS. Untuk domain cdn.example.com, versi minimum TLS 1.2 ditetapkan, NSAllowsLocalNetworking=true mengizinkan HTTP untuk jaringan lokal (berguna untuk server pengembangan). Apple sangat merekomendasikan untuk tidak mengaktifkan NSAllowsArbitraryLoads tanpa NSExceptionDomains — ini harus berupa pengecualian, bukan aturan umum.

TLS di Android: Network Security Config

Network Security Config — mekanisme Android untuk mengonfigurasi HTTPS dan TLS tanpa mengubah kode Java/Kotlin. Konfigurasi didefinisikan dalam file XML network_security_config.xml dan dihubungkan di AndroidManifest melalui atribut android:networkSecurityConfig. Mendukung konfigurasi sertifikat tepercaya (user dan system CA), Certificate Pinning, menonaktifkan HTTP teks biasa, override debug, dan pengalihan lalu lintas.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config untuk Android. Base-config melarang lalu lintas teks biasa dan hanya mempercayai sertifikat CA sistem (tanpa sertifikat pengguna — perlindungan terhadap instalasi sertifikat MitM oleh pengguna). Domain-config untuk api.example.com berisi pin-set dengan sidik jari SHA-256 sertifikat. Jika sertifikat server berubah sebelum tanggal kedaluwarsa yang ditentukan, koneksi akan ditolak — ini adalah bentuk ketat dari Certificate Pinning.

Certificate Pinning dan keamanan

Certificate Pinning — teknik menetapkan sertifikat atau kunci publik server dalam kode aplikasi. Pada setiap TLS Handshake, klien membandingkan sertifikat server dengan sidik jari yang disimpan sebelumnya (hash SHA-256). Bahkan jika penyerang memperoleh sertifikat CA tepercaya atau mengompromikan otoritas sertifikasi, ia tidak dapat melakukan serangan MitM — aplikasi memeriksa sidik jari spesifik, bukan rantai CA. Ini sangat penting untuk aplikasi keuangan dan aplikasi dengan data sensitif.

Risiko dan alternatif Pinning

Certificate Pinning memerlukan kehati-hatian: saat sertifikat berubah di server, semua versi lama aplikasi tidak akan dapat terhubung. Disarankan untuk menyimpan beberapa sidik jari cadangan (utama + cadangan), menentukan tanggal kedaluwarsa pin-set, dan mengimplementasikan mekanisme fallback melalui verifikasi CA standar. Alternatifnya — Trust On First Use (TOFU), ketika aplikasi mengingat sertifikat pada koneksi pertama dan memperingatkan pengguna saat terjadi perubahan. Menurut OWASP (2026), tidak adanya Certificate Pinning termasuk dalam 3 kerentanan teratas aplikasi mobile (M3: Insecure Communication).

Implementasi Pinning di Alamofire

Di Alamofire 5+, Certificate Pinning dikonfigurasikan melalui ServerTrustManager dengan PinnedCertificatesTrustEvaluator (memeriksa seluruh sertifikat) atau PublicKeysTrustEvaluator (hanya kunci publik). Kunci publik lebih disukai — tidak berubah saat pembaruan sertifikat di CA yang sama. Buat ServerTrustManager dengan kamus [host: evaluator], berikan ke Session, dan gunakan untuk semua permintaan ke API yang dilindungi.