Understanding HTTPS

Https adalah jargon yang paling sering dikampanyekan oleh situs internet banking dan ecommerce. Benarkah https adalah jaminan keamanan bertransaksi? Tipe serangan seperti apa yang bisa dicegah dengan https dan tipe serangan apa yang tidak bisa dicegah dengan https?

Apa yang Dijamin HTTPS ?

Bayangkan bila suatu saat anda menelpon Call Center suatu bank untuk melakukan transaksi. Sangat penting bagi bank untuk memastikan dulu siapa anda, sebelum melakukan transaksi seperti yang anda minta. Karena melalui telepon, bank hanya bisa mendengar suara anda, mungkin saja ada orang lain yang berpura-pura menjadi anda dan menguras habis rekening anda.

Begitu pula di internet, ketika anda mengakses suatu website, anda harus benar-benar yakin bahwa anda sedang mengakses server yang benar, bukan situs palsu yang berminat untuk mencuri data rahasia anda. Sangat berbahaya akibatnya bila anda terjebak mengakses situs palsu, sebab itu artinya anda memberikan data rahasia anda pada orang yang salah.

Inilah yang disebut dengan Authentication, yaitu memastikan identitas, siapa anda. Ketika anda berkomunikasi dengan orang lain, anda harus tahu betul dengan siapa anda berbicara.

Selain memastikan anda berbicara dengan orang yang benar, sangat penting pula bahwa hubungan telpon antara anda dan bank tidak didengarkan oleh orang lain, karena anda akan membicarakan hal yang sensitif dan rahasia seperti PIN. Inilah yang disebut dengan Confidentiality, yaitu kerahasiaan data, memastikan tidak ada kebocoran data di tengah jalan.

Ketika anda mengakses internet, paket data yang anda kirim akan berkelana dari satu server ke server lain sebelum mencapai server tujuan. Sangat mudah bagi orang lain untuk melakukan sniffing, mengintip data anda yang lewat karena internet adalah jaringan umum yang bebas dipakai siapa saja.

Itulah dua hal utama yang dijamin oleh HTTPS, yaitu Authentication (who are you speaking with?) dan Confidentiality (is someone listening to your conversation?). Authentication dan Confidentiality dalam https dijamin dengan perpaduan penggunaan kriptografi simetris dan asimetris.

Public Key/Asymmetric Cryptography (PKC) and Symmetric Cryptography

courtesy of uic.edu

Setiap enkripsi dan dekripsi pasti memerlukan kunci rahasia (enkripsi/dekripsi tanpa kunci rahasia, itu namanya  encoding/decoding). Bila enkripsi dan dekripsi dilakukan hanya dengan satu kunci yang sama, ini adalah jenis enkripsi simetris. Keunggulannya adalah kecepatannya tinggi karena tidak enkripsi simetris tidak membutuhkan komputasi yang rumit. Namun kelemahannya adalah kesulitan dalam melakukan pertukaran kunci.

Bayangkan bila Alice ingin berkomunikasi dengan Bob dengan kriptografi simetris. Sebelum bisa berhubungan, keduanya harus menyepakati bersama kunci yang akan dipakai. Bagaimana cara menegosiasikan kunci ini? Apakah dikirim melalui sms, email atau telpon? Bukankah sms, email dan telpon bisa disadap?

Berkomunikasi dengan kriptografi simetris jadi seperti ayam dan telur. Enkrip dulu atau kunci dulu? Kalau enkrip dulu, kuncinya bagaimana? Kalau kunci dulu, bagaimana cara mengirim kunci dengan aman?

PKC datang membawa solusi (jadi seperti kampanye), yaitu dengan penggunaan dua macam kunci, yaitu publik dan private. Jadi Alice dan Bob masing-masing harus sudah mempunyai kunci public dan private. Kunci public untuk diberikan pada orang lain (bukan kunci rahasia), dan kunci private harus dirahasiakan. Bila Alice ingin mengirim pesan ke Bob, maka Alice harus meng-enkrip pesannya dengan kunci publik milik Bob. Untuk membaca pesan Alice, Bob bisa men-dekripnya dengan kunci private Bob sendiri. Jadi ingat, bahwa kunci untuk enkripsi dan dekripsi selalu berlawanan. Lawan dari kunci publik adalah kunci private, lawan dari kunci private adalah kunci publik.

• Bila pesan di-enkrip dengan kunci publik, maka dekrip-nya dengan kunci private: Artinya hanya bisa dibuka oleh pemilik kunci private.
• Bila pesan di-enkrip dengan kunci private, maka dekrip-nya dengan kunci public: Artinya semua orang bisa men-dekrip.

Apa perlunya meng-enkrip pesan dengan kunci private? Karena semua orang bisa membacanya. Kalau enkripsi dengan kunci publik tujuannya untuk kerahasiaan (Confidentiality), maka enkripsi dengan kunci private tujuannya untuk Authentication: Memastikan siapa pembuat pesan.

Bila pesan berhasil di-dekrip dengan kunci publik Bob berarti  DIJAMIN pesan itu dibuat oleh Bob.

Man-in-the-Middle (MITM) Problem

courtesy of pburkholder.com

PKC ternyata juga tidak terbebas dari masalah. Bayangkan bila Alice ingin mengirim pesan ke Bob. Charlie sebagai orang ke-3 ingin mendengarkan pesan dari Alice ke Bob. Berikut skenario tipu muslihat Charlie:

1. Sebelum bisa mengirim pesan rahasia. Alice meminta Bob untuk mengirimkan kunci publiknya.
2. Bob mengirim kunci publiknya ke Alice.
3. Sebelum tiba di Alice, kunci publik Bob dicatat Charlie dan diganti dengan kunci publiknya sendiri, lalu diteruskan ke Alice.
4. Alice tertipu, mengira kunci publik yang diterimanya adalah kunci publik Bob, padahal itu milik Charlie.
5. Alice mengenkrip pesannya dengan kunci publik Charlie (bukannya Bob), dan mengirimkannya ke Bob.
6. Sebelum tiba di Bob, pesan Alice di-dekrip oleh Charlie dengan kunci private Charlie (karena enkripnya dengan kunci publik Charlie).
7. Agar Bob tidak curiga, pesan yang telah di-dekrip itu, dienkrip lagi dengan kunci publik Bob yang sebelumnya sudah dicatat lalu dikirim ke Bob.
8. Bob men-dekrip pesan itu dengan kunci private-nya, dan pesan itu dibaca oleh Bob seperti tidak terjadi apa-apa.

Dalam skenario tersebut, Charlie telah sukses berperan sebagai Man-in-the-Middle yang menyadap pesan dari Alice ke Bob tanpa disadari keduanya.

Serangan MITM itu bisa terjadi karena Alice tidak bisa memastikan bahwa pesan berisi publik key yang diterimanya adalah benar dari Bob. Sebab untuk bisa memastikan pesan itu dari Bob, maka pesan itu harus di-enkrip dengan kunci private Bob, dan di-dekrip oleh Alice dengan kunci public Bob, padahal  Alice tidak tahu kunci public Bob.

Jadi mirip ayam dan telur juga kan? Untuk mendapatkan kunci publik harus memastikan identitas pembuat pesan, sedangkan untuk memastikan identitas pembuat pesan harus tahu kunci publik.

Pihak Penjamin: Solusi Mendapatkan Kunci Publik

Kita sudah melihat bahwa PKC juga memiliki kelemahan terhadap serangan mitm. Agar serangan mitm tidak terjadi dibutuhkan mekanisme untuk mendapatkan publik key yang benar.

Untuk memecahkan masalah ayam dan telur dalam PKC, dibutuhkan bantuan pihak ke-3 sebagai pihak penjamin yang kunci publiknya telah dikenal sebelumnya.

Mari kita buat ilustrasinya pengembangan dari kasus mitm oleh Charlie sebelumnya, anggaplah pihak penjamin itu adalah Dedy dengan kunci publik yang telah dikenal sebelumnya oleh Alice.

1. Ketika Alice ingin mengetahui kunci publik Bob, maka Bob sebelumnya harus meminta Dedy untuk membuat surat jaminan yang berisi kunci publik Bob dan pernyataan bahwa Bob adalah orang baik dan rajin menabung.
2. Kemudian surat itu di-enkrip dengan kunci private Dedy untuk memastikan bahwa surat itu benar dibuat oleh Dedy.
3. Bila Alice bertanya pada Bob, “Hey Bob tolong kirim kunci publikmu, aku ada pesan rahasia untukmu”. Maka Bob akan mengirimkan surat jaminan dari Dedy pada Alice.
4. Ketika surat jaminan yang dikirim Bob tiba di Alice. Alice bisa menguji identitas pembuat surat itu dengan cara men-dekrip dengan kunci publik Dedy yang sudah dikenalnya.
5. Bila berhasil di-dekrip, maka surat jaminan itu benar dibuat oleh Dedy. Di dalam surat jaminan itu tertera juga kunci publik Bob. Kini Alice siap mengirim pesan rahasia pada Bob.

Bagaimana dengan Charlie? Bila Charlie nekat mengganti surat jaminan Dedy dengan surat jaminan yang dibuatnya sendiri lalu mengirimnya ke Alice. Maka Alice dengan mudah mengetahui bahwa surat ini palsu, karena tidak bisa didekrip dengan kunci publik Dedy, artinya surat jaminan ini bukan dibuat oleh Dedy.

Why We Need Authentication

Mungkin ada yang bingung sebenarnya untuk apa sih otentikasi server itu? Bukankah kalau kita buka yahoo.com, pasti yang menjawab adalah servernya yahoo, bukan servernya google. Kan tidak mungkin bisa tertukar begitu. Benarkah tidak mungkin tertukar?

Ketika kita mengakses situs, yang kita tulis di address bar browser biasanya adalah domain name, misalkan yahoo.com. Selanjutnya browser akan meminta DNS untuk menerjemahkan yahoo.com menjadi IP address. Baru kemudian browser bisa berkomunikasi dengan server.

Nah, proses pengubahan dari domain name ke IP address ini yang menjadi celah yang memungkinkan seseorang tersesat ke server yang salah. Dengan teknik ARP poisoning, DNS cache poisoning, atau proses routing yang sengaja disesatkan, seseorang bisa saja bukan mengakses server yang benar.

Untuk itulah kita perlu Authentication.

Authentication: Who are you speaking with.

Mari kita bahas bagaimana https menjamin authentication. Sebelum berkomunikasi dengan server, browser mensyaratkan server untuk meng-otentikasi dirinya, menunjukkan bukti identitasnya. Bukti identitas ini berbentu sertifikat yang ditanda-tangani (digital signature) oleh penjamin yang disebut Certificate Authority, mirip dengan ilustrasi Dedy sebagai penjamin Bob di atas. Dalam sertifikat tersebut tertera antara lain: nama perusahaan, alamat web, dan kunci publik.

Ketika browse menghubungi server, untuk menunjukkan identitas dan memberikan kunci publiknya,  server akan mengirimkan sertifikatnya. Kemudian browser akan memverifikasi apakah sertifikat itu ditanda-tangani oleh penjamin (CA) yang trusted (browser memiliki daftar trusted CA). Jika tanda tangan digital CA pada sertifikat itu valid, maka dijamin sertifikat itu benar dibuat oleh CA. Selain itu browse juga akan memeriksa tanggal expired sertifikatnya dan membandingkan alamat web yang ada di sertifikat dengan server yang sedang dihubungi. Jika semuanya valid, browser akan mengambil kunci publik server yang tertera pada sertifikat.

Oke, dari sertifikat yang kamu beri, saya dapat kunci publik ini. Kalau kamu punya pasangan kuncinya (private key), berarti kamu benar-benar server yang disebut di sertifikat ini.

Dengan kunci publik server di tangan, browser akan mencoba melakukan komunikasi dengan mengirimkan pesan ter-enkripsi. Bila server bisa menjawab pesan ini, maka server itu pasti punya kunci private, dengan kata lain serve itu pasti benar-benar pemilik kunci publik yang tertera di sertifikat.

Dengan cara ini browser akan yakin sedang terhubung dengan server yang benar.

Confidentiality: Is Someone Listening to Your Conversation?

https layer stack

Sebenarnya https bukanlah satu protokol, tapi kumpulan protokol (dalam hal ini saja banyak yang salah paham) yang diberi nama HTTPS. Kumpulan protokol yang membentuk https adalah http yang ditumpangkan di atas SSL (Secure Socket Layer) atau TLS (Transport Layer Security). Jadi kalau dalam layer posisinya dari bawah ke atas adalah TCP -> SSL/TLS -> HTTP. SSL dan TLS adalah protokol yang secure dalam artian seluruh data yang dikirim dan diterima dalam keadaan ter-enkrip. Sedangkan http adalah protokol yang tidak secure karena datanya telanjang. Perkawinan antara http dan (SSL atau TLS) menghasilkan keturunan yang lebih unggul dari kedua orang tuanya, yang disebut https.

Mari kita lihat interaksi yang terjadi antar protokol tersebut. Bayangkan anda sedang membuka halaman https, dan browser anda sudah terhubung dengan web server dalam mode secure (biasanya muncul tanda gembok di status bar). Ketika anda meng-klik sebuah link, yang terjadi adalah browser mengirimkan request GET  dalam protokol HTTP (tidak ter-enkrip). Request GET ini diserahkan pada layer SSL/TLS untuk di-enkrip. Hasil enkripsi request GET ini kemudian diserahkan pada layer TCP untuk dikirim ke tujuan (server web).

Ketika request GET yang ter-enkrip ini sampai di tempat tujuan (server web). Pertama paket akan di-handle oleh layer TCP. Kemudian paket itu diserahkan pada layer SSL/TLS untuk di-dekrip. Hasilnya adalah paket dalam format HTTP tidak ter-enkrip. Baru kemudian paket HTTP ini diserahkan pada yang berhak, yaitu server web (misal:Apache). Setelah Apache selesai menjawab, dia akan mengirimkan balasan request GET tersebut dalam bentuk paket HTTP. Paket ini akan di-enkrip dulu oleh layer SSL/TLS sebelum diserahkan pada layer TCP dan dikirim ke client (browser yang mengirimkan request GET semula).

SSL menjamin kerahasiaan komunikasi end-to-end, artinya mulai dari ujung server hingga ujung client. Tidak ada satu pun server atau komputer yang menjadi perantara antara client hingga server bisa membaca isinya.

Kombinasi Symmetric dan Asymmetric Cryptography

Dalam https komunikasi yang terjadi semua ter-enkripsi. Seperti yang sudah saya jelaskan di awal, masing-masing jenis enkripsi memiliki keunggulan dan kelemahan. Keunggulan kriptografi simetris adalah kecepatannya yang tinggi. Sedangkan keunggulan kriptografi asimetris adalah kemudahan dalam pertukaran kunci.

Oleh karena itu https memadukan kedua jenis enkripsi ini. Pada tahap awal komunikasi, client dan server berkomunikasi dengan menggunakan kriptografi asimetris. Enkripsi ini hanya ditujukan untuk menyepakati dan saling bertukar kunci rahasia yang akan dipakai dengan kriptografi simetris. Jadi pertukaran kunci rahasia dilakukan dalam keadaan ter-enkrip dengan kriptografi asimetris.

Setelah kedua pihak memegang kunci rahasia yang sama, komunikasi selanjutnya dilakukan dengan kriptografi simetris karena lebih murah dan cepat.

Apa yang Tidak Dijamin HTTPS ?

SSL hanya menjamin authentication dan confidentiality saja. Padahal masih banyak attack yang mengancam aplikasi web, antara lain SQL Injection, XSS, CSRF, Denial of Service, Brute-Force-Attack. Ya benar, semua serangan terhadap aplikasi web selain sniffing dan mitm bisa dilakukan tanpa hambatan.

Selain itu kerahasiaan data hanya berlaku di perjalanan antara client hingga server. Sedangkan di dalam komputer client atau server itu sendiri, data memungkinkan untuk disadap dengan penyadapan di level sistem operasi.

Hebatnya lagi, karena komunikasi antara client dan server ter-enkrip, maka IDS (Intrusion Detection System) tidak berguna. IDS bekerja dengan cara meng-inspeksi paket yang masuk (persis seperti sniffer). Bila paket mengandung pattern yang mencurigakan, maka IDS akan membunyikan alarm. Bila komunikasi antara client dan server ter-enkrip, maka IDS tidak bisa melihat isi paket, apakah mengandung pattern yang berbahaya atau tidak.