Halaman ini diterjemahkan oleh Cloud Translation API.

Mengacaukan perantara berbahaya dengan keamanan transportasi HTTPS dan HTTP Strict

Mike West

Mengingat jumlah data pribadi yang mengalir melalui serangkaian besar tabung yaitu internet, enkripsi bukanlah sesuatu yang dapat atau tidak boleh kita abaikan. Browser modern menawarkan beberapa mekanisme yang dapat Anda gunakan untuk memastikan data pengguna tetap aman saat dalam pengiriman: cookie yang aman dan Strict Transport Security adalah dua yang paling penting. Keduanya memungkinkan Anda melindungi pengguna dengan lancar, mengupgrade koneksi mereka ke HTTPS, dan memberikan jaminan bahwa data pengguna tidak pernah dikirim secara jelas.

Mengapa Anda perlu tahu? Pertimbangkan ini:

Mengirimkan halaman web melalui koneksi HTTP yang tidak terenkripsi kurang lebih sama seperti memberikan amplop yang belum dibuka kepada orang pertama yang Anda lihat di jalan dan terlihat sedang berjalan ke arah kantor pos. Jika Anda beruntung, dia mungkin saja membawanya sendiri ke sana, atau dia mungkin menyerahkannya kepada orang berikutnya yang dia lihat sedang menuju ke arah yang benar. Orang itu mungkin melakukan hal yang sama, dan seterusnya.

Sebagian besar orang asing dalam rangkaian pesan mendadak ini dapat dipercaya, dan tidak akan pernah mengintip surat Anda atau mengubahnya. Namun, semakin sering huruf berpindah tangan, semakin besar jumlah orang yang memiliki akses lengkap ke huruf yang Anda kirim. Pada akhirnya, kemungkinan besar penerima surat Anda akan mendapatkan sesuatu melalui email tersebut, namun apakah hal tersebut sama dengan yang telah Anda serahkan sebelumnya adalah pertanyaan terbuka. Mungkin kau harus menyegel amplop itu...

Perantara

Baik atau buruk, banyaknya internet bergantung pada kepercayaan orang asing. Server tidak terhubung langsung satu sama lain, tetapi meneruskan permintaan dan respons dari router ke router dalam game Telepon yang sangat besar.

Anda dapat melihat cara kerja hop ini dengan {i>traceroute<i}. 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 itu bukan masalah. Namun, jika saya mengirim permintaan melalui HTTP, maka 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 Manusia di Middle, membaca data saya, atau bahkan memanipulasinya dalam pengiriman.

Lebih buruk lagi, intersepsi semacam ini hampir tidak terdeteksi. Respons HTTP yang dimodifikasi dengan berbahaya akan terlihat persis seperti respons yang valid karena tidak ada mekanisme yang dapat digunakan untuk memastikan bahwa data yang diterima _persis _data yang dikirim. Jika seseorang memutuskan untuk mengubah internet saya untuk tertawa, maka saya kurang beruntung.

Apakah ini saluran yang aman?

Peralihan dari HTTP teks biasa ke koneksi HTTPS yang aman memberikan pertahanan terbaik terhadap perantara. Koneksi HTTPS mengenkripsi seluruh saluran secara menyeluruh sebelum data dikirim, sehingga membuat mesin yang berada di antara Anda dan tujuan Anda tidak dapat membaca atau mengubah data saat dalam pengiriman.

Omnibox Chrome memberikan detail tentang status sambungan. — Omnibox Chrome memberikan beberapa detail tentang status sambungan.

Keamanan yang disediakan HTTPS berakar pada konsep kunci kriptografis publik dan pribadi. Diskusi mendalam tentang detail tersebut (dengan senang hati) jauh di luar cakupan artikel ini, tetapi premis intinya cukup jelas: data yang dienkripsi dengan kunci publik tertentu hanya dapat didekripsi dengan kunci pribadi yang sesuai. Saat browser memulai handshake HTTPS untuk membuat saluran aman, server akan 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 dikirimkan ke dan respons diterima dari server yang diautentikasi.

Oleh karena itu, HTTPS memberi Anda jaminan bahwa Anda berkomunikasi dengan server yang Anda maksud, dan tidak ada orang lain yang mendengarkan atau memutar-putar bit pada kabel. Enkripsi semacam ini adalah prasyarat mutlak untuk keamanan di web; jika aplikasi Anda saat ini tidak dikirimkan melalui HTTPS, aplikasi akan rentan terhadap serangan. Perbaiki. Ars Technica memiliki panduan untuk mendapatkan dan menginstal sertifikat (gratis) yang sebaiknya Anda lihat untuk mengetahui detail teknis. Konfigurasi akan berbeda dari penyedia ke penyedia dan server ke server, tetapi proses permintaan sertifikat sama di mana saja.

Aman secara default

Setelah Anda meminta dan menginstal sertifikat, pastikan pengguna mendapatkan manfaat dari kerja keras Anda: migrasikan pengguna yang ada ke koneksi HTTPS secara transparan melalui keajaiban pengalihan HTTP, dan pastikan bahwa cookie hanya dikirim melalui koneksi yang aman.

Dengan cara ini,

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 mengatur pengalihan semacam ini dengan mudah di server seperti Apache atau Nginx. Misalnya, konfigurasi Nginx yang dialihkan dari http://example.com/ ke https://example.com/ akan 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;
    }
}

Kunci stoples kue

Cookie memberi kami kemampuan untuk memberikan pengalaman login yang lancar kepada pengguna melalui protokol HTTP stateless. Data yang disimpan dalam cookie, termasuk informasi sensitif seperti ID sesi, dikirimkan bersama dengan setiap permintaan, sehingga server dapat mengetahui pengguna mana yang sedang meresponsnya. Setelah memastikan bahwa pengguna membuka situs melalui HTTPS, sebaiknya pastikan juga bahwa data sensitif yang disimpan dalam cookie hanya ditransfer melalui koneksi yang aman, dan tidak pernah dikirim secara jelas.

Menetapkan cookie umumnya memerlukan 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 guna mengamankan sesi dengan menargetkan 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 pengguna yang berada di situs Anda, akan menggunakan koneksi yang aman. Namun, data ini menyisakan sedikit peluang untuk melakukan serangan: koneksi HTTP awal terbuka secara luas, rentan terhadap SSL stripping dan serangan terkait. Mengingat bahwa man in the middle memiliki akses penuh ke permintaan HTTP awal, hal ini dapat bertindak sebagai proxy antara Anda dan server, sehingga Anda tetap berada pada koneksi HTTP yang tidak aman, terlepas dari maksud server.

Anda dapat mengurangi risiko jenis serangan ini dengan meminta browser untuk menerapkan HTTP Strict Transport Security (HSTS). Mengirim header HTTP Strict-Transport-Security akan menginstruksikan browser untuk melakukan sisi klien HTTP ke HTTPS, tanpa pernah menyentuh jaringan (hal ini juga sangat bagus untuk performa; permintaan terbaik adalah 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 detail) akan membuat catatan bahwa situs khusus ini telah meminta akses khusus HTTPS, artinya terlepas dari cara pengguna masuk ke situs, dia akan mengunjungi situs melalui HTTPS. Meskipun dia mengetik http://example.com/ di browser, dia akan berakhir di HTTPS tanpa perlu membuat koneksi HTTP. Lebih baik lagi, jika browser mendeteksi sertifikat yang tidak valid (berpotensi mencoba melakukan spoofing terhadap identitas server Anda), pengguna tidak akan diizinkan untuk melanjutkan melalui HTTP; semuanya bisa saja terjadi atau tidak sama sekali, dan itu sangat bagus.

Browser akan habis masa berlakunya status HSTS server setelah max-age detik (sekitar satu bulan dalam contoh ini); setel 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

Teruslah menjelajah dengan aman

HTTPS adalah satu-satunya cara untuk lebih memastikan bahwa data yang Anda kirim sampai ke penerima yang dituju secara utuh. Sekarang Anda harus menyiapkan koneksi yang aman untuk situs dan aplikasi Anda. Proses ini cukup mudah, dan akan membantu menjaga keamanan data pelanggan. Setelah mendapatkan saluran terenkripsi, Anda harus secara transparan mengalihkan pengguna ke koneksi yang aman ini, terlepas dari bagaimana mereka datang ke 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 menyetel cookie. Setelah Anda melakukannya, pastikan pengguna tidak jatuh dari bus secara tidak sengaja: 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. Hasil yang didapat sepadan dengan usaha Anda.

Referensi

StartSSL menawarkan sertifikat gratis yang diverifikasi domain. Anda tidak boleh kalah. Melangkah ke tingkat verifikasi yang lebih tinggi tentu saja dapat dilakukan dan dengan harga yang wajar.
Pengujian Server SSL: Setelah menyiapkan HTTPS untuk server, pastikan Anda telah melakukannya dengan benar dengan menjalankannya melalui pengujian server SSL Labs. Anda akan mendapatkan laporan yang sangat mendetail yang menunjukkan apakah Anda benar-benar aktif dan berjalan.
Artikel terbaru Ars Technica "Mengamankan Server Web Anda dengan SSL/TLS" layak dibaca untuk mengetahui detail latar belakang yang lebih lengkap tentang dasar-dasar penyiapan server.
Spesifikasi HTTP Strict Transport Security (RFC6797) layak untuk dibaca sekilas untuk semua informasi teknis tentang header Strict-Transport-Security yang mungkin Anda inginkan.
Setelah benar-benar mengetahui apa yang Anda lakukan, satu langkah yang mungkin dilakukan adalah mengiklankan bahwa situs Anda hanya dapat dijangkau melalui kumpulan sertifikat tertentu. Ada beberapa pekerjaan yang sedang berlangsung di IETF yang memungkinkan Anda melakukannya melalui header Public-Key-Pins; masih sangat awal, tetapi menarik, dan layak diikuti.