SSL Bukan Hanya Tentang Enkripsi
“Penerapan SSL seharusnya menjadi hal yang wajib ada dalam setiap halaman login situs web. Meskipun tidak sepenuhnya memberikan perlindungan, SSL adalah jaminan awal bahwa situs yang kita kunjungi bisa dipercaya dan memiliki integritas melindungi data kredensial para penggunanya”
– catatan editor –
Artikel asli dalam Bahasa Inggris oleh: Troy Hunt
Ditranslasikan ke dalam Bahasa Indonesia oleh: Edy Kesuma
Dicek dan ditinjau ulang oleh: Reopan editor
Ini adalah tentang keterjaminan. Ini tentang menyediakan sebuah tingkat kepercayaan keabsahan situs yang cukup memberi keyakinan dimana pengiriman dan penerimaan data dapat mencapai tujuan yang diharapkan tanpa dicegat atau dimanipulasi dalam prosesnya.
Beberapa waktu sebelumnya, saya menulis artikel ironi yang sedikit kurang ajar tentang “Siapa yang mempraktekkan penggunaan password yang buruk.” Saya selalu bersikap kritis pada sejumlah situs yang tidak mengimplementasikan keamanan SSL (Secure Socket Layer) dimana terindikasi tidak menghadirkannya di dalam tampilan browser atau perambah. “Namun tunggu dulu!” teriak beberapa pengomentar, “anda tetap bisa mempostingnya dalam HTTPS dan data akan dienkripsi” kata mereka, “Berhenti menyebarkan ketakutan dan kesalahpahaman,” mereka memperingatkan.
Saya berhati-hati memikirkan beberapa respon tersebut dan membuat sedikit pembaharuan pada akhir kiriman artikel, namun penjelasan tentang pengiriman data dari HTTP ke HTTPS lebih layak dari sekedar catatan kaki. Kesalahpahaman sebenarnya dalam artikel ini adalah hanya karena percaya data kredensial sudah dienkripsi saat ditransmisikan, bukan berarti SSL telah diterapkan dengan baik. Mari perhatikan baik-baik apa yang salah pada kepercayaan tersebut dan mengapa terdapat lebih banyak lagi yang di-SSL dibandingkan dengan sekedar enkripsi.
Dianggap terjamin tanpa umpan balik positif
Mari mulai hanya dari bagian enkripsi dan melihat beberapa contoh situs yang sudah dikenal baik. Yang mana dari dibawah ini yang anda perkirakan akan melindungi data kredensial anda dalam jaringan:
Siapapun diantara mereka? Sebenarnya, semua situs tersebut telah mengimplementasikan SSL ketika mentransmisikan data kredensial anda. Namun tentu saja anda tidak tahu hanya dari melihat gambar diatas bukan? Jika anda termasuk orang yang sedikit teknis, anda dapat memeriksa sumber kode halaman web dan melihat bagian form postingan ke sebuah alamat HTTPS atau anda dapat melihatnya melalui program Fiddler yang bisa mengetahui bagaimana permintaan dibuat dan mengamati protokol berubah dari HTTP ke HTTPS.
Masalahnya adalah sebagian besar orang-orang tidak seperti anda. Semua yang mereka tahu untuk menilai keamanan relatif dari sebuah situs adalah informasi yang browser atau perambah tampilkan kepada mereka dari indikator SSL yang ada dimana-mana. Tanpa hal ini, mereka menganggap (mungkin karena profile situs tersebut) bahwa keabsahan dari situs dan data kredensial mereka telah aman dan terjamin.
Jaminan implisit dengan atau tanpa umpan balik positif
Mari melihat sekilas beberapa situs lain dari sudut pandang berbeda:
Keterjaminan pada situs tersebut dibuat implisit atau tersirat. Mereka mencoba mengatakan “Hey, ada gambar gembok kunci dalam form login sehingga kita telah aman.” Tentu saja ini tidak berarti apa-apa dan gambar gembok kunci yang kita temui dimana-mana tidak lebih dari usaha untuk menunjukkan keabsahan dan keamanan.
Poin yang ingin saya tunjukkan disini adalah tanpa upaya perambah membuat kehadiran SSL dapat dilihat jelas dan mengijinkan sertifikat untuk dicek, gambar-gambar ikon tersebut tidak berarti apa-apa. Pada faktanya mereka sangat salah kaprah dan menciptakan salah pemahaman keamanan dengan mencoba menunjukkan sesuatu yang ternyata bukan, terlepas dari ada tidaknya SSL.
Membuat umpan balik positif dan jaminan yang jelas atau eksplisit
Browser atau perambah yang bagus telah memiliki kemampuan secara proaktif memberitahu anda validitas dan keaslian dari suatu situs dengan menyediakan keterjaminan yang positif dan eksplisit. Hal ini biasanya tampak dengan jelas pada bagian bar URL dan meskipun mereka tampak tidak sama, konsep yang digunakan adalah konsisten:
Masing-masing dari browser tersebut, menyediakan jaminan yang lebih pasti dengan memberikan gambaran detail dari sertifikat SSL yang bisa kita baca langsung:
Semua poin diatas adalah latihan untuk memberikan kemudahan memverifikasi keabsahan suatu situs bagi kita dan memberikan kita kepercayaan (eksplisit) bahwa data kita akan dienkripsi saat ditransmisikan. Dan hal ini membawa kita kepada inti dari permasalahan: tidak menampilkan form login dalam HTTPS memberikan jaminan kosong dari keaslian situs sebelum data kredensial anda dimasukkan.
Mengeksploitasi pola HTTP ke HTTPS
Cara termudah menggambarkan bahaya ini adalah dengan melihat kasus “man-in-the-middle-attack:”
Penyerang membuat suatu koneksi sendiri dengan calon korban dan mengirimkan pesan diantara mereka, membuat mereka percaya bahwa mereka saling berbicara satu sama lain melalui koneksi privat, dimana kenyataannya seluruh percakapan mereka dikendalikan oleh penyerang.
Dalam kasus MITM, seorang penyerang berada diantara PC dan server. Sifat alami dari internet adalah dimana terdapat banyak, banyak sekali permintaan-permintaan data yang lewat melalui perantara.
Bayangkan sebuah kasus di suatu cafe yang menyediakan layanan wifi, ketika seorang pelanggan terkoneksi dengan router wireless, membuat jalan keluar dari internet gateway, berjalan melewati ISP kemudian disalurkan melalui lusinan simpul internet sebelum mendarat di server tujuan.
Permasalahan dari permintaan login melalui HTTP adalah dia dapat dimanipulasi dari setiap bagian. Mari kita melihat contoh kasus dimana pemerintah Tunisia mengumpulkan data username dan password:
Instansi Pemerintah Internet Tunisia sedang disalahkan oleh publik karena kehadiran script JavaScript yang merekam data username dan password. Kode ini ditemukan pada halaman login Gmail, Yahoo, dan Facebook, dan dikatakan sebagai alasan terjadinya pembajakan akun sesuai yang dilaporkan oleh para pendemo Tunisia.
Apa yang terjadi pada kasus ini adalah ISP menanamkan sebuah potongan script kode pada halaman login situs-situs tersebut. Dan untuk berjaga-jaga percabangan masalah ini masih belum jelas:
Empat orang ahli berbeda berkonsultasi dengan media Tech Herald secara independen mengkonfirmasi pemikiran kami: kode yang tertanam digunakan untuk mencuri data login kredensial.
Namun cerita sebenarnya (dan relefan dengan artikel ini) sedikit lebih jauh:
Kode JavaScript yang tertanam hanya tampil ketika salah satu situs ini mengakses protokol HTTP dibanding HTTPS. Pada masing-masing pengetesan kasus, kami telah berhasil mengkonfirmasi bahwa Gmail dan Yahoo hanya terjadi ketika menggunakan protokol HTTP. Di lain sisi, akses default atau standar Facebook adalah HTTP, sehingga para pengguna di Tunisia perlu mengetikkan alamat HTTPS secara manual.
Bukanlah masalah bahwa situs-situs ini mengirimkan data melalui HTTPS, hanya saja fakta bahwa mereka mengijinkan halaman login ditampilkan tanpa perlindungan adalah hal yang cukup bagi para ISP memanipulasi konten dan merekam data kredensial melalui JavaScript sebelum mereka mengirimkannya melalui HTTPS. Jika halaman login meminta keterjaminan melalui HTTPS (seperti yang terjadi pada Facebook sebagai contoh), pengeksploitasian data ini tidak akan terjadi.
ISP nakal dan diktator adalah sesuatu, namun pertimbangkan apa yang terjadi setiap anda terhubung pada Wi-Fi publik. Ambil skenario Cafe Kopi sebagai contoh:
Adalah hal yang luar biasa bagaimana Internet dirancang, gateway dalam router kita dapat membajak permintaan HTTP data kita dan kita tidak dapat menghentikannya. Dalam kasus ini, kita dapat melihat URL telah berubah dalam browser atau perambah kita setelah diarahkan, namun jika sebuah gateway yang jahat secara transparan mem-proxy permintaan HTTP kita ke muatan malware jahat dari kloningan www.google.com, kita tidak memiliki cara untuk mengetahuinya karena tidak akan menjadi pengalihan dan URL tidak akan mengalami perubahan.
Hal ini lebih dari sekedar sebuah kecemasan kecil dan kita seperti memamerkan diri kita sendiri pada bahaya setiap kita mengkoneksikan diri pada suatu layanan Wi-Fi umum. Tentu saja masalah ini semakin diperparah ketika anda tidak bisa mengakses jaminan eksplisit dari keaslian situs sebelum memindahtangkankan data kredensial anda.
Namun terdapat cara lain mengeksploitasi pola HTTP ke HTTPS, sebagai contohnya adalah “DNS Poisoning.” Jika anda bisa mengalihkan permintaan ke suatu alamat yang sah ke host yang benar-benar berbeda, anda memiliki kesempatan untuk mengolah konten di host palsu tersebut (mungkin dengan meniru halaman login Facebook) dan tentu dengan hasil yang pasti. Namun tentu hal ini tidak memiliki sertifikat SSL resmi dan ketidakhadirannya dapat digunakan untuk mengidentifikasi sesuatu yang mencurigakan. Namun tambahan lagi, hal ini hanya berlaku jika sertifikat SSL diperkirakan tersedia sebelum proses login yang mana bukanlah kasus dimana data HTTP diposting dalam pola HTTPS.
Posisi OWASP (Open Web Application Security Project)
Tentu saja selalu ada sisi pandang lain terhadap masalah ini jadi saya mencari beberapa masukan melalui forum The Security Stack Exchange dengan bertanya apakah memposting data dari HTTP ke HTTPS adalah praktek yang buruk? Jawabannya direferensikan dalam praktek terbaik OWASP SSL:
Penampakan Halaman Login Harus Menggunakan SSL
Halaman yang benar dimana pengguna mengisi halaman login harus menggunakan halaman HTTPS. Jika tidak, seorang penyerang bisa memodifikasi halaman yang dilihat oleh pengguna dan mengubah pengiriman lokasi data atau menyusupkan kode JavaScript yang mana akan mencuri data username/password ketika diketikkan.
Terdengar akrab? Hal ini membawa kita kembali ke poin dimana kita sudah mendiskusikannya diatas. Jika halaman login tersebut tidak diminta melalui SSL, anda tidak memiliki jaminan keaslian halaman web tersebut.
Keamanan tidak dimulai dan tidak berakhir pada SSL
Sebelum orang-orang mengatakan hal ini, SSL yang diterapkan dengan baik tidak menjamin keamanan apapun di dalam lapisan transmisi. Bisa saja menjadi benar-benar berantakan dari server web dan seterusnya.
SSL juga bukanlah alat untuk membuktikan sesuatu. Terdapat beberapa contoh SSL dieksploitasi dari satu sudut atau dari hal lain (contoh kasus 200 PS3 digunakan untuk memecahkan MD5). Bukanlah hal mudah, namun hal ini bisa dilakukan.
Walaupun begitu, keamanan SSL adalah satu-satunya jaminan awal yang kita miliki. Ini adalah hal yang digunakan dimana-mana untuk menciptakan kepercayaan pada integritas data dan menjamin situs yang kita pergunakan.
Menjalankan upaya mengimplementasikannya dalam postingan data kredensial namun secara sadar meniadakannya dari halamam login adalah seperti menjual cuma-cuma esensi keamanan lapisan web cukup dekat pada potensinya. Bagi situs seperti Facebook, Twitter dan bahkan Dropbox yang menggunakan pendekatan ini, sebenarnya memang sangat aneh.
