IMPLEMENTASI KEAMANAN
SECURE SOCKET LAYER (SSL) DAN TRANSPORT LAYER SECURITY (TLS)
TERHADAP ANCAMAN DALAM JARINGAN INTERNET
MAKALAH PENELITIAN
TUGAS MATA KULIAH MANAJEMEN BISNIS ICT
DOSEN : Dr. Ir. Iwan Krisnadi, M.B.A.
Oleh :
SIGIT HERMAWANTO
55417110020
PROGRAM PASCASARJANA TEKNIK ELEKTRO
UNIVERSITAS MERCU BUANA
JAKARTA
BAB I
PENDAHULUAN
1.1. Abstrak
Secure Socket Layer (SSL) merupakan salah satu protokol yang digunakan untuk browsing web secara aman. Banyak fitur yang disediakan pada SSL merupakan bentuk dari keamanan dalam browsing Internet. Paper ini menjelaskan mengenai keamanan yang disediakan oleh SSL untuk menciptakan web yang aman pada saat melakukan browsing. Penjelasan yang dilakukan meliputi fitur-fitur keamanan yang disertakan dalam setiap komponen pesan yang ada pada saat negosiasi pelayanan keamanan yang dibentuk antara client dan server. Selain itu dijelaskan pula mengenai isu–isu serangan yang memungkinkan ada pada Internet yang mampu diatasi oleh SSL, peluang penyerang melakukan serangan cukup mumpuni adalah SSL. 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. Secure Socket Layer (SSL) adalah protokol yang digunakan untuk browsing web secara aman. SSL bertindak sebagai protokol yang mengamankan komunikasi antara client dan server. Protokol ini memfasilitasi penggunaan enkripsi untuk data yang rahasia dan membantu menjamin integritas informasi yang dipertukarkan antara website dan web browser.
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.
Bab 2 Pembahasan menjelaskan tentang sejarah perkembangan SSL, Fungsionality, Mekanisme kerja, perbandingan antara SSL dengan TSL dan serangan pada SSL serta pencegahannya.
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.
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.
Client yang 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.
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
Gambar 2.3. SSL juga dapat menangani keamanan aplikasi lain
Fungsi SSL pada komunikasi aman sama seperti fungsi TCP pada komunikasi normal,yaitu menyediakan sebuah infrastruktur komunikasi standar di mana sebuah aplikasi dapat menggunakannya dengan mudah danhampir tidak dapat terlihat (invisible).
SSL menyediakan sebuah komponen penting pada sistem yang aman. Mekanisme otentikasi dasar seperti password Telnet dan otentikasi HTTP dasar menjadi sangat kuat ketikadieksekusi dengan SSL dibandingkan denganTCP, di mana pada SSL password tidak lagidikirim dalam bentuk plainteks. SSL mengenkripsi koneksi, bukan data pada keduapihak yang berkomunikasi, dan tidakmengandung mekanisme untukotentikasi
userataupun perlindungan password (hanyakoneksi yang diotentikasi, keamanannya akangagal jika mesin pada kedua pihak yang berkomunikasi compromised).
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 SSL
enabled 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
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
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.
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 dipilih 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
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.
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?
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 ter kunci 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)”.
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
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
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
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. 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
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
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
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.
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.
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
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
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)
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
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 pa ge 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
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
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.
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
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.
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.1
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 Encr yptMessage() yang gunanya mengenkrip pesan yang akan dikirim ke web server google. Begitu pula sebaliknya, data yang diterima dari web 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
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).
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.
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/
