SSL/TLS — apa itu, protokol dan prinsip kerja enkripsi

Apa itu SSL/TLS?

SSL (Secure Sockets Layer) — adalah protokol yang dikembangkan oleh perusahaan Netscape pada tahun 1995 untuk melindungi lalu lintas web. Versi pertama SSL 1.0 tidak pernah dipublikasikan, SSL 2.0 (1995) dan SSL 3.0 (1996) digunakan hingga awal 2000-an, tetapi mengandung kerentanan kritis. Menggantikan SSL hadir TLS (Transport Layer Security) — versi yang ditingkatkan dan distandarisasi oleh IETF. TLS 1.0 (1999) didasarkan pada SSL 3.0, dan versi selanjutnya TLS 1.1 (2006), TLS 1.2 (2008) dan TLS 1.3 (2018) secara bertahap menjauh dari arsitektur asli, menambahkan algoritma enkripsi baru dan menghilangkan kerentanan. Saat ini SSL dianggap usang dan semua sistem modern menggunakan TLS, meskipun karena kebiasaan kedua protokol sering disebut bersama sebagai SSL/TLS.

Sejarah Penciptaan Protokol

Sejarah SSL/TLS dimulai dari kebutuhan akan transmisi data yang aman di web awal. Pada tahun 1994, Netscape mengembangkan SSL 1.0 untuk browser Navigator-nya, tetapi protokol tersebut tidak pernah dipublikasikan karena masalah keamanan serius. SSL 2.0 dirilis pada tahun 1995 dan digunakan dalam praktik, namun mengandung banyak kerentanan: kurangnya perlindungan terhadap serangan Man-in-the-Middle, algoritma enkripsi lemah, dan kerentanan terhadap serangan truncation. SSL 3.0 (1996) memperbaiki sebagian besar masalah, tetapi pada tahun 2014 kerentanan POODLE ditemukan di dalamnya, setelah itu IETF secara resmi menyatakan semua versi SSL usang. TLS 1.0–1.3 secara berurutan meningkatkan kekuatan kriptografi, performa, dan kerahasiaan, dengan TLS 1.3 mengurangi handshake dari dua round-trip menjadi satu, yang sangat penting untuk aplikasi seluler dengan koneksi tidak stabil.

Bagaimana SSL/TLS Handshake Bekerja

Handshake — adalah proses pembentukan koneksi aman antara klien dan server. Ini terdiri dari beberapa langkah berurutan di mana para pihak menyepakati versi protokol, memilih algoritma enkripsi, bertukar kunci, dan saling mengautentikasi. Dalam TLS 1.3, handshake hanya membutuhkan satu interaksi jaringan (1-RTT), sedangkan dalam TLS 1.2 diperlukan dua (2-RTT).

Langkah pertama, klien mengirim ClientHello — pesan yang berisi daftar versi TLS yang didukung, cipher suites, dan angka acak. Server merespons dengan ServerHello berisi versi dan cipher yang dipilih, sertifikat X.509, dan tanda tangan digital. Klien memverifikasi sertifikat melalui rantai otoritas sertifikasi (CA), menghasilkan kunci sesi, dan mengirimkannya terenkripsi dengan kunci publik server dari sertifikat. Setelah konfirmasi oleh server, transmisi data aman dimulai. Seluruh handshake selesai dalam 1–3 milidetik pada perangkat modern, membuatnya tidak terlihat oleh pengguna.

Sertifikat X.509 dan Rantai Kepercayaan

Dasar dari autentikasi TLS adalah infrastruktur kunci publik (PKI) yang dibangun di atas sertifikat format X.509. Setiap sertifikat berisi: nama domain (Common Name atau Subject Alternative Name), kunci publik server, nama penerbit (Certificate Authority), masa berlaku, dan tanda tangan digital CA. Klien memverifikasi sertifikat server melalui rantai kepercayaan: dari sertifikat server hingga CA root, yang sertifikatnya tertanam di sistem operasi. Pada perangkat Android, sertifikat root disimpan di penyimpanan sistem yang diperbarui melalui Google Play Services; di iOS — melalui iOS Updates. Ketika ada mata rantai yang putus (sertifikat kedaluwarsa, ketidakcocokan domain, CA tidak dikenal), klien memutus koneksi. Untuk sertifikat yang ditandatangani sendiri (digunakan dalam pengembangan), diperlukan kepercayaan eksplisit — di Android melalui Network Security Config, di iOS melalui NSExceptionDomains di Info.plist. Proses validasi rantai sertifikat juga mencakup pemeriksaan status pencabutan melalui CRL (Certificate Revocation List) atau OCSP (Online Certificate Status Protocol), meskipun pada perangkat seluler permintaan OCSP sering dilewati untuk mempercepat koneksi — ini adalah kompromi antara keamanan dan performa yang harus dipertimbangkan oleh arsitek.

SSL vs TLS: Perbedaan Utama

Meskipun istilah SSL dan TLS sering digunakan secara bergantian, ada perbedaan teknis mendasar di antara keduanya yang memengaruhi keamanan dan performa aplikasi seluler.

Perbedaan utama TLS 1.3 dari pendahulunya — penggunaan wajib Perfect Forward Secrecy (PFS) melalui protokol ECDHE. Ini berarti bahkan jika penyerang mendapatkan akses ke kunci privat server, ia tidak akan dapat mendekripsi lalu lintas yang sebelumnya disadap. Untuk aplikasi seluler, di mana peretasan server adalah ancaman nyata, TLS 1.3 dengan PFS adalah persyaratan keamanan wajib.

Kerentanan yang Diketahui pada Versi Lama

Versi lama SSL dan TLS memiliki kerentanan yang terdokumentasi yang membuatnya tidak layak untuk digunakan dalam produksi. POODLE (CVE-2014-3566) menyerang SSL 3.0 melalui padding oracle, memungkinkan dekripsi cookie sesi dalam 256 permintaan. BEAST (CVE-2011-3389) mengeksploitasi kerentanan TLS 1.0 dalam mode CBC melalui IV yang dapat diprediksi. Heartbleed (CVE-2014-0160) — bukan kerentanan protokol, tetapi bug dalam implementasi OpenSSL yang memungkinkan membaca memori server: menurut Netcraft, pada tahun 2014 lebih dari 500 ribu server rentan. Mulai dari Android 10 (API 29) dan iOS 13, semua protokol yang disebutkan dinonaktifkan di tingkat sistem. Namun demikian, pengembang harus memeriksa konfigurasi server melalui SSL Labs Test (qualys.com) sebelum meluncurkan aplikasi untuk memastikan tidak ada cipher suites usang dan TLS 1.3 didukung.

Bagaimana SSL/TLS Melindungi Data di Aplikasi Seluler

Dalam aplikasi seluler, TLS melindungi data di tiga tingkat: enkripsi konten (tidak ada yang bisa membaca data kecuali server), pemeriksaan integritas (data tidak dapat diubah dalam perjalanan), dan autentikasi server (klien yakin bahwa ia terhubung ke server yang benar). Autentikasi sangat kritis: tanpanya, penyerang dapat mengganti server melalui DNS-spoofing atau titik akses Wi-Fi palsu.

Menurut studi Google Play Protect (2024), 76% aplikasi Android menggunakan TLS dengan benar dengan pemeriksaan sertifikat. Sisanya 24% melakukan kesalahan: menonaktifkan pemeriksaan sertifikat untuk pengujian (dan lupa mengaktifkannya di produksi), menggunakan sertifikat yang ditandatangani sendiri tanpa validasi, atau mengizinkan protokol usang SSL 3.0 dan TLS 1.0. Apple App Transport Security (ATS) di iOS mewajibkan TLS 1.2 setidaknya sejak 2017, dan mulai iOS 15 secara default menggunakan TLS 1.3 untuk semua permintaan jaringan. Untuk perlindungan tambahan, penerapan Certificate Pinning — pengikatan ke sertifikat server tertentu — juga direkomendasikan.

Implementasi SSL/TLS di Aplikasi Seluler

Mari kita lihat contoh konfigurasi koneksi HTTPS aman di Android menggunakan OkHttp — salah satu pustaka paling populer untuk bekerja dengan jaringan. Konfigurasi yang benar mencakup penggunaan paksa TLS 1.3 dan pemeriksaan sertifikat.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

Dalam contoh ini, kami membatasi set versi TLS yang didukung hanya pada protokol 1.3 dan 1.2, tidak termasuk TLS 1.0/1.1 yang usang. Cipher suites dipilih dari algoritma modern dengan mode AEAD dan Perfect Forward Secrecy wajib. HostnameVerifier memeriksa kesesuaian nama host dengan sertifikat. Untuk iOS, konfigurasi serupa dilakukan melalui konfigurasi URLSession dengan parameter tlsMinimumSupportedProtocolVersion, di mana .TLSv13 ditentukan. Selain itu, di iOS dapat diatur tlsMaximumSupportedProtocolVersion untuk membatasi batas atas versi — ini berguna untuk kompatibilitas dengan server lama yang belum beralih ke TLS 1.3. Konfigurasi semacam itu menjamin tingkat keamanan maksimum saat mentransmisikan data dalam aplikasi seluler.