2

DAFTAR ISI

DAFTAR ISI ....................................................................................................................2

BAB I PENDAHULUAN.................................................................................................3

1.1 Latar Belakang .......................................................................................................3

1.2 Tujuan Penelitian ...................................................................................................3

1.3 Metode Penelitian...................................................................................................3

1.4 Sistematika Penulisan.............................................................................................3

BAB II PEMBAHASAN ..................................................................................................5

2.1 Sejarah Perkembangan SSL....................................................................................5

2.2 SSL Fungsionality..................................................................................................6

2.3 Mekanisme Kerja SSL..........................................................................................10

2.3.1 Alert .........................................................................................................10

2.3.2 Handshake ................................................................................................10

2.3.3 Session......................................................................................................12

2.3.4 Mengakhiri Session...................................................................................13

2.4 Sertifikat SSL.......................................................................................................14

2.5 SSL dan TSL........................................................................................................16

2.6 Celah Keamanan SSL...........................................................................................17

2.6.1 Certificate Distribution .............................................................................17

2.6.2 Self-Certification ......................................................................................17

2.6.3 Absent Client Certificate ...........................................................................17

2.6.4 Automated Systems ...................................................................................18

2.6.5 Human Error ............................................................................................18

2.6.6 Lower-Layer Protocols .............................................................................18

2.7 Serangan pada SSL dan Pencegahannya ...............................................................18

2.7.1 Man In The Middle(MITM) Attack ...........................................................18

2.7.2 Sniffing SSL Traffic ...................................................................................30

BAB III PENUTUP........................................................................................................36

DAFTAR PUSTAKA.....................................................................................................37

3

BAB I

PENDAHULUAN

1.1. Latar Belakang

Salah satu objek dalam cakupan keamanan adalah keamanan protokol yang

dipergunakan dalam komunikasi dan transaksi. Protokol, dalam konteks ini merupakan

suatu set aturan yang dipergunakan oleh komputer-komputer (yang terhubung dalam suatu

jaringan) untuk saling berkomunikasi. Protokol yang paling banyak dipergunakan dalam

Web merupakan set protokol TCP/IP.

Sayangnya, protokol ini didesain tanpa memperhatikan faktor keamanan data. Oleh

karena itu dibutuhkan suatu mekanisme tambahan untuk memperkokoh keamanan protokol

ini tanpa harus menggantinya dengan yang lain. Dengan protokol (beserta mekanismenya)

yang aman serta implementasi yang benar, tingkat keamanan komunikasi dan transaksi

Web dapat ditingkatkan. Salah satu metode penerapan keamanan protokol ini adalah

dengan menerapkan Secure Socket Layer (SSL).

1.2. Tujuan Penelitian

Tujuan dari penelitian ini adalah untuk mengetahui dan memahami teknologi Secure

Socket Layer (SSL), meliputi sejarah perkembangan SSL, mekanisme kerja dan serangan

pada SSL serta pencegahannya.

1.3. Metode Penelitian

Metode yang digunakan adalahstudy literature yang diambil dari buku, security report

atau artikel online di internet. Metode ini digunakan karena waktu penelitian yang cukup

singkat.

1.4. Sistematika Penulisan

Bab I Pendahuluan diawali dengan penjelasan mengenai latar belakang masalah,

kemudian disambung dengan tujuan penelitian, metode penelitian dan sitematika

penulisan.

4

Bab 2 Pembahasan menjelaskan tentang sejarah perkembangan SSL, Fungsionality,

Mekanisme kerja, perbandingan antara SSL dengan TSL dan serangan pada SSL serta

pencegahannya.

Bab 3 Penutup berisi kesimpulan dan saran dari penelitian yang penulis lakukan.

5

BAB II

PEMBAHASAN

2.1. Sejarah Perkembangan SSL

Implementasi SSL paling pertama dikembangkan oleh Netscape Communications

Corporation pada awal tahun 1990-an untuk mengamankan HTTP, yang mengirmkan data

dalam bentuk plainteks melalui internet. Peluncuran resmi pertamanya adalah versi 2.0, di

mana saat itu diterima cukup luas, meskipun masih ada beberapa masalah desain pada

protokol. Pada akhir tahun 1990-an, semakin terlihat dengan jelas bahwa SSL 2.0 tidaklah

aman. Netscape memulai untuk membangun SSL 3.0.

Dengan bantuan Netscape, Internet Engineering Task Force (IETF, badan yang

mengatur untuk standar internet) memulai untuk menstandardisasi SSL, sebuah proyek

yang kemudian dikenal dengan nama TLS (Transport Layer Security). SSL 3.0 tidak

dikembangkan seteliti TLS, sehingga SSL 3.0 dapat dirilis lebih dahulu dan menggantikan

SSL 2.0 sebagai standar industri. TLS yang akhirnya diselesaikan pada tahun 2000,

menyediakan protokol terstandardisasi yang pertama untuk SSL. Walaupun SSL 3.0 masih

digunakan secara luas, untuk pengembangan terbaru termasuk sudah tertinggal karena saat

ini hampir semua browser modern mendukung TLS.

Gambar 2.1.Sejarah Perkembangan SSL

6

2.2. SSL Fungsionality

SSL adalah protokol keamanan yang didesain untuk dijalankan pada TCP/IP dan

dengan mudah dapat digantikan dengan API soket UNIX-style standar yang digunakan

oleh hampir semua perangkat lunak jaringan. Keamanan dijamin dengan menggunakan

kombinasi dari kiptografi kunci publik dan kriptografi kunci simetri bersamaan dengan

sebuah infrastruktur sertifikat.Sebuah sertifikat adalah sebuah kumpulan data identifikasi

dalam format yang telah distandardisasi . Data tersebut digunakan dalam proses verifikasi

identitas dari sebuah entitas (contohnya sebuah web server) pada internet. Sertifikat ini

secara digital ditandatangani oleh sebuah Certificate Authority (CA), yaitu sebuah entitas

yang dapat dipercaya yang diberikan kekuasaan untuk melakukan verfikasi sebuah

perusahaan atau individu yang ingin menyediakan aplikasi yang diamankan menggunakan

SSL.

Clientyang ingin berkomunikasi secara aman dengan entitas tersebut dapat melakukan

verifikasi identitasnya dengan menanyakannya pada basis data CA. Sebuah sertifikat juga

mengandung kunci publik dari pemiliknya. Kunci ini berpasangan dengan kunci privat

yang hanya diketahui oleh pemiliknya. Pasangan kunci ini digunakan untuk vaifikasi

identitas dari pemilik sertifikat, dan juga untuk membuat informasi rahasia dapat

dipertukarkan antara pemilik sertifikat dan entitas lainnya. SSL adalah protokol keamanan

yang digunakan pada hampir semua transaksi amanpada internet. SSL mengubah suatu

protokol transport seperti TCP menjadi sebuah saluran komunikasi aman yang cocok

untuk transaksi yang sensitif.

Protokol SSL mendefinisikan metode yang digunakan untuk membangun sebuah

saluran komunikasi yang aman dan tidak tergantung pada algoritma kriptografi mana yang

digunakan. SSL mendukung berbagai macam algoritma kriptografi, dan berlaku sebagai

sebuah framework di mana kriptografi dapat digunakan dengan cara yang tepat dan

terdistribusi. Penggunaan SSL sangat luas. Aplikasi yang membutuhkan pengiriman data

melalui sebuah jaringan yang tidak aman seperti internet atau intranet perusahaan adalah

salah satu aplikasi yang berpotensi untuk memanfaatkan SSL. SSL menyediakan

keamanan, dan yang lebih penting adalah ketenangan. Dengan menggunakan SSL, kita

dapat memastikan bahwa data kita aman dari pihak-pihak yang tidak berhak mengakses.

SSL didesain untuk dijalankan pada TCP/IP.

7

SSL menyediakan otentikasi (pada sisi client,dan opsional pada sisi server) terhadap

pihak-pihakyang berkomunikasi. SSL dapatmengamankan koneksi antara dua titik,

dantidak ada pihak yang dapat melakukan hal-halang bersifat destruktif atau

mengaksesinformasi yang bersifat sensitif.SSL menyediakan sebuah saluran

komunikasiyang aman tanpa perlu adanya pertemuankedua pihak yang berkomunikasi

untukmelakukan proses pertukaran kunci.

Para desainer SSL memutuskan untuk membuat protokol terpisah untuk menangani

masalah keamanan. Mereka menambahkan lapisan (layer) tambahan pada arsitektur

protokol Internet. Gambar 2.2sebelah kiri menunjukkan susunan lapisan protokol dalam

komunikasi Web. Gambar sebelah kanan menunjukkan penambahan lapisan SSL untuk

memperkokoh keamanan. Dengan bertindak sebagai lapisan baru, SSL tidak banyak

mengubah lapisan diatasnya dan dibawahnya. Interface aplikasi HTTP akan melihat SSL

sebagai suatu lapisan yang hampir sama dengan lapisan TCP. Demikian juga halnya

dengan lapisan TCP, ia akan melihat SSL sebagai suatu aplikasi lain yang menggunakan

layanannya.

Gambar 2.2. SSL merupakan lapisan terpisah dalam susunan protokol Internet

Selain hanya membutuhkan sedikit perubahan pada implementasi yang sudah ada,

pendekatan ini memiliki keuntungan lain: SSL mampu mendukung aplikasi lain selain

HTTP. Motivasi utama perancangan SSL adalah untuk meningkatkan keamanan Web,

namun pada Gambar 2.3, SSL dapat juga dipergunakan untuk menambahkan keamanan

pada aplikasi Internet lainnya seperti Net News Transfer Protocol (NNTP) dan

FileTransfer Protocol (FTP).

8

Gambar 2.3. SSL juga dapat menangani keamanan aplikasi lain

Fungsi SSL pada komunikasi aman samaseperti fungsi TCP pada komunikasi

normal,yaitu menyediakan sebuah infrastrukturkomunikasi standar di mana sebuah

aplikasidapat menggunakannya dengan mudah danhampir tidak dapat terlihat (invisible).

SSL menyediakan sebuah komponen pentingpada sistem yang aman. Mekanisme

otentikasidasar seperti password Telnet dan otentikasiHTTP dasar menjadi sangat kuat

ketikadieksekusi dengan SSL dibandingkan denganTCP, di mana pada SSL password tidak

lagidikirim dalam bentuk plainteks. SSLmengenkripsi koneksi, bukan data pada

keduapihak yang berkomunikasi, dan tidakmengandung mekanisme untukotentikasi

userataupun perlindungan password (hanyakoneksi yang diotentikasi, keamanannya

akangagal jika mesin pada kedua pihak yangberkomunikasi compromised).

Gambar 2.4. Letak SSL dalam model ISO Reference

9

Transmission Control Protocol/Internet Protocol (TCP/IP) mengatur transportasi dan

pembentukan rute data di Internet. Protokol lain, seperti HyperText Transport Protocol

(HTTP), Lightweight Directory Access Protocol (LDAP), atau Internet Messaging Access

Protocol (IMAP), berjalan ‘diatas’ TCP/IP. Seluruh protokol tersebut menggunakan

TCP/IP untuk mendukung aplikasi tipikal seperti menampilkan halaman web atau

menjalankan server e-mail.

Protokol SSL berjalan diatas TCP/IP dan dibawah protokol-level-atas seperti HTTP

atau IMAP. Ia menggunakan TCP/IP atas nama protokol-level-atas, dan dalam prosesnya

memungkinkan sebuah SSL-enabled server untuk mengautentikasi dirinya sendiri kepada

SSL-enabled client, serta memungkinkan client untuk mengautentikasi dirinya sendiri

kepada server, dan memungkinkan kedua mesin untuk membangun sebuah koneksi

terenkripsi.

Hal diatas berimplikasi terhadap munculnya komponen fundamental dalam

komunikasi di Internet dan di jaringan yang menggunakan TCP/IP.

1. Autentikasi server SSL

Memungkinkan seorang pengguna untuk memastikan identitas server. Software

SSLenabled client dapat menggunakan teknik standar public-key cryptography untuk

memeriksa keabsahan sertifikat server dan public ID yang dikeluarkan oleh Certificate

Authority (CA). CA ini harus ada dalam daftar CA yang dipercayai oleh client. Konfirmasi

ini bisa menjadi sangat penting jika, misalnya, mengirimkan sebuah nomor kartu kredit

melalui jaringan dan ingin memastikan identitas server penerima nomor tersebut.

2. Autentikasi client SSL

Memungkinkan sebuah server untuk memastikan identitas pengguna. Dengan

menggunakan teknik yang sama seperti yang digunakan pada autentikasi server, software

SSL pada server dapat memeriksa keabsahan sertifikat client dan public ID. Peran CA

dalam hal ini sama seperti yang telah disebutkan sebelumnya. Konfirmasi ini bisa menjadi

sangat penting bagi server jika, misalnya, server tersebut adalah sebuah bank yang akan

mengirimkan informasi finansial rahasia kepada pelanggannya. Pemeriksaan indentitas

penerima, dalam hal ini sangat penting.

10

3. Enkripsi koneksi SSL

Membutuhkan kondisi dimana semua informasi yang dikirimkan antara client dan

server dienkripsikan/didekripsikan oleh kedua belah pihak. Hal ini menyediakan tingkat

kerahasiaan yang tinggi. Kerahasiaan merupakan hal penting bagi kedua pihak yang akan

melakukan komunikasi pribadi. Sebagai tambahan, semua data yang dikirimkan melalui

koneksi SSL dilindungi oleh mekanisme yang akan mendeteksi tampering, yaitu

kemampuan untuk mendeteksi apakah data tersebut diubah selama dalam perjalanan.

2.3. Mekanisme Kerja SSL

Walaupun SSL sederhana pada teorinya (kunci dipertukarkan menggunakan

kriptografi kunci publik, dan komunikasi dilakukan dengan menggunakan kriptografi kunci

simetri), namun cukup kompleks pada implementasi aktualnya. Berikut ini beberapa detail

dalam membangun sebuah koneksi SSL dan berkomunikasi menggunakan koneksi

tersebut:

2.3.1. Alert

Error pada SSL disebut juga Alert. Salah satu komponen terpenting dalam SSL adalah

system penanganan errornya. Alert biasa juga diartikan sebagai serangan karena error itu

bisa mempengaruhi system kerja. Alert ini berupa pesan-pesan error yang dikirim melalui

komunikasi SSL Apabila pada perusahaan ini tidak ada system keamanan maka akan

dengan mudah serangan-serangan itu akan masuk ke data. Makanya di berikan teknologi

SSL. Spesifikasi SSL menjelaskan secara detail tentang jenis 20 alert yang berbeda dan

SSL juga bisa mendeteksi bagaimana menanganinya ketika alert tersebut diterima, serta

kapan waktu yang tepat untuk membangkitkan dan mengirimkannya.

2.3.2. Handsake

Komunikasi SSL diadakan pada sebuah SSL session. SSL ini dibangun menggunakan

sebuah proses handshake yang mirip dengan TSP 3-way handshake. Keseluruhan proses

handshake, termasuk pembangunan soket pada TCP/IP.

11

Gambar 2.5. Proses SSL Handsake

Seperti yang dapat dilihat pada gambar, koneksi TCP/IP dibangun terlebih dahulu,

kemudian proses handshake SSL dimulai. Session SSL dimulai ketika client dan server

berkomunikasi menggunakan parameter dan cipher yang telah dinegosiasikan. Session SSL

diakhiri ketika kedua pihak selesai.

2.3.2.1. Client Hello dan operasi kunci publik

Semua session pada SSL dimulai dengan sebuah pesan Client Hello. Pesan ini

dikirim oleh client kepada server yang ingin dituju untuk berkomunikasi. Pesan ini

berisi versi SSL dari client, sebuah bilangan acak yang akan digunakan selanjutnya

pada penurunan kunci, dan juga sebuah kumpulan ciphersuite offer.

Offerini merupakan penanda yang menunjukkan cipher dan algoritma hashyang

ingin digunakan oleh client. Pada saat membangun koneksi inisial, server memilih

sebuah offer yang ingin digunakan, dan menyampaikan kembali offer tersebut kepada

client bersama dengan certificate dan sebuah bilangan acak yang dimilikinya. Client

kemudian melakukan verifikasi server menggunakan sertifikat dan mengekstraksi

kunci public server.

Dengan menggunakan kunci publik, client mengenkripsi rahasia premaster,

sebuah nilai acak yang akan digunakan untuk membangkitkan kunci simetri, dan

12

mengirim pesan terenkripsi tersebut kepada server, yang kemudian mendekripsi pesan

menggunakan kunci privatnya.

2.3.2.2. Penurunan kunci simetri

Setelah server menerima rahasia premaster dari client, server dan client sama-

sama membangkitkan kunci simetri yang sama menggunakan rahasia premaster dan

juga membangkitkan bilangan acak yang telah dipertukarkan sebelumnya

menggunakan TLS pseudorandom function (PRF), yang mengekspansi rahasia dan

beberapa data menjadi sebuah blok dengab panjang tertentu.

Dengan cara ini, yang hanya mengenkripsi rahasia premaster kecil menggunakan

kriptografi kunci publik, membatasi kemungkinan mahalnya operasi pada performansi.

2.3.2.3. Finish handshake

Segera setelah kunci dibangkitkan, client dan server bertukar pesan-pesan

“change cipher spec” untuk mengindikasikan bahwa mereka telah memiliki kunci

simetri dan komunikasi selanjutnya dapat dilaksanakan menggunakan algoritma

simetri yang dipilik pada tahap inisial proses handshake.

Pada tahap ini, server dan client menggunakan semua pesan-pesan handshake

yang diterima dan dikirim, dan membangkitkan sebuah blok data yang digunakan

untuk melakukan verifikasi bahwa handshake tidak terganggu. Data ini, yang

dibangkitkan menggunakan TLS PRF, dikirimkan pada pesan handshake terakhir

disebut Finish.

Jika data pada pesan finish yang dibangkitkan tidak cocok dengan data finish

yang dibangkitkan secara lokal, maka akan koneksi diterminasi oleh pihak manapun

yang gagal melakukan tes verifikasi.

2.3.3. Session

Ketika sebuah proses handshake selesai, client dan server mulai berkomunikasi

dengan menggunakan saluran komunikasi aman yang baru. Setiap pesan di-hash,

dienkripsi dan kemudian dikirim.

13

Setiap kali ada kegagalan, baik itu pada proses dekripsi, enkripsi, hash, verifikasi, atau

komunikasi, SSL alert akan dikirimkan (menggunakan enkripsi kunci simetri) oleh entitas

yang mengalami kegagalan. Kebanyakan alert bersifat fatal, dan menyebabkan komunikasi

harus dihentikan sesegera mungkin.

2.3.4. Mengakhiri Session

Ketika client atau server selesai berkomunikasi, sebuah alert khusus, close_notify,

dikirimkan untuk memastikan semua komunikasi telah dihentikan dan koneksi dapat

ditutup.

Alert ini digunakan untuk mencegah pihak yang tidak bertanggung jawab melakukan

sebuah serangan pemotongan, yang akan menipu server atau client agar berpikir bahwa

semua data yang ingin dipertukarkan telah berhasil terkirim, padahal sebenarnya masih ada

data yang masih belum terkirim (hal ini dapat menjadi masalah pada situasi seperti

transaksi perbankan, di mana semua informasi harus terkirim).

Secara umum, cara kerja protokol SSL adalah sebagai berikut (Gambar 2.6):

1. Klien membuka suatu halaman yang mendukungprotokol SSL, biasanya diawali

dengan https://pada browsernya.

2. Kemudian webserver mengirimkan kuncipubliknya beserta dengan sertifikat server.

3. Browser melakukan pemeriksaan : apakahsertifikat tersebut dikeluarkan oleh CA

(CertificateAuthority) yang terpercaya? Apakah sertifikattersebut masih valid dan

memang berhubungandengan alamat situs yang sedang dikunjungi?

4. Setelah diyakini kebenaran dari webservertersebut, kemudian browser menggunakan

kuncipublic dari webserver untuk melakukan enkripsiterhadap suatu kunci simetri

yang dibangkitkansecara random dari pihak klien. Kunci yangdienkripsi ini kemudian

dikirimkan ke webserveruntuk digunakan sebagai kunci untuk mengenkripsialamat

URL (Uniform Resource Locator) dan datahttp lain yang diperlukan.

5. Webserver melakukan dekripsi terhadap enkrispidari klien tadi, menggunakan kunci

privat server.Server kemudian menggunakan kunci simetri dariklien tersebut untuk

mendekripsi URL dan datahttp yang akan diperlukan klien.

6. Server mengirimkan kembali halaman dokumenHTML yang diminta klien dan data

http yangterenkripsi dengan kunci simetri tadi.

14

7. Browser melakukan dekripsi data http dandokumen HTML menggunakan kunci

simteri tadidan menampilkan informasi yang diminta.

Gambar 2.6. Prinsip Kerja SSL

2.4. Sertifikat SSL

Sertifikat SSL memastikan data transaksi yang terjadi secara online di enkripsi/acak

sehingga tidak dapat dibaca oleh pihak lain.

1. Apa kegunaan sertifikat SSL?

Kegunaan utamanya adalah untuk menjaga keamanan dan kerahasiaan data ketika

melakukan transaksi. SSL memberikan jaminan keamanan pada pemilik dan pengunjung

situs atas data yang dikirim lewat web. SSL yang sering digunakan dapat dilihat pada situs

perbankan untuk melakukan transaksi e-banking.

2. Jenis SSL yang mana yang paling aman?

Tingkat keamanan SSL terletak pada kekuatan enkripsi yang didukungnya (misalnya

256 bit). Semakin besar tingkat enkripsi semakin susah untuk dibobol. Secara teknis,

semua SSL dengan tingkat enkripsi yang sama, mempunyai tingkat keamanan yang sama.

15

3. Bagaimana mengetahui transaksi diamankan SSL?

Sebuah icon berlambangkan gembok yang terkunci akan muncul di browser yang

telah diamankan dengan SSL. Dengan meng-klik icon tersebut akan diketahui otoritas

sertifikasi dari sertifikat SSL tersebut.

Gambar 2.7. Icon berlambang gembok terkunci pada Internet Explorer

4. Apa tanda situs yang tidak menggunakan sertifikat SSL?

Umumnya situs yang tidak menggunakan sertifikasi SSL dapat diketahui ketika

membuka halaman web situs tersebut misalnya terdapat “Certificate Error: Navigation

Blocked” pada browser Internet Explorer atau “This Connection is Untrusted” pada

browser Mozilla Firefox.

Bagipengunjung situs yang tidak memiliki sertifikat SSL, dianjurkan untuk tidak

melakukan transaksi secara online atau melanjutkan membuka situs tersebut dengan meng-

klik link “Continue to this website (not recommended)”.

Gambar 2.8. Certificate Error pada Internet Explorer

16

Sebagai contoh, sejak pertengahan April 2010 situs Kementerian Pertanian yang telah

menggunakan sertifikat SSL adalah situs webmail Kementerian Pertanian dengan alamat

URL http://mail.deptan.go.id atau https://exchange2k7fe.deptan.go.id. Dengan adanya

sertifikat SSL di situs Webmail Kementerian Pertanian, maka data yang terdapat pada

email telah diproteksi sehingga aman untuk digunakan dalam bertransaksi secara online.

2.5. SSL dan TSL

SSL merupakan protokol keamanan yang terkenal danbanyak digunakan, namun SSL

bukan satu-satunyaprotokol yang ada untuk keamanan transaksi web. Salahsatu protokol

yang juga penting dan menjadi pengganti dariSSL adalah TLS.

TLS (Transport Layer Security) adalah protocol keamanan dari IETF (Internet

Engineering Task Force)sebagai pengganti untuk protokol SSL v3.0 yangdikembangkan

oleh Netscape. TSL didefinisikan di dalamsuatu Request for Comment, yaitu pada

RFC2246. Banyakprotokol pada layer aplikasi yang menggunakan TLSuntuk menciptakan

koneksi yang aman, antara lain HTTP, IMAP, POP3, dan SMTPProtokol TSL ini dibangun

oleh dua layer:

1. Protokol TLS record, digunakan untuk melindungikerahasian dengan menggunakan

enkripi algoritmakunci simetri

2. Protokol TLS handshake, yang melakukanautentikasi antara server dan klien dan

melakukannegosiasi terhadap algorima enrkripsi dan kincikriptografi yang akan

digunakan di dalam transaksisebelum protokol aplikasi mengirimkan ataumenerima

data.

Prinsip kerja protokol TSL adalah sebagai berikut:

1. Pertama-tama, protokol TLS handshake melakukanpertukaran kunci dapat

menggukaan algoritma kunciasimetrik, seperti RSA atau Diffie-Hellman antara

kliendan server.

2. Kemudian protokol TLS record membukasaluran yang terenkripsi menggunakan

algoritma kuncisimetrik seperti RC4, IDEA, DES, atau Triple-DESsehingga informasi

dapat dikirimkan dengan aman.Selain itu, protokol TLS record juga

bertanggungjawab untuk memastikan bahwa komunikasi antara kliendan server tidak

17

berubah di tengah jalan, oleh karena itudigunakan juga fungsi hash, seperti MD5 dan

SHA.

2.6. Celah Keamanan pada SSL

Celah keamanan yang paling umum untuk SSL datang dari empat area: certificate

distribution, authentication, failure handling, dan dari lower-layer protocols.

2.6.1. Certificate Distribution

SSL bergantung pada sertifikat yang di-shared. Jika sertifikat tidak dipertukarkan cara

yang aman, dapat dicuri dan dimanipulasi oleh attacker. Sebagai contoh, banyak

perusahaan menggunakan email untuk mengirim sertifikat client-side kepada pengguna.

Seorang penyerang yang mengakses email tersebut dapat menggunakan sertifikat client-

side. Biasanya server CA (Certificate Authority) menghasilkan sertifikat untuk digunakan

pada server SSL, namun banyak server SSL menghasilkan sertifikat publik dan privatuntuk

digunakan dengan klien, yang memungkinkan pengguna untuk meng-host private-key

mereka. Akibatnya, inisial sertifikat client-side mungkin tidak terlindungi (atau hanya

dilindungi oleh password).

2.6.2. Self-Certification

Sertifikat X.509 menentukan server CA. Seorang penyerang menjalankan server SSL

dapat menggenerate sertifikat yang mengarah ke server CA. Dalam situasi ini, sertifikat

tersebut valid, namun server CA tidak dapat dipercaya. Untuk mengurangi risiko ini,

banyak aplikasi (termasuk browser Web) mempertahankan daftar server CA terpercaya.

Setiap server CA yang tidak ada dalam daftar memerlukan pertimbangan khusu/ditolak.

2.6.3. Absent Client Certificate

Sertifikat client-side tidak selalu digunakan. Jika server menyimpan informasi sensitif

yang dibutuhkan oleh klien, maka server harus dikonfirmasi. Jika klien SSL menyimpan

informasi yang digunakan oleh server SSL, maka client juga harus disertifikasi.

Sayangnya, lingkungan SSL tidak menerapkan client-side sertifikat. Sebaliknya,

mengotentikasi lapisan OSI aplikasi klien. Keamanan SSL ini tidak meluas ke lapisan OSI

18

yang lebih tinggi. SSL (tanpa sertifikat client-side) melindungi pengiriman data pada

application-layer tetapi tidak melindungi terhadap serangan lapisan server aplikasi.

2.6.4. Automated Systems

SSL umumnya digunakan untuk komunikasi antar sistem secara otomatis. Termasuk

web tools, backup dan restore system dan fasilitas login yang aman. Meskipun SSL tidak

menyediakan komunikasi yang aman ketika bekerja, automated systems banyak yangtidak

bisamengetahui saat SSL gagal. Misalnya, jika sertifikat SSL tidak valid, automated

systems dapat tetap digunakan. Banyak sistem SSL otomatis tidak memeriksa sertifikat

yang sudah kadaluarsa atau melakukan pencocokan sertifikat (potensial terjadi pencurian

sertifikat).

2.6.5. Human Error

Beberapa serangan, seperti MITM dilakukan dengan memanfaatkan kemalasan

pengguna untuk langsung menggunakan https. Pengguna yang malas memilih untuk

menggunakan http biasa dan berharap di-redirect ke url https otomatis atau menemukan

link ke url https. Padahal pada saat pengguna menggunakan http biasa itulah pengguna

berpotensi terkena serangan MITM. Bila pengguna langsung menggunakan https, maka

pengguna akan aman dan terbebas dari serangan MITM.

2.6.6. Lower-Layer Protocols

Celah keamanan dari lower-layers dapat berpengaruh pada efektifitas SSL. Gaya

serangan ini biasanya menghasilkan peringatan kepada pengguna, seperti server CA

unauthenticated atau sertifikat tidak valid.

2.7. Serangan Pada SSL

2.7.1. Man in the Middle (MITM) Attack

Https (http over SSL) sebenarnya adalah protokol yang sangat aman, protokol ini

menjamin keamanan data dari browser hingga web server. MITM attack (man in the

middle) tidak bisa dilakukan terhadap https karena https memiliki fitur authentication

sehingga attacker tidak bisa menyamar sebagai web server. Walaupun MITM attack tidak

bisa dilakukan terhadap https, namun attacker tetap bisa menyerang user yang

19

menggunakan http sebagai pintu masuk menuju https. Dengan menggunakan SSLStrip

(http://www.thoughtcrime.org/software/sslstrip/index.html), sebuah tool yang dibuat oleh

Moxie Marlinspike untuk melakukan serangan MITM terhadap pengguna situs yang

dilindungi dengan https.

2.7.1.1. Mekanisme Serangan

SSL is not vulnerable to MITM attack

MITM attack adalah serangan dimana attacker berada di tengah bebas

mendengarkan dan mengubah percakapan antara dua pihak. Jadi dengan serangan

MITM ini attacker tidak hanya pasif mendengarkan, tetapi juga aktif mengubah

komunikasi yang terjadi. Sebagai contoh, pada percakapan antara Rudi dan Bobby,

Charlie menjadi pihak yang ditengah melakukan MITM attack. Charlie tidak hanya

bisa mendengarkan percakapan itu, namun juga bisa mengubah percakapannya. Ketika

Rudi berkata “Besok makan siang jam 7″, Charlie bisa mengubahnya menjadi “Besok

makan siang dibatalkan” sehingga Bobby mengira makan siang dengan Rudi tidak

jadi.

Kenapa MITM attack bisa terjadi? MITM attack bisa terjadi karena sebelum

berkomunikasi kedua pihak tidak melakukan authentication. Authentication berguna

untuk memastikan identitas pihak yang berkomunikasi, apakah saya sedang berbicara

dengan orang yang benar, atau orang ke-3 (the person in the middle)? Tanpa

authenticationRudi akan mengira sedang berbicara dengan Bobby, sedangkan Bobby

juga mengira sedang berbicara dengan Rudi, padahal bisa jadi sebenarnya Rudi sedang

berbicara dengan Charlie dan Bobby juga sedang berbicara dengan Charlie, sehingga

Charlie bertindak sebagai “the person in the middle”. Seharusnya sebelum Rudi dan

Bobby berbicara, harus ada authentication, untuk memastikan “Who are you speaking

with?”. Rudi harus memastikan “Are you really Bobby? Prove it!”, sedangkan Bobby

juga harus memastikan “Are you really Rudi? Prove it!”.

SSL adalah protokol yang memiliki tingkat keamanan sangat tinggi. SSL tidak

hanya mengatur tentang enkripsi, namun juga mengatur tentang authentication

sehingga SSL tidak rentan terhadap serangan man in the middle. SSL menggunakan

sertifikat yang memanfaatkan kunci publik dan kunci private sebagai cara untuk

20

melakukan authentication. Dengan menggunakan sertifikat SSL ini, pengunjung web

bisa yakin sedang berkomunikasi dengan web server yang benar, bukan attacker in the

middle yang menyamar menjadi web server suatu situs.

Attacker yang mencoba menjadi “the person in the middle”, akan dengan mudah

ketahuan karena attacker tidak bisa membuktikan identitasnya dengan sertifikat SSL

yang sah. Sertifikat SSL yang sah haruslah ditandatangani oleh CA (certificate

authority) yang dipercaya dan tersimpan dalam daftar trusted CA browser. Jadi bila

attacker mencoba membuat sertifikat SSL sendiri, browser akan memberi peringatan

keras pada pengunjung bahwa sertifikat SSL tidak bisa dipercaya dan pengunjung

disarankan untuk membatalkan kunjungan karena beresiko terkena serangan MITM.

Serangan MITM attack baru bisa berhasil bila pengunjung tetap bandel dan nekat

untuk menggunakan sertifikat palsu tersebut. Bila ini yang terjadi, maka kesalahan ada

pada pengguna, bukan kelemahan SSL sebagai protokol.

HTTPS vs HTTP, Terpercaya dan Tidak

Http adalah protokol yang tidak bisa dipercaya karena rentan terhadap serangan

MITM. Sedangan http over SSL (https) adalah protokol yang bisa dipercaya karena

protokol ini tidak rentan terhadap serangan MITM. Informasi yang dilihat pengunjung

pada browser di sebuah page http sebenarnya tidak bisa dipercaya karena tidak ada

jaminan integritas dan keontentikan data. Informasi tersebut kemungkinan sudah

diubah di tengah jalan atau berasal dari sumber yang tidak otentik (orang lain). dan

pengunjung tidak bisa melakukan verifikasi.

Sedangkan informasi yang dilihat pengunjung pada browser di sebuah halaman

https bisa dipercaya karena DIJAMIN informasi yang diterima adalah sama dengan

yang dikirim web server dan informasi tersebut juga DIJAMIN dikirim oleh web

server yang benar.

HTTP sebagai gerbang HTTPS

Jarang sekali orang mengunjungi situs dengan mengetikkan https:// bahkan http://

pun orang sudah malas. Kebanyakan orang langsung mengetikkan alamat situs yang

ditujunya tanpa harus diawali dengan http:// atau https://. Secara default browser akan

21

berasumsi bahwa pengunjung akan menggunakan protokol http, bukan https bila

pengunjung tidak menyebutkan protokolnya.

Kebanyakan situs yang harus memakai https, memang dirancang untuk menerima

request melalui http (port 80) atau https (port 443). Situs pada port 80 biasanya hanya

dijadikan jembatan untuk menuju situs yang sebenarnya pada port 443. Bila

pengunjung masuk melalui port 80, maka server akan memberikan link untuk menuju

URL https, atau dengan memberikan response Redirect.

Gambar 2.9. Proses Komunikasi HTTPS

Jadi bisa disimpulkan bahwa sebagian besar pengunjung memasuki https dengan

melalui http, dengan kata lain http sebagai gerbang menuju https. Metode peralihan

dari situs http ke situs https ada beberapa cara, yaitu:

Memberikan link menuju URL https.

Memberikan response redirect ke URL https.

Menggunakan META tag auto refresh ke URL https.

Menggunakan javascript untuk load halaman https.

Menyerang HTTP, bukan HTTPS

Sebelumnya sudah saya jelaskan bahwa https adalah protokol yang sangat secure

sehingga tidak bisa diserang dengan serangan MITM. Namun mengingat kenyataan

bahwa kebanyakan orang mengakses https melalui http, maka attacker memiliki

peluang untuk menyerang ketika pengunjung masih berada dalam protokol http.

22

Gambar 2.10. Pembajakan Komunikasi HTTPS

SSLStrip adalah tool untuk melakukan MITM attack pada protokol http (bukan

HTTPS), dengan maksud untuk menyerang situs-situs yang dilindungi dengan https.

SSLStrip sebagai “the person in the middle”, akan mencegah peralihan dari http ke

https dengan secara aktif mengubah response dari server sehingga pengunjung akan

tetap berada dalam protokol http.

Mari kita lihat beberapa cara peralihan dari http ke https, saya tambahkan cara

SSLStrip mencegah peralihan itu:

Memberikan link menuju URL https: SSLStrip akan mengubah link berawalan

https menjadi http. Sehingga yang muncul di browser korban bukan link ke https

melainkan link ke http.

Memberikan response redirect ke URL https: SSLStrip akan mengubah header

Location dari URL berawalan https menjadi http.

Menggunakan META tag auto refresh ke URL https: SSLStrip akan mengubah

url https menjadi http.

Menggunakan javascript untuk load halaman https: SSLStrip akan mengubah url

https menjadi http.

Untuk lebih jelasnya berikut adalah gambar yang menunjukkan salah satu cara

kerja SSLStrip mencegah korban beralih dari http ke https.

Gambar 2.11. Opening Bank Front Page

23

Pada gambar di atas korban mengakses web server bank dengan URL

http://bank/. Request tidak secara langsung dikirim ke web server, namun melalui

SSLStrip dulu. SSLStrip meneruskan request tersebut ke web server. Kemudian web

server menjawab dengan memberikan html berisi link ke URL https://bank/login/

kepada SSLStrip. Sebelum response html diterima oleh browser, SSLStrip mengubah

response tersebut dengan mengubah URL https menjadi http biasa sehingga HTML

yang diterima di browser korban berisi link ke URL http://bank/login/ bukan

https://bank/login/.

Gambar 2.12. Opening login page

Korban mengklik link pada halaman yang muncul browsernya, tentu saja link ini

bukan ke https://bank/login/ melainkan ke http://bank/login/. Dengan cara ini browser

tetap dalam protokol http bukan dalam protokol https seperti seharusnya, dengan kata

lain SSLStrip berhasil mencegah browser beralih ke protokol https. Request ke

http://bank/login/ tersebut dikirimkan ke SSLStrip. Kemudian SSLStrip tidak

meneruskan request tersebut ke http://bank/login/, melainkan membuat request baru ke

https://bank/login/. Kemudian web server mengirimkan response dari response

tersebut ke SSLStrip.

Seperti biasanya SSLStrip akan mengubah response dari server tersebut untuk

mencegah peralihan ke https. Response yang telah diubah ini kemudian dikirimkan ke

browser korban sehingga korban tetap melihat halaman yang sama persis seperti

ketika dia membuka https://bank/login/. Dengan tampilan yang sama persis ini, korban

mengira sedang membuka https://bank/login/, padahal sebenarnya dia sedang

24

membuka http://bank/login/. Perhatikan bahwa koneksi antara browser dengan

SSLStrip adalah dalam http biasa, sedangkan dari SSLStrip ke web server dalam https.

Gambar 2.13. Submit Username and Password

Setelah muncul halaman login dan korban mengira sedang membuka

https://bank/login, kemudian korban memasukkan username dan password dan

mengklik tombol Login. Browser akan membuat POST request ke http://bank/login/

yang diterima oleh SSLStrip. Karena protokolnya adalah http, maka SSLStrip dengan

mudah bisa membaca username dan password yang dimasukkan korban. SSLStrip

kemudian akan mengirimkan username dan password korban degan POST request ke

https://bank/login/. Seperti biasa jawaban dari webserver akan dimodifikasi dulu

seperlunya oleh SSLStrip sebelum dikirimkan ke browser korban.

Perhatikan bahwa korban sejak awal hingga login mengakses situs dengan http,

sedangkan SSLStrip di tengah-tengah membuat koneksi https ke web server yang

sebenarnya. Jadi walaupun browser mengakses dengan http, namun response yang

diterima browser berasal dari koneksi https yang dibuat oleh SSLStrip.

2.7.1.2. Studi Kasus: Mandiri Internet Banking

Mari kita coba trik di atas dengan contoh kasus pada situs internet banking

Mandiri. Karena ini hanya contoh, saya tidak menggunakan teknik ARP Spoofing

untuk melakukan MITM attack yang sesungguhnya. Saya sengaja mengubah setting

browser saya agar menggunakan proxy, yaitu SSLStrip. Dalam website SSLStrip,

disebutkan seharusnya cara untuk melakukan MITM attack dengan SSLStrip adalah:

25

Setting komputer agar bisa melakukan forwarding paket

Setting iptables untuk mengarahkan traffic HTTP ke SSLStrip

Jalankan SSLStrip

Gunakan ARPSpoof untuk meyakinkan jaringan bahwa traffic harus dikirimkan

melalui komputer yang menjalankan SSLStrip.

Dalam contoh ini saya tidak melakukan ARPSpoofing, namun saya

menggunakan SSLStrip sebagai proxy yang saya setting dalam browser saya.

Sehingga setiap traffic http yang dilakukan browser saya akan dikirimkan melalui

SSLStrip sebagai man in the middle.

Saya menjalankan SSLStrip di linux dengan IP address 192.168.0.10. Cara

menjalankannya mudah sekali, cukup jalankan perintah: python sslstrip.py -l

portnumber . Kemudian pada browser saya setting untuk menggunakan proxy

192.168.0.10 dan port sesuai dengan port sslstrip. Untuk lebih jelasnya, perhatikan

gambar di bawah ini:

Gambar 2.14.Setting up SSLStrip as proxy in IE

Setelah semuanya siap, mari kita coba melakukan serangan MITM. Pada

skenario ini, korban akan login ke Mandiri IB tidak dengan mengetikkan

https://ib.bankmandiri.co.id, karena korban hanya hafal bankmandiri.co.id saja maka

korban langsung mengetikkan bankmandiri.co.id (tanpa diawali www atau http://).

Secara default browser akan menganggap korban menghendaki koneksi dengan

protokol http, bukan https. Request http tersebut dikirimkan melalui SSLStrip sebagai

man in the middle, dan berikut adalah response yang diterima di browser korban.

26

Sebagai pembanding saya juga berikan gambar screenshot halaman depan bank

mandiri yang asli (tidak dimodifikasi SSLStrip).

Gambar 2.15.Bank Mandiri front page modified by sslstrip

Gambar 2.16. Real Mandiri front page (not modified)

Login ke Mandiri IB dilakukan dengan mengklik tombol Login di halaman

depan bank mandiri. Login tersebut sebenarnya adalah link ke URL https, namun

SSLStrip mengubahnya menjadi http agar korban tidak beralih ke modus https.

Berikutnya korban akan mengklik tombol Login, sehingga browser akan mengakses

URL http://ib.bankmandiri.co.id (bukan https://). Berikut adalah gambar screenshot

halaman login Mandiri IB yang telah dimodifikasi sslstrip dan yang masih asli. Kedua

gambar di bawah ini sangat mirip, perbedaannya hanya pada penggunaan awalan

27

http:// dan https://. Saya yakin kebanyakan orang tidak akan menyadari bahwa dia

sedang menggunakan http biasa, bukan https.

Gambar 2.17.Mandiri IB login page modified by sslstrip

Gambar 2.18. Real login page, https version and not modified

Berikutnya setelah bertemu dengan halaman login, korban akan dengan senang

hati memasukkan username dan password. Request tersebut dikirimkan dalam request

POST http (bukan https) ke sslstrip. Karena POST dikirim melalui http, maka sslstrip

bisa dengan mudah menyimpan username dan password korban.Berikut ini adalah log

dari sslstrip yang menangkap username dan password Mandiri IB.

28

Setelah itu sslstrip akan mengirimkan username dan password korban dalam

POST request ke URL https (ini adalah url submit yang asli). Response yang

diberikan oleh webserver Mandiri IB akan dimodifikasi seperlunya dan dikembalikan

ke browser korban. Bila login berhasil, maka korban akan melihat tampilan seperti

gambar dibawah ini, sebagai pembanding saya juga sertakan gambar bila

menggunakan protokol https.

Gambar 2.19. Login success page in http mode, modified by sslstrip

Gambar 2.20. Real login success page, https mode, not modified

Seperti pada halaman login, halaman setelah login berhasil juga sama persis

walaupun menggunakan protokol http. Korban tidak akan menyadari bahwa dia

sedang menggunakan http, bukannya https karena tampilannya memang tidak ada

bedanya.

2.7.1.3. Tips Pencegahan

Seperti telah dibahas sebelumnya, serangan SSL dengan cara ini hampir tidak

terdeteksi dari sisi server, karena server ‘menyangka’ hal ini hanyalah komunikasi

normal dengan klien. Untungnya, ada beberapa hal yang dapat dilakukan dari sisi

klien untuk mendeteksi dan mencegah serangan, antara lain:

29

1. Pastikan melakukan koneksi yang aman dengan HTTPS

Serangan MITM dengan SSLstrip ini dilakukan dengan memanfaatkan

kemalasan pengguna untuk langsung menggunakan https. Pengguna yang malas

memilih untuk menggunakan http biasa dan berharap di-redirect ke url https otomatis

atau menemukan link ke url https. Padahal pada saat pengguna menggunakan http

biasa itulah pengguna berpotensi terkena serangan MITM. Bila pengguna langsung

menggunakan https, maka pengguna akan aman dan terbebas dari serangan MITM.

Jadi mulai sekarang biasakanlah mengetikkan https:// di URL anda bila ingin

mengakses situs yang sensitif.

2. Sebaiknya jangan melakukan traksaksi online di tempat umum

Kemungkinan seseorang mencegat lalu lintas pada jaringan di rumah Anda jauh

lebih sedikit dibandingkan pada jaringan di kantor atau ditempat umum. Anda tidak

akan menyadari disekitar anda ternyata ada seseorang yang sedang meng-capture

paket jaringan, just be carefull.

3. Amankan perangkat jaringan internal Anda

Jika perangkat jaringan anda aman maka ada sedikit peluang bagi para attacker

untuk memasuki system Anda.

2.7.2. Sniffing SSL Traffic using oSpy

SSL menjamin confidentiality data dari endpoint ke endpoint, itu artinya di tengah

jalan tidak ada pihak ke-3 yang bisa menyadap data yang dikirimkan. Nah, kalau di tengah

jalan tidak bisa disniff, bagaimana dengan sniffing di salah satu endpoint, baik di komputer

klien atau server? Itulah yang akan saya tunjukkan dalam artikel ini.

2.7.2.1. Mekanisme Serangan

SSL: The Secure Tunnel for All

SSL adalah protokol yang menjamin confidentiality dan authentication

komunikasi dari satu titik awal ke titik akhir. Data apapun yang dilewatkan melalui

SSL dijamin aman dari pengintip di tengah jalan karena semua data dikirim dalam

30

keadaan terenkripsi. Karena itu SSL sering dijadikan terowongan (tunnel) untuk

membuat protokol lain yang tidak secure menjadi secure.

Contoh pemakaian SSL sebagai tunnel adalah pada https. Http sejatinya adalah

protokol clear text, artinya semua request dan response http yang lewat tidak

terenkripsi dan bisa disadap siapapun yang berminat. Namun untuk web tertentu yang

sensitif seperti bank memerlukan jaminan confidentiality, oleh karena itu protokol

Http ini dibungkus dan dilewatkan tunnel SSL, sehingga menjadi apa yang dikenal

sebagai https yaitu http tunneled over SSL. Masih banyak protokol lain yang bisa

dilewatkan tunnel SSL, antara lain IMAP, SMTP, POP, LDAP.

Sniffing at Endpoint

SSL memang menjamin keamanan sepanjang perjalanan dari titik asal menuju

titik tujuan. Data yang terkirim dari dan ke komputer klien/server dijamin

keamanannya karena terenkripsi. Kalau ada attacker yang mencoba mengintip data di

tengah perjalanan, data yang dia dapatkan adalah data yang terenkripsi, bukan plain-

text, sehingga tidak ada gunanya mengintip data yang dilindungi SSL.

Jaminan keamanan SSL hanya berlaku dari titik A ke titik B (end-to-end).

Pertama saya harus jelaskan dulu apa yang dimaksud dengan titik. Titik disini adalah

aplikasi atau program komputer yang berjalan di atas operating system, contohnya

adalah browser, instant messenger, outlook. Aplikasi ada yang berfungsi sebagai client

dan ada pula yang sebagai server.

Agar data yang dikirimkan aman, aplikasi tersebut harus melakukan enkripsi

data terlebih dahulu sebelum mengirimkan data ke tujuan. Begitu pula dari titik

penerima, data yang diterima harus dikenakan proses dekripsi agar bisa dimengerti dan

bisa diproses. Proses tersebut digambar seperti pada gambar berikut ini:

31

Gambar 2.21. Simplified SSL Data Flow

Pada gambar di atas, dicontohkan yang menjadi titik adalah browser sebagai

client dan web server sebagai server. Pada saat paket data diserahkan dari aplikasi ke

network adapter (ethernet, wifi adapter dsb), paket tersebut sudah dalam keadaan

terenkripsi. Jadi dalam aplikasi yang memakai SSL data yang dikirim dan diterima

dalam keadaan terenkripsi, namun justru dalam aplikasinya sendiri data masih dalam

keadaan tidak terenkripsi.

Data hanya aman ketika berada di luar rumah, justru di dalam rumah data tidak

terlindungi enkripsi. Karena data hanya aman ketika berada di luar rumah

(proses/aplikasi), maka ada peluang bagi aplikasi/proses lain yang memiliki hak akses

yang cukup untuk melakukan sniffing ketika data masih berada di dalam rumah. Salah

satu skenario attack yang mungkin adalah: dalam sistem operasi multi user seperti

linux dan windows, ada satu user yang dipakai beberapa orang. Dalam kondisi ini

ketika ada orang yang sedang browsing, maka orang lain dengan user yang sama bisa

mengintip isi rumah browser korban. Hal ini dimungkinkan karena kedua orang

tersebut login dengan user yang sama. Jadi walaupun korban sedang login

mengggunakan https (SSL) di browser tersebut, attacker tetap bisa melakukan sniffing

dengan cara masuk langsung ke dalam rumah proses browser korban.

2.7.2.2. Studi Kasus: Sniffing Google Talk SSL Traffic

Agar lebih jelasnya mari kita langsung praktek mencoba sniffing SSL google

talk di komputer yang sama. Sebelumnya anda harus sudah berhasil mendownload

oSpy (http://code.google.com/p/ospy/). Kemudian silahkan ekstrak dan jalankan file

oSpy.exe. Untuk dapat melakukan sniffing proses saya harus menginjeksi agen ke

32

dalam proses tersebut. Agen ini mirip dengan mata-mata yang disusupkan ke daerah

lawan agar saya bisa mendapatkan informasi segala sesuatu tentang lawan. Agen yang

disusupkan ke proses googletalk.exe ini akan memberikan saya informasi fungsi apa

saja yang dijalankan oleh sebuah proses.

Untuk menginjeksi agen, di dalam oSpy, klik menu Capture kemudian pilih

menu Inject Agent. Silakan pilih proses yang akan diintip, dalam contoh ini saya

memilih googletalk.exe. Setelah memilih proses, kemudian klik tombol Inject. Proses

injeksi agen diperlihatkan pada gambar di bawah ini.

Gambar 2.22. Injecting Agent

Setelah agen berhasil disusupkan ke sebuah proses, kini tiba saatnya untuk

mengantifkan modus mata-mata, caranya adalah dengan klik menu Capture, kemudian

pilih Start. Setelah itu saya coba login ke googletalk, kemudian saya klik Stop Capture

untuk melihat hasil capture. Mari kita lihat informasi apa saja yang dikirimkan oleh

agen yang saya susupkan ke daerah musuh.

Gambar 2.23. Captured Information

33

Dalam gambar di atas terlihat informasi yang dikirim oleh agen rahasia saya.

Google Talk menggunakan https untuk melakukan authentication. Walaupun

menggunakan https, namun agen rahasia saya mampu membaca paket http yang

dikirimkan ke google dan yang diterima dari google.

POST /accounts/ClientAuth HTTP/1.1Connection: Keep-AliveContent-Length: 171Content-Type: application/x-www-form-urlencodedHost: www.google.com:443User-Agent: Google Talk

Email=rizki.wicaksono%40gmail.com&Passwd=%74%65%73%74%69%6E%67%70%61%73%73%77%6F%72%64&PersistentCookie=false&source=googletalk&accountType=HOSTED_OR_GOOGLE&skipvpage=true

Request POST tersebut mengirimkan username dan password saya dalam bentuk

url encoded ke https://www.google.com. Namun karena username dan password salah,

maka response yang didapatkan adalah 403 Forbidden. Kalau password benar,

response status code adalah 200 OK.

Pada gambar tersebut juga terlihat bahwa sebelum googletalk mengirimkan data,

dia memanggil fungsi EncryptMessage() yang gunanya mengenkrip pesan yang akan

dikirim ke web server google. Begitu pula sebaliknya, data yang diterima dari web

server google diterima oleh fungsi recv() setelah itu diikuti dengan fungsi

DecryptMessage() yang gunanya mendekrip pesan yang diterima dari web server

google.

2.7.2.3. Kesimpulan

SSL adalah protokol yang sangat bagus karena bisa menjamin keamanan data

dari titik ke titik. Namun keamanan data di titik itu sendiri tidak bisa dijamin SSL

karena itu adalah domain dari keamanan sistem operasi. Dengan menggunakan oSpy

saya bisa mengintip komunikasi SSL yang dilakukan sebuah aplikasi/proses.

Komunikasi SSL tidak bisa diintip dengan menggunakan network sniffer seperti

wireshark (ethereal) walaupun sniffer dijalankan di komputer yang sama dengan

aplikasi. Kenapa network sniffer tidak berguna walau di komputer yang sama? Hal ini

karena sniffer bekerja di layer physical dengan mengubah network adapter ke modus

promiscious. Dalam gambar sebelumnya saya jelaskan bahwa data yang dikirimkan

melalui network layer (physical layer) adalah hasil dari fungsi EncryptData(), yang

34

artinya data tersebut sudah dalam bentuk terenkripsi, walaupun masih dalam satu

komputer yang sama.

Dalam aplikasi yang menggunakan SSL, data hanya aman ketika berada di luar

rumah (di luar process address space), sehingga data yang dikirim ke luar melalui

network adapter sudah dalam keadaan terenkripsi. Untuk dapat melakukan sniffing

SSL saya harus melakukan itu di dalam rumah (di dalam proses itu sendiri). Dalam

gambar sebelumnya saya menjelaskan bahwa sebelum memanggil fungsi send(),

proses memanggil fungsi EncryptData(). Fungsi inilah yang saya target karena fungsi

ini mengubah plaintext menjadi ciphertext, plaintext inilah yang dilaporkan kepada

saya oleh agen mata-mata saya (ospy).

Attack dengan oSpy ini akan efektif bila attacker telah mendapatkan akses penuh

di sebuah komputer. Untuk menyadap password internet banking pengguna, bila

keylogger tidak berguna karena user menggunakan virtual keyboard, bila FFSniff juga

tidak berguna karena user tidak memakai Firefox, maka oSpy akan sangat berguna.

35

BAB III

PENUTUP

Salah satu cara untuk meningkatkan keamanan web server adalah dengan

menggunakan enkripsi pada komunikasi terhadap tingkat socket. Dengan menggunakan

enkripsi, orang tidak bisa menyadap data-data (transaksi) yang dikirimkan dari client ke

web server. Dengan kata lain SSL (Secure Socket Layer)hanya mengamankan jalur

komunikasi (secure connection) transaksi yang terbungkus dan terenkripsi antara client dan

server.

Protokol SSL menyediakan sebuah framework untuk pertukaran kunci (key

exchanges), authentikasi dan enkripsi. Hal ini cukup fleksibel dan extendible,

memperbolehkan algoritma baru untuk ditambahkan tanpa mengganti session dan

implementasi application layer. SSL secara umum digunakan untuk men-tunnel protokol

yang insecure melalui sebuah koneksi jaringan yang secure.

Sayangnya, masalah sertifikasi SSL dapat membatasi keefektifan SSL. Celah

keamanan yang paling umum untuk SSL datang dari empat area: certificate distribution,

authentication, failure handling, dan dari lower-layer protocols.

Beberapa hal yang dapat dilakukan oleh user dalam mencegah aksi para Attacker,

khususnya Man in the middle attack (MITM) pada SSL antara lain dengan memastikan

penggunaan koneksi yang aman via HTTP over SSL (HTTPS), tidak melakukan transaksi

online ditempat umum serta melakukan pengamanan pada perangkat jaringan internal.

36

DAFTAR PUSTAKA

__________. 2010. Sertifikat SSL. http://www.deptan.go.id/

Fernando, Hary. 2010. Studi dan Implementasi Sistem Keamanan Berbasis Web dengan

Protokol SSL di Server Students Informatika ITB. Departemen Teknik Elektro, Program

Studi Teknik Elektronika, Institut Teknologi Bandung. Via http://budi.insan.co.id/

Madjid, Nurkholis. 2010. Perbandingan SSL (Secure Socket Layer) Dan IPSec (Internet

Protocol Security) Pada VPN (Virtual Private Network). Departemen Teknik Elektro,

Program Studi Teknik Elektronika, Institut Teknologi Bandung. Via http://budi.insan.co.id/

Rawetz, Neal. 2007. Introduction to Network Security. Charles River Media: Boston.

Sanders, Chris. 2010. Understanding ManInTheMiddle Attacks: SSL Hijacking.

http://www.windowsecurity.com/

Simalango, Indra Antonius. 2004. Perancangan Cryptoboard dengan

Mengimplementasikan OpenSSL-0.9.7 pada Single Board Computer. Departemen Teknik

Elektro, Program Studi Teknik Elektronika, Institut Teknologi Bandung. Via

http://budi.insan.co.id/

Sholeh, Muchammad. 2008. Keamanan Apache Web Server Dan Secure Socket Layer

(SSL). http://www.depkominfo.go.id/

Thomas, Stephen. 2000. SSL and TLS Essentials, Securing the Web. John Wiley & Sons:

New York.

Wicaksono, Rizki. 2009. MITM Attack on Mandiri Internet Banking using SSLStrip.

http://www.ilmuhacking.com/

Wicaksono, Rizki. 2009. Sniffing SSL Traffic using oSpy. http://www.ilmuhacking.com/