Milyaran penghuni dunia maya tanpa sadar menggunakan SSL ketika login ke Facebook, Twitter, Google, Amazon ataupun melakukan transaksi Internet Banking. Secure Socket Layer (SSL) adalah protokol enkripsi (aturan pengacak data) yang digunakan untuk mengamankan (menjamin kerahasiaan dan integritas) lalu lintas data yang dikirim melalui jaringan Internet. Selain SSL terdapat SSH dan IPSec yang juga menjadi standar de facto protokol enkripsi jaringan. Namun SSL menjadi pilihan utama karena lebih mudah implementasinya dan dapat digunakan secara transparan.

HTTPS vs SSL

Hypertext Transfer Protocol Secure (HTTPS) merupakan protokol (aturan) berbasiskan protokol HTTP yang menggunakan protokol SSL untuk mengamankan data-data saat dikirimkan. “Kalau ada di browser ada gambar gembok terkunci dan dibagian alamat situs web tertulis https://www.xyz.co.id berarti aman (Gambar-1). Kalau hanya http://www.xyz.co.id tanpa huruf s berarti tidak aman.” adalah penjelasan yang sering kita dengar saat seseorang menjelaskan salah satu faktor keamanan di Internet. Karena implementasi SSL terbanyak adalah dalam bentuk HTTPS, maka tidak mengherankan jika SSL lebih dikenal dengan HTTPS dikalangan pengguna Internet. Namun HTTPS bukanlah SSL.

Gambar-1: Contoh penggunaan SSL pada browser Internet Explorer dan XecureBrowser

Kemudahan dan keamanan SSL

Kemudahan dan keamanan selalu berbanding terbalik. Namun Netscape berhasil memadukan Kemudahan dan keamanan pada protokol SSL, terutama SSL versi 3.0. Sepengetahuan saya, tidak ada protokol keamanan jaringan lain yang pembuatan (baca: pemrograman) dan implementasinya (konfigurasi sistem dan penggunaan) semudah SSL. Fleksibilitas implementasi SSL memungkinkan penggunaan berbagai macam algoritma enkripsi, mulai dari yang relatif mudah dibongkar hingga ketingkatan yang sangat aman. Kedua alasan tersebut dan didukung oleh kebutuhan melakukan transaksi yang aman melalui Internet menjadikan SSL sebagai protokol yang diadopsi secara cepat dan luas oleh industri teknologi informasi. Saat ini, mayoritas produk TI yang terhubung ke Internet mendukung penggunaan SSL.

Apakah benar SSL aman?

Aman atau tidak tergantung implementasi. Banyak pihak-pihak yang bertanggung-jawab terhadap keamanan implementasi SSL. Sayangnya amat sedikit pembuat kebijakan, arsitek keamanan TI, sistem administrator, dan auditor yang memahami teknologi SSL secara mendalam. Bahkan “plagiat” kebijakan dan perancangan implementasi SSL dilakukan secara kolosal dan kemudian beramai-ramai menyebutnya sebagai Internet security best practice. Termasuk menjadikan peringatan keamanan (Gambar-2) yang diberikan oleh client (browser, seperti Internet Explorer, Firefox, Opera, dll) sebagai sesuatu yang lumrah untuk diabaikan. Hal-hal tersebut yang menjadi akar masalah ketidak-amanan 99% implementasi SSL dewasa ini, termasuk pada sistem Internet Banking.

SSL dirancang dengan asumsi bahwa komunikasi antara server sebagai penyedia layanan dan client sebagai pengguna melalui jaringan Internet yang tidak aman. Analoginya, seorang jenderal harus dapat memastikan kerahasiaan dan integritas pesan yang dikirimkan (melalui wilayah yang dikuasai musuh) ke pasukan yang berada dimedan pertempuran. Apa jadinya jika perintah sang jenderal isinya “Berjuang sampai mati!” diganti pihak lawan menjadi “Menyerah sekarang juga”?

Kekuatan SSL bergantung pada beberapa faktor kunci berikut ini:

1. Otentikasi mutual atau otentikasi dua arah
2. Pengamanan kunci privat
3. Kesadaran Keamanan dari Pengguna
4. Sistem operasi dan aplikasi
5. Algoritma enkripsi

Gambar-2: Contoh peringatan keamanan pada browser Internet Explorer

Otentikasi Mutual yang Diabaikan

Di dunia maya, pelaku kejahatan bisa menyamar menjadi siapa saja dengan mudah, sehingga  proses otentikasi untuk mengetahui secara pasti siapa yang sedang diajak berkomunikasi menjadi amat penting. Penggunaan sertifikat digital (semacam identitas elektronik) menjadi solusi utama otentikasi di dunia maya. Tanpa melakukan otentikasi dengan sertifikat digital sebelum berkomunikasi, sama halnya dengan berkomunikasi dengan menggunakan topeng atau dalam kondisi gelap gulita.

SSL versi 2.0 yang di release Netscape tahun 1995 memiliki berbagai kelemahan. Salah satu diantaranya adalah tidak terdapat mekanisme otentikasi mutual atau otentikasi dua arah ketika melakukan negosiasi session key dan pemilihan jenis algoritma enkripsi. Pada SSL versi 2.0, hanya client (misal: browser) yang memastikan bahwa server yang diakses adalah asli, bukan server palsu milik penjahat, dengan cara meminta sertifikat digital milik server, memeriksa keaslian dan validitasnya.

Menyadari kelemahan fatal tersebut, Netscape mengeluarkan SSL versi 3.0 di tahun 1996 yang memiliki fungsi otentikasi mutual. Pada SSL versi 3.0 server juga dapat melakukan proses otentikasi sertifikat digital milik client. Namun agar sistem-sistem yang menggunakan SSL versi 2.0 tetap berfungsi dan sambil menunggu proses migrasi, proses otentikasi sertifikat digital milik client hanya menjadi pilihan bukan keharusan.

Saat itu, para perintis e-commerce menganggap proses otentikasi mutual sebagai rintangan utama bagi bisnis yang sedang dirintis sehingga layak diabaikan untuk sementara waktu. Hingga saat ini, hasil survey yang dilakukan WhiteHackerLab (Divisi penelitian dan pengembangan di XecureIT) menunjukan bahwa setelah hampir 15 tahun SSL versi 3.0 digunakan secara masal, 99% layanan e-commerce tidak melakukan otentikasi mutual. Pertanyaan yang amat sederhana, bagaimana bisa aman jika setiap orang yang masuk ke pusat perbelanjaan atau bank menggunakan topeng?

Kunci Privat yang Tidak Privat

Sebelum sesi SSL terbentuk, server mengirimkan sertifikat digital ke client sehingga client dapat memastikan keaslian server. Demikian sebaliknya jika proses otentikasi mutual dilakukan client akan mengirimkan sertifikat digital miliknya ke server.

Sertifikat digital yang digunakan dalam proses otentikasi diatas berisi kunci publik. Setiap kunci publik memiliki pasangan kunci privat yang unik sehingga tidak dapat digunakan dengan kunci publik yang lain. Kunci privat digunakan oleh si pemilik untuk melakukan tanda tangan digital. Seluruh informasi yang ditanda-tangani (baca: dienkripsi) oleh kunci privat terjamin integritasnya dan hanya bisa didekripsi menggunakan kunci publik pasangannya. Sebaliknya, seluruh informasi yang dienkripsi oleh kunci publik terjamin kerahasiannya dan hanya bisa didekripsi menggunakan kunci privat pasangannya. Jika kunci privat jatuh ke tangan penjahat, maka penjahat dengan mudah dapat menyamar sebagai si pemilik kunci privat (melakukan tanda-tangan secara elektronik), merubah dan membaca informasi yang sensitif.

Pencurian kunci privat kerap dan mudah terjadi. Salah satu yang mengegerkan yaitu ketika tahun 2002 Verisign, salah satu certificate authority (CA) terbesar dan terpercaya didunia menjadi korban penipuan (social engineering). Saat itu Verisign memberikan kunci privat milik Microsoft kepada seseorang yang mengaku sebagai manajemen Microsoft tanpa melakukan proses verifikasi menyeluruh.

Penjagaan kunci privat didalam server juga amat lemah. Ketika test penetrasi dilakukan terhadap salah situs web penyedia layanan transaksi elektronik, kunci privat dapat dicuri ketika server berhasil diambil alih. Disitus lainnya, ditemukan bahwa terdapat beberapa orang yang memiliki hak sebagai administrator. Tanpa mekanisme security monitoring yang ketat, administrator yang jahat dapat dengan mudah mencuri kunci privat tersebut tanpa terdeteksi. Dalam kasus menggunakan server sewaan di Internet, sudah pasti administrator server dapat mengkopi kunci privat dengan mudah. Belum lagi jika harddisk di server yang digunakan untuk menyimpan kunci privat rusak dan dikembalikan ke penjual atau produsen. Penjual atau produsen yang memiliki akses fisik ke piringan didalam harddisk rusak tersebut dapat mengambil kunci privat milik server.

Bersambung ke: Ilusi Keamanan Secure Socket Layer (SSL), Bagian-II – Terakhir

Gildas Deograt Lumy, CISA, CISSP

Senior Information Security Consultant di XecureIT
Koordinator Komunitas Keamanan Informasi (KKI)
Koordinator Information Security Professional Network (ISPN)

Majalah InfoKomputer, edisi Oktober 2010