Mengingat jumlah data pribadi yang mengalir melalui serangkaian jaringan internet yang sangat besar, enkripsi bukanlah sesuatu yang dapat atau harus kita abaikan begitu saja. Browser modern menawarkan beberapa mekanisme yang dapat Anda gunakan untuk memastikan bahwa data pengguna Anda aman saat dalam pengiriman: cookie aman dan Strict Transport Security adalah dua mekanisme yang paling penting. Fitur ini memungkinkan Anda melindungi pengguna dengan lancar, mengupgrade koneksi mereka ke HTTPS, dan memberikan jaminan bahwa data pengguna tidak pernah dikirim dalam bentuk teks biasa.
Mengapa Anda harus peduli? Pertimbangkan ini:
Menayangkan halaman web melalui koneksi HTTP yang tidak dienkripsi kurang lebih sama dengan menyerahkan amplop yang tidak disegel kepada orang pertama yang Anda lihat di jalan yang tampaknya sedang berjalan ke arah kantor pos. Jika Anda beruntung, dia mungkin akan membawanya sendiri sampai ke sana, atau dia mungkin akan menyerahkannya kepada orang berikutnya yang dia lihat yang menuju ke arah yang benar. Orang tersebut mungkin melakukan hal yang sama, dan seterusnya.
Sebagian besar orang asing dalam rantai dadakan ini dapat dipercaya, dan tidak akan pernah mengintip surat terbuka Anda atau mengubahnya. Namun, makin sering surat berpindah tangan, makin banyak orang yang memiliki akses lengkap ke surat yang Anda kirim. Pada akhirnya, kemungkinan besar penerima yang dituju akan mendapatkan sesuatu dalam surat, tetapi apakah sesuatu itu sama dengan sesuatu yang Anda serahkan di awal adalah pertanyaan terbuka. Mungkin Anda seharusnya menyegel amplop itu…
Middlemen
Baik atau buruk, sebagian besar internet mengandalkan kepercayaan dari orang asing. Server tidak terhubung langsung satu sama lain, tetapi meneruskan permintaan dan respons dari router ke router dalam permainan Telepon yang sangat besar.
Anda dapat melihat cara kerja hop ini dengan traceroute. Rute dari komputer saya ke HTML5Rocks terlihat seperti ini:
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
13 hop sebenarnya tidak terlalu buruk. Namun, jika saya mengirim permintaan melalui HTTP, setiap router perantara tersebut memiliki akses penuh ke permintaan saya dan ke respons server. Semua data ditransfer sebagai teks biasa yang tidak dienkripsi, dan salah satu perantara tersebut dapat bertindak sebagai Man in the Middle, membaca data saya, atau bahkan memanipulasinya saat dalam pengiriman.
Lebih buruk lagi, intersepsi semacam ini hampir tidak dapat dideteksi. Respons HTTP yang dimodifikasi secara berbahaya terlihat persis seperti respons yang valid, karena tidak ada mekanisme yang memungkinkan Anda memastikan bahwa data yang diterima _persis_ dengan data yang dikirim. Jika seseorang memutuskan untuk mengacaukan Internet saya hanya untuk bersenang-senang, saya akan mengalami kerugian.
Apakah saluran ini aman?
Beralih dari HTTP teks biasa ke koneksi HTTPS yang aman menawarkan pertahanan terbaik Anda terhadap perantara. Koneksi HTTPS mengenkripsi seluruh saluran secara end-to-end sebelum data dikirim, sehingga mesin di antara Anda dan tujuan tidak dapat membaca atau mengubah data dalam pengiriman.
Keamanan yang diberikan HTTPS berakar pada konsep kunci kriptografis publik dan pribadi. Pembahasan mendalam tentang detailnya (untungnya) berada di luar cakupan artikel ini, tetapi premis intinya cukup sederhana: data yang dienkripsi dengan kunci publik tertentu hanya dapat didekripsi dengan kunci pribadi yang sesuai. Saat browser memulai handshake HTTPS untuk membuat saluran yang aman, server memberikan sertifikat yang memberi browser semua informasi yang diperlukan untuk memverifikasi identitasnya dengan memeriksa apakah server memiliki kunci pribadi yang tepat. Semua komunikasi dari titik tersebut dan seterusnya dienkripsi sedemikian rupa sehingga membuktikan bahwa permintaan dikirim ke dan respons diterima dari server yang diautentikasi.
Oleh karena itu, HTTPS memberi Anda jaminan bahwa Anda berkomunikasi dengan server yang Anda tuju, dan tidak ada orang lain yang menguping atau mengutak-atik bit di jaringan. Jenis enkripsi ini adalah prasyarat mutlak untuk keamanan di web; jika aplikasi Anda saat ini tidak dikirimkan melalui HTTPS, aplikasi tersebut rentan terhadap serangan. Perbaiki. Ars Technica memiliki panduan yang bagus untuk mendapatkan dan menginstal sertifikat (gratis) yang sebaiknya Anda lihat untuk mengetahui detail teknisnya. Konfigurasi akan berbeda dari satu penyedia ke penyedia lainnya dan dari satu server ke server lainnya, tetapi proses permintaan sertifikat sama di mana pun.
Aman secara default
Setelah Anda meminta dan menginstal sertifikat, pastikan pengguna Anda mendapatkan manfaat dari kerja keras Anda: migrasikan pengguna yang ada ke koneksi HTTPS secara transparan melalui keajaiban pengalihan HTTP, dan pastikan cookie hanya dikirim melalui koneksi yang aman.
Silakan lewat sini
Saat pengguna mengunjungi http://example.com/, alihkan mereka ke
https://example.com/ dengan mengirimkan respons 301 Moved
Permanently dengan header Location yang sesuai:
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
Anda dapat menyiapkan pengalihan semacam ini dengan mudah di server seperti Apache atau Nginx.
Misalnya, konfigurasi Nginx yang mengalihkan dari http://example.com/
ke https://example.com/ terlihat seperti ini:
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
Mengunci stoples cookie
Cookie memberi kita kemampuan untuk memberikan pengalaman login yang lancar kepada pengguna melalui protokol HTTP stateless. Data yang disimpan dalam cookie, termasuk informasi sensitif seperti ID sesi, dikirim bersama setiap permintaan, sehingga server dapat memahami pengguna mana yang sedang direspons saat ini. Setelah memastikan bahwa pengguna mengakses situs kita melalui HTTPS, kita juga harus memastikan bahwa data sensitif yang disimpan dalam cookie hanya ditransfer melalui koneksi yang aman, dan tidak pernah dikirim dalam bentuk teks biasa.
Menetapkan cookie umumnya melibatkan header HTTP yang terlihat seperti ini:
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
Anda dapat menginstruksikan browser untuk membatasi penggunaan cookie ke sesi aman dengan menambahkan satu kata kunci:
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
Cookie yang ditetapkan dengan kata kunci secure tidak akan pernah dikirim melalui HTTP.
Menutup jendela yang terbuka
Pengalihan transparan ke HTTPS berarti bahwa sebagian besar waktu pengguna Anda berada di situs Anda, mereka akan menggunakan koneksi yang aman. Namun, hal ini menyisakan sedikit peluang untuk serangan: koneksi HTTP awal terbuka lebar, rentan terhadap SSL stripping dan serangan terkait. Mengingat bahwa man in the middle memiliki akses penuh ke permintaan HTTP awal, ia dapat bertindak sebagai proxy antara Anda dan server, sehingga membuat Anda tetap berada di koneksi HTTP yang tidak aman, terlepas dari niat server.
Anda dapat mengurangi risiko serangan jenis ini dengan meminta browser untuk
menerapkan HTTP Strict Transport Security
(HSTS). Mengirim header HTTP Strict-Transport-Security akan menginstruksikan browser untuk melakukan pengalihan HTTP ke HTTPS di sisi klien, tanpa menyentuh jaringan (hal ini juga sangat baik untuk performa; permintaan terbaik adalah permintaan yang tidak perlu Anda buat):
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
Browser yang mendukung header ini (saat ini Firefox, Chrome, dan Opera: caniuse memiliki detailnya) akan mencatat bahwa situs tertentu ini telah meminta akses khusus HTTPS, artinya, terlepas dari cara pengguna membuka situs, dia akan berkunjung melalui HTTPS. Meskipun dia mengetik http://example.com/ di browser, dia akan diarahkan ke HTTPS tanpa pernah membuat koneksi HTTP. Lebih baik lagi, jika browser mendeteksi sertifikat yang tidak valid (berpotensi mencoba melakukan spoofing pada identitas server Anda), pengguna tidak akan diizinkan untuk melanjutkan melalui HTTP; semuanya atau tidak sama sekali, yang sangat bagus.
Browser akan mengakhiri masa berlaku status HSTS server setelah max-age detik
(sekitar sebulan dalam contoh ini); tetapkan nilai ini ke nilai yang cukup tinggi.
Anda juga dapat memastikan bahwa semua subdomain origin dilindungi dengan menambahkan
perintah includeSubDomains ke header:
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
Lanjutkan dengan aman
HTTPS adalah satu-satunya cara untuk memastikan bahwa data yang Anda kirim sampai ke penerima yang dituju secara utuh. Anda harus menyiapkan koneksi aman untuk situs dan aplikasi Anda, sekarang juga. Prosesnya cukup mudah, dan akan membantu
menjaga keamanan data pelanggan Anda. Setelah Anda menyiapkan saluran terenkripsi, Anda harus mengalihkan pengguna secara transparan ke koneksi aman ini, terlepas dari cara mereka membuka situs Anda, dengan mengirimkan respons HTTP 301. Kemudian,
pastikan semua informasi sesi sensitif pengguna Anda hanya menggunakan
koneksi aman tersebut dengan menambahkan kata kunci secure saat menetapkan cookie.
Setelah Anda melakukan semua itu, pastikan pengguna Anda tidak pernah secara tidak sengaja keluar dari
bus: lindungi mereka dengan memastikan bahwa browser mereka melakukan hal yang benar dengan
mengirimkan header Strict-Transport-Security.
Menyiapkan HTTPS tidaklah sulit, dan memiliki manfaat besar bagi situs Anda dan penggunanya. Hasilnya akan sepadan dengan usaha Anda.
Resource
- StartSSL menawarkan sertifikat gratis yang diverifikasi domain. Anda tidak dapat mengalahkan gratis. Tentu saja, Anda dapat meningkatkan ke tingkat verifikasi yang lebih tinggi dengan harga yang wajar.
- SSL Server Test: Setelah menyiapkan HTTPS untuk server, pastikan Anda telah melakukannya dengan benar dengan menjalankannya melalui pengujian server SSL Labs. Anda akan mendapatkan laporan mendetail yang menunjukkan apakah Anda benar-benar aktif dan berjalan.
- Artikel terbaru Ars Technica "Securing your Web Server with SSL/TLS" layak dibaca untuk mengetahui sedikit lebih banyak detail latar belakang tentang seluk-beluk penyiapan server.
- Spesifikasi HTTP Strict Transport Security
(RFC6797) layak dibaca sekilas untuk mengetahui semua
informasi teknis tentang header
Strict-Transport-Securityyang mungkin Anda inginkan. - Setelah Anda benar-benar memahami apa yang Anda lakukan, langkah berikutnya yang mungkin dilakukan adalah
memberitahukan bahwa situs Anda hanya dapat dijangkau melalui kumpulan sertifikat
tertentu. Ada beberapa pekerjaan yang sedang berlangsung di IETF yang memungkinkan Anda
melakukan hal tersebut melalui header
Public-Key-Pins; masih dalam tahap awal, tetapi menarik, dan layak untuk diikuti.