Arsitektur web yang masih mengadopsi teknologi awal tahun 90-an kini menghambat kinerja browser generasi baru dan lebih mudah diserang. Teknologi baru akhirnya muncul dan mampu membuat web lebih cepat dan lebih aman.
Daniel Bernstein dan Jeff Hodges adalah penggerak revolusi. Yang mereka kerjakan sangat berarti bagi setiap orang yang ingin menggunakan Internet dengan aman dan cepat.
Mereka meneliti jalur web yang lama, seperti protokol TCP dan HTTP. Jalur alternatif temuan mereka akan menyingkirkan masalah terbesar dan membuat Internet siap untuk masa depan dengan web yang semakin interaktif.
Protokol lama menghambat kinerja web modern layaknya lubang di tengah jalan tol. Selain itu, hacker amat mudah memata-matai password atau mengendalikan browser dengan serangan cyber yang semakin canggih.
Bernstein, Hodges, dan rekan-rekannya kini berupaya mencapai tingkat keamanan yang lebih baik dan transfer data yang lebih cepat. Nama protokol yang baru adalah DNSCurve, CurveCP, HSTS, dan SPDY. Untuk hasil yang optimal, produsen browser dan pengelola web server harus mendukung teknologi baru tersebut.
Untuk memahami mengapa setiap pengguna akan menikmati revolusi ini, kita harus meneropong masalah-masalah protokol data aktual. Transfer data di web – komunikasi antara pengguna dan website berlangsung dalam tahapan yang telah ditetapkan dengan segala kelemahannya.
Sebuah ‘TCP-Handshake’ membangun koneksi ke website dan di sini CurveCP akan melindungi dari serangan. Selanjutnya, konten web akan ditransfer, ini akan diubah dengan HSTS.
Transfer melalui HTTP juga terbatas secara teknis. Di sini, Google ingin meningkatkan kecepatan dengan SPDY. Namun sebelum koneksi ke website terbangun, DNS harus menemukan alamat IP dari URL yang dimasukkan. DNSCurve bertugas mencegah hacker memanipulasi penerjemahan alamat ini.
DNSCurve: Tidak ada lagi phishing
Sebuah URL terdiri atas tiga bagian, yaitu protokol yang digunakan (http://), nama domain (www.yahoo), dan top-level-domain (.co.id). Jika URL dimasukkan ke dalam address bar di browser, browser akan menampilkan website yang dimaksud. Untuk itu, URL membutuhkan alamat IP website yang didapatkan dari server DNS.
Biasanya, server DNS menyampaikan IP Address tanpa enkripsi. Metode ini sangat berbahaya. Jika hacker mampu mengubah IP Address, Anda bisa diarahkan ke website phishing. Tujuannya adalah untuk mencuri data login Anda. Serangan yang disebut DNS-spoofing ini sangat berbahaya.
Upaya pertama mengamankan permintaan DNS adalah melalui DNSSEC (Domain Name System Security Extension) yang mulai digunakan pada tahun 2005 dan mengenkripsi informasi domain di server-server DNS. Namun, jalur paket DNS antara PC pengguna dan server DNS tetap tidak terenkripsi. Bagi para pakar TI, kondisi ini menunjukkan bahwa DNSSEC telah gagal.
Alternatif yang dikembangkan Daniel J. Bernstein dari University of Illinois adalah DNSCurve. Proses ini mengamankan transfer nama domain dan IP Address dengan mengenkripsi permintaan dan jawaban pada ujung-ujungnya, ya itu di dalam sistem operasi client DNS dan server DNS.
Bila Anda mengetikkan URL www.website.com, client DNS mengirimkannya ke server sebagai www.123456789.website.com. Angka-angka tersebut adalah Public Key. Hanya server DNS yang dapat mendekripsi permintaan itu karena hanya server itulah yang memiliki kunci pribadi (Private Key) yang dibutuhkan.
Pada jalur sebaliknya, server mengirimkan IP Address yang bersangkutan dengan metode enkripsi yang sama dan asal paket data juga diverifikasi. Hacker yang menyadap data yang ditransfer tidak dapat memanfaatkannya.
Banyak server DNS telah mendukung teknologi baru ini. Selain keamanan, DNSCurve juga memiliki kelebihan, yaitu tidak membutuhkan revolusi server dan hanya perlu meng-install sebuah software untuk menggunakannya. Pertanyaannya, kapan Windows mendukung teknologi ini dalam client DNS-nya?
CurveCP: Mengenkripsi dengan Curve
Curve CP mengenkripsi transfer data pada titik akhirnya. Dengan prinsip ini, Daniel Bernstein juga ingin merevolusi protokol transportasi. Protokol ini menghubungkan browser dengan website dan mengirimkan data dalam dalam bentuk paket. TCP yang selama ini digunakan telah berusia 19 tahun dan tidak terenkripsi, sehingga mudah dimanipulasi dengan malcode.
Karena itu, CurveCP juga mengandalkan enkripsi asimetris antara browser dan webserver. Hanya penerima yang dapat mendekripsi dengan Private Key. Prinsip yang sama digunakan dalam enkripsi PGP untuk lalu-lintas e-mail. Namun, metoda yang digunakan CurveCP berbeda. Kurva CurveCP menggunakan metode Eliptis Sistem Krypto Curve 25519.
Di balik nama yang rumit, tersembunyi kalkulasi logaritma sebuah kurva eliptis. Dalam prakteknya, enkripsi ini menggunakan kunci yang jauh lebih singkat daripada metode enkripsi asimetris lainnya. Sebagai perbandingan, kunci Curve 25519 sepanjang 160 Bit sama amannya dengan kunci RSA sepanjang 1.024 Bit. Namun, kelebihan dalam sistem keamanan ini ada harganya dibandingkan transfer data tanpa enkripsi. Akan tetapi, menurut Bernstein, kecepatannya hanya 1,15 kali lebih lambat daripada protokol TCP. Selain itu, meski enkripsinya rumit, kinerja CPU juga tidak terbebani.
CPU modern dapat dengan mudah memproses 10 juta kunci dalam waktu kurang dari 10 menit. Peselancar web tercepat pun tidak akan mampu membuka 16.600 website/detik.
Google adalah penyedia browser pertama yang mengaplikasikan teknologi ini ke dalam versi pengembangan terbaru Chrome. Rencana ini pun menimbulkan perdebatan seputar pengganti protokol TCP yang sudah kuno. Karena CurveCP ingin menggantikan salah satu pilar dasar web, mau tidak mau, produsen browser lainnya juga harus mendukung.
Namun ketika dikonfirmasi, Google tidak membeberkan rencana yang jelas. Sekarang ini hanya pengelola software-library NaCl (Networking and Cryptography Library) yang menguji metode ini. Bila pengujian yang dilakukan membuktikan kelebihan transfer data yang aman, CurveCP akan menghadapi tantangan berikutnya.
Daniel Bernstein dan Jeff Hodges adalah penggerak revolusi. Yang mereka kerjakan sangat berarti bagi setiap orang yang ingin menggunakan Internet dengan aman dan cepat.
Mereka meneliti jalur web yang lama, seperti protokol TCP dan HTTP. Jalur alternatif temuan mereka akan menyingkirkan masalah terbesar dan membuat Internet siap untuk masa depan dengan web yang semakin interaktif.
Protokol lama menghambat kinerja web modern layaknya lubang di tengah jalan tol. Selain itu, hacker amat mudah memata-matai password atau mengendalikan browser dengan serangan cyber yang semakin canggih.
Bernstein, Hodges, dan rekan-rekannya kini berupaya mencapai tingkat keamanan yang lebih baik dan transfer data yang lebih cepat. Nama protokol yang baru adalah DNSCurve, CurveCP, HSTS, dan SPDY. Untuk hasil yang optimal, produsen browser dan pengelola web server harus mendukung teknologi baru tersebut.
Untuk memahami mengapa setiap pengguna akan menikmati revolusi ini, kita harus meneropong masalah-masalah protokol data aktual. Transfer data di web – komunikasi antara pengguna dan website berlangsung dalam tahapan yang telah ditetapkan dengan segala kelemahannya.
Sebuah ‘TCP-Handshake’ membangun koneksi ke website dan di sini CurveCP akan melindungi dari serangan. Selanjutnya, konten web akan ditransfer, ini akan diubah dengan HSTS.
Transfer melalui HTTP juga terbatas secara teknis. Di sini, Google ingin meningkatkan kecepatan dengan SPDY. Namun sebelum koneksi ke website terbangun, DNS harus menemukan alamat IP dari URL yang dimasukkan. DNSCurve bertugas mencegah hacker memanipulasi penerjemahan alamat ini.
DNSCurve: Tidak ada lagi phishing
Sebuah URL terdiri atas tiga bagian, yaitu protokol yang digunakan (http://), nama domain (www.yahoo), dan top-level-domain (.co.id). Jika URL dimasukkan ke dalam address bar di browser, browser akan menampilkan website yang dimaksud. Untuk itu, URL membutuhkan alamat IP website yang didapatkan dari server DNS.
Biasanya, server DNS menyampaikan IP Address tanpa enkripsi. Metode ini sangat berbahaya. Jika hacker mampu mengubah IP Address, Anda bisa diarahkan ke website phishing. Tujuannya adalah untuk mencuri data login Anda. Serangan yang disebut DNS-spoofing ini sangat berbahaya.
Upaya pertama mengamankan permintaan DNS adalah melalui DNSSEC (Domain Name System Security Extension) yang mulai digunakan pada tahun 2005 dan mengenkripsi informasi domain di server-server DNS. Namun, jalur paket DNS antara PC pengguna dan server DNS tetap tidak terenkripsi. Bagi para pakar TI, kondisi ini menunjukkan bahwa DNSSEC telah gagal.
Alternatif yang dikembangkan Daniel J. Bernstein dari University of Illinois adalah DNSCurve. Proses ini mengamankan transfer nama domain dan IP Address dengan mengenkripsi permintaan dan jawaban pada ujung-ujungnya, ya itu di dalam sistem operasi client DNS dan server DNS.
Bila Anda mengetikkan URL www.website.com, client DNS mengirimkannya ke server sebagai www.123456789.website.com. Angka-angka tersebut adalah Public Key. Hanya server DNS yang dapat mendekripsi permintaan itu karena hanya server itulah yang memiliki kunci pribadi (Private Key) yang dibutuhkan.
Pada jalur sebaliknya, server mengirimkan IP Address yang bersangkutan dengan metode enkripsi yang sama dan asal paket data juga diverifikasi. Hacker yang menyadap data yang ditransfer tidak dapat memanfaatkannya.
Banyak server DNS telah mendukung teknologi baru ini. Selain keamanan, DNSCurve juga memiliki kelebihan, yaitu tidak membutuhkan revolusi server dan hanya perlu meng-install sebuah software untuk menggunakannya. Pertanyaannya, kapan Windows mendukung teknologi ini dalam client DNS-nya?
CurveCP: Mengenkripsi dengan Curve
Curve CP mengenkripsi transfer data pada titik akhirnya. Dengan prinsip ini, Daniel Bernstein juga ingin merevolusi protokol transportasi. Protokol ini menghubungkan browser dengan website dan mengirimkan data dalam dalam bentuk paket. TCP yang selama ini digunakan telah berusia 19 tahun dan tidak terenkripsi, sehingga mudah dimanipulasi dengan malcode.
Karena itu, CurveCP juga mengandalkan enkripsi asimetris antara browser dan webserver. Hanya penerima yang dapat mendekripsi dengan Private Key. Prinsip yang sama digunakan dalam enkripsi PGP untuk lalu-lintas e-mail. Namun, metoda yang digunakan CurveCP berbeda. Kurva CurveCP menggunakan metode Eliptis Sistem Krypto Curve 25519.
Di balik nama yang rumit, tersembunyi kalkulasi logaritma sebuah kurva eliptis. Dalam prakteknya, enkripsi ini menggunakan kunci yang jauh lebih singkat daripada metode enkripsi asimetris lainnya. Sebagai perbandingan, kunci Curve 25519 sepanjang 160 Bit sama amannya dengan kunci RSA sepanjang 1.024 Bit. Namun, kelebihan dalam sistem keamanan ini ada harganya dibandingkan transfer data tanpa enkripsi. Akan tetapi, menurut Bernstein, kecepatannya hanya 1,15 kali lebih lambat daripada protokol TCP. Selain itu, meski enkripsinya rumit, kinerja CPU juga tidak terbebani.
CPU modern dapat dengan mudah memproses 10 juta kunci dalam waktu kurang dari 10 menit. Peselancar web tercepat pun tidak akan mampu membuka 16.600 website/detik.
Google adalah penyedia browser pertama yang mengaplikasikan teknologi ini ke dalam versi pengembangan terbaru Chrome. Rencana ini pun menimbulkan perdebatan seputar pengganti protokol TCP yang sudah kuno. Karena CurveCP ingin menggantikan salah satu pilar dasar web, mau tidak mau, produsen browser lainnya juga harus mendukung.
Namun ketika dikonfirmasi, Google tidak membeberkan rencana yang jelas. Sekarang ini hanya pengelola software-library NaCl (Networking and Cryptography Library) yang menguji metode ini. Bila pengujian yang dilakukan membuktikan kelebihan transfer data yang aman, CurveCP akan menghadapi tantangan berikutnya.
HSTS: Dipaksa demi keamanan
Sebuah alternatif untuk koneksi web yang aman adalah HTTP Strict Transport Security (HSTS) yang sekarang telah digunakan oleh para pengelola website. Selama ini, koneksi terenkripsi dapat dikenali melalui tampilan ‘https’ dalam kolom URL browser. Namun, kebanyakan pengguna melupakan ‘https’ ini ketika memasukkan URL atau langsung menyimpan website biasa sebagai Favorite.
Di dalam website yang secara opsional mendukung keduanya (misalnya Facebook), pengguna dapat memilih untuk login melalui https yang aman atau http yang lebih terbuka bagi pencuri password. Man-in-the-Middle (hacker di antara pengguna dan server) seringkali memanfaatkan celah tersebut untuk menyadap identitas pengguna. Meskipun begitu, kesalahan tidak sepenuhnya berada di tangan pengguna. Sebagian website hanya mengenkripsi halaman login. Selanjutnya, pengguna diteruskan ke sub-website yang tidak dienkripsi.
Berbasis plugin Firefox ForceHTTPS, sebuah tim yang dipimpin Jeff Hodges (dulu bertanggung jawab atas keamanan informasi di PayPal) mengembangkan mekanisme HSTS. Tugas mekanisme ini mencegah koneksi tidak aman. Server website menetapkan setiap koneksi ke pengguna harus terenkripsi jika browser mendukungnya. Tak soal, apakah pengguna memasukkan https atau http dan bergerak di sub-website yang mana. Pemaksaan ini tidak dapat dihindari – kemungkinan terburuknya, website tidak ditampilkan.
Pemaksaan ‘https’ berakar di dalam header protokol data situs web dengan baris ‘Strict-Transport-Security: max-age=123456789; include SubDomains’. Parameter ‘max-age’ menetapkan dalam detik berapa lama koneksi https berlangsung. Kemudian, ‘Include SubDomains’ berarti setiap sub-website juga dienkripsi.
Kelebihan HSTS lainnya adalah mencegah hacker mencuri session-cookies yang berisi data login atau melakukan hal-hal lainnya atas nama pengguna. Jika halaman login yang terenkripsi langsung mengantar ke sub-halaman yang tidak terenkripsi, hal semacam itu dapat dengan mudah dilakukan.
Pemaksaan keamanan HSTS pada awalnya terkesan aneh. Akan tetapi, metode ini membantu memberi rasa aman pada pengguna. Sekarang, jaminan keamanan beralih kepada pengelola website. Pengguna tidak perlu lagi memeriksa kolom URL, apakah koneksinya aman atau tidak. Namun, tidak setiap website demikian.
Setidaknya, banyak pengelola website seperti layanan pembayaran PayPal, pengelola password LastPass, atau Android market telah menggunakan HSTS. Produsen browser juga menyusul. Chrome dan Firefox (mulai versi 4) juga mendukung HSTS. Dalam Chrome website-website HSTS disimpan dalam sebuah daftar yang dapat Anda perluas.
JIka Anda ingin berselancar dengan aman menggunakan Chrome, Anda bisa mencoba cara berikut ini. Masukkan ke dalam kolom URL ‘chrome://net-internals’ lalu pindah lah ke tab ‘HSTS’. Tambahkan sebuah URL di bawah ‘Add Domain’ dan tandai ‘Include SubDomains’. Dalam pengujian, upaya ini berhasil sangat baik. Di Facebook, kami berselancar di sana dengan koneksi terenkripsi.
SPDY: Turbo-web dari Google
Karena koneksi yang sepenuhnya terenkripsi selalu sedikit lebih lambat, sebuah teknologi baru memang dibutuhkan: SPDY (baca seperti ‘speedy’) akan membuat transfer data melalui protokol HTTP jauh lebih cepat.
Ketika HTTP distandardisasi 15 tahun lalu, halaman website tampak lebih sederhana dengan hanya menyajikan banyak teks, sedikit gambar, dan hampir tidak ada elemen interaktif. HTTP mentransfer volume data yang tidak banyak tersebut dengan sangat efisien. Namun, semakin banyak elemen, seperti sekarang ini (lusinan gambar, video, elemen JavaScript, dan CSS di web) membuat kapasitas HTTP semakin menyempit seperti leher botol.
Karena HTTP hanya dapat mentransfer salah satu elemen tersebut pada setiap koneksi data aktif, terjadi kemacetan sehingga halaman website di-load tidak lengkap. Kelemahan lainnya adalah header protokol yang tidak dikompresi dan selalu berisi informasi yang sama (bahasa, rangkaian karakter, website yang dikunjungi sebelumnya).
SPDY dikembangkan Google untuk mengatasi masalah di atas. Tantangannya, kita tidak dapat begitu saja mengganti protokol yang digunakan di seluruh web seperti HTTP. Perubahan yang dibutuhkan dalam sistem operasi pengguna dan di dalam hardware server serta jaringan sangat rumit. Karena itu, SPDY hanya memodifikasi manajemen koneksi dan format transfer data HTTP.
Secara teknis, masih HTTP yang mentransfer data dalam paket-paket TCP, tetapi jumlah elemen yang ditransfer secara paralel pada SPDY tidak terbatas. Di sini, Google menggunakan proses multi-flexing yang membungkus seluruh komunikasi antara pengguna dan server, memecahnya ke dalam frames, dan selanjutnya mentransfer melalui satu koneksi yang terenkripsi.
Anda bahkan dapat memprioritaskan elemen tertentu untuk mentransfer data terpenting lebih dulu atau memblokir elemen jika saluran penuh. Dengan sebuah fungsi Push server, Anda sudah dapat mengirim data ke browser sebelum diminta. Selain itu, SPDY merampingkan header dan mengompresinya dengan gzip. Kelemahan SPDY adalah beban kerja CPU meningkat akibat kompresi dan enkripsi header.
Walaupun demikian, menurut Google semua itu menghasilkan peningkatan kecepatan 44-64%. Anda akan merasakannya jika menggunakan Chrome dengan layanan Google, seperti Docs atau Gmail, di mana SPDY telah diaplikasikan hingga 90%. Faktanya, SPDY berfungsi lebih lancar di Chrome daripada di browser lain seperti Firefox atau IE. Namun, kecepatan juga selalu tergantung pada koneksi web aktual dan beban server.
Sebagai penyedia layanan web, Google mendapat banyak keuntungan dari koneksi cepat. Namun, penyedia layanan web yang lain pun mulai menggunakan SPDY. Contohnya, Strange Loop telah mengaplikasikan untuk beberapa pelanggannya dan mencatat peningkatan kecepatan loading rata-rata 20%.
Mozilla juga menganggap SPDY sebuah perbaikan yang berarti dari protokol HTTP dan akan mengujinya dalam Firefox versi pengembangan. Kapan SPDY akan didukung dalam versi final? Para pengembang Firefox belum dapat memastikannya.
Sepertinya, untuk semua layanan baru berlaku sebuah aturan "kapan revolusi akan berhasil? Jawabannya, tidak jelas". Satu hal yang pasti , akan ada perubahan dan perubahan itu menguntungkan pengguna yang ingin berselancar lebih cepat dan lebih aman.
Yang Dibawa Serta oleh Top-Level-Domain baru
Keputusan ‘pengelola Internet’ ICANN membuka pintu bagi akhiran domain seperti ‘bayern’ atau ‘microsoft’. Tetapi siapa yang membutuhkan TLD baru ini?
NAMA BARU, LEBIH AMAN
Top-Level-Domain (TLD) adalah bagian ke tiga sebuah domain-URL (setelah www dan nama domain) yang dibutuhkan untuk penerjemahan nama dan pencarian IP Address. Mulai 12 Januari 2012, setiap orang bisa meminta TLD sendiri dan juga sebuah arsitektur jaringan sendiri. Namun, prosesnya berlangsung sangat lama sehingga Anda harus menunggu hingga 2013 untuk TLD yang baru. TLD seperti ‘hotel’ atau ‘music’ akan diperebutkan dengan sangat sengit di seluruh dunia. Bagi perusahaan dan negara, TLD yang baru memberikan proteksi lebih besar untuk nama merk dan regional. Bagi pengguna, proses seleksi yang ketat akan menjamin website di bawah domain-domain tersebut dapat dipercaya.
Di sini Revolusi Internet Telah Dimulai
IPV6: Alamat yang Tidak Habis-Habis
Setiap perangkat akhir (di sisi pengguna atau server) membutuhkan sebuah IP Address untuk mengirim dan menerima data. Alamat-alamat IPv4 yang selama ini digunakan (192.168.56.1) hampir semua telah dibagikan. Namun, web terus berkembang. Solusinya adalah alamat IPv6 yang tampak seperti 2001:0eb7:86b4:03d7:1218:8e3b:0540:7847/64.
Dengan ukuran tersebut, jumlah totalnya hampir mencapai tidak terhingga. Perubahan ini berpengaruh pada pengguna (firmware-update router), penyedia layanan, dan pengelola website. Akan tetapi, IPv4 tetap didukung seperti sebelumnya sehingga seharusnya pergantian ini terjadi tanpa menimbullkan sejumlah masalah.
HTML5: Website Interaktif
Tidak hanya protokol data seperti TCP dan HTTP yang ‘kedaluarsa’. Bahasa standar web HTML juga berasal dari zaman website dengan konten teks murni. Kecanggihan multimedia menyebabkan banyak website sekarang ini hanya dapat direalisasi dengan bantuan JavaScript atau Flash. Teknologi itu memang dapat menempatkan banyak video, grafik, dan elemen interaktif. Akan tetapi, dampak negatifnya adalah sering menghambat website itu sendiri dan browser sering crash.
Sumber: Majalah CHIP 10/2011
No comments:
Post a Comment