Halaman ini diterjemahkan oleh Cloud Translation API.

Membingungkan perantara berbahaya dengan HTTPS dan HTTP Strict Transport Security

Mike West

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

Mengapa Anda harus peduli? Pertimbangkan hal ini:

Mengirim 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 sepertinya sedang berjalan ke arah kantor pos. Jika Anda beruntung, dia mungkin akan membawanya sendiri, atau dia mungkin akan memberikannya 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 spontan ini dapat dipercaya, dan tidak akan pernah mengintip surat terbuka Anda atau mengubahnya. Namun, semakin sering surat berpindah tangan, makin banyak orang yang memiliki akses lengkap ke surat yang Anda kirim. Pada akhirnya, kemungkinan besar penerima surat Anda akan mendapatkan sesuatu melalui pos, tetapi apakah sesuatu tersebut sama dengan sesuatu yang Anda serahkan pada awalnya adalah pertanyaan terbuka. Mungkin Anda harus menyegel amplop itu…

Perantara

Baik atau buruk, sebagian besar internet mengandalkan kepercayaan terhadap 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 lengkap ke permintaan saya dan ke respons server. Semua data ditransfer sebagai teks biasa yang tidak dienkripsi, dan setiap perantara tersebut dapat bertindak sebagai Man in the Middle, membaca data saya, atau bahkan memanipulasinya dalam pengiriman.

Lebih buruk lagi, jenis intersepsi 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 adalah _persis _data yang dikirim. Jika seseorang memutuskan untuk mengacak koneksi Internet saya untuk hiburan, saya tidak bisa berbuat apa-apa.

Apakah saluran ini aman?

Beralih dari HTTP teks biasa ke koneksi HTTPS yang aman menawarkan pertahanan terbaik terhadap perantara. Koneksi HTTPS mengenkripsi seluruh saluran end-to-end sebelum data dikirim, sehingga mesin antara Anda dan tujuan tidak dapat membaca atau mengubah data dalam pengiriman.

Omnibox Chrome memberikan cukup banyak detail tentang status koneksi.

Keamanan yang disediakan HTTPS berakar pada konsep kunci kriptografis publik dan pribadi. Diskusi mendalam tentang detailnya (untungnya) jauh melebihi 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 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 akan dienkripsi sedemikian rupa sehingga membuktikan bahwa permintaan dikirim ke dan respons diterima dari server yang diautentikasi.

Oleh karena itu, HTTPS memberi Anda beberapa jaminan bahwa Anda berbicara dengan server yang Anda yakini, dan tidak ada orang lain yang mendengarkan atau memanipulasi bit di jaringan. Jenis enkripsi ini adalah prasyarat mutlak untuk keamanan di web; jika aplikasi Anda saat ini tidak dikirim 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 penyedia ke penyedia dan server ke server, tetapi proses permintaan sertifikat sama di mana saja.

Aman secara default

Setelah 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 cookie hanya dikirim melalui koneksi aman.

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 toples kue

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 dengan setiap permintaan, sehingga server dapat memahami pengguna mana yang sedang direspons saat ini. Setelah memastikan bahwa pengguna membuka situs kami melalui HTTPS, kita juga harus memastikan bahwa data sensitif yang disimpan dalam cookie hanya ditransfer melalui koneksi yang aman, dan tidak pernah dikirim secara terbuka.

Menetapkan cookie biasanya melibatkan header HTTP yang terlihat seperti ini:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

Anda dapat memerintahkan browser untuk membatasi penggunaan cookie guna mengamankan sesi 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 sebagian besar waktu saat pengguna berada di situs Anda, mereka akan menggunakan koneksi aman. Namun, hal ini meninggalkan peluang kecil untuk serangan: koneksi HTTP awal terbuka lebar, rentan terhadap SSL stripping dan serangan terkait. Mengingat bahwa man in the middle memiliki akses lengkap ke permintaan HTTP awal, man in the middle dapat bertindak sebagai proxy antara Anda dan server, sehingga Anda tetap terhubung ke koneksi HTTP yang tidak aman, terlepas dari niat 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 pengalihan HTTP ke HTTPS sisi klien, tanpa pernah menyentuh jaringan (hal ini juga sangat bagus 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 membuat catatan bahwa situs tertentu ini telah meminta akses khusus HTTPS, yang berarti bahwa terlepas dari cara pengguna membuka situs, ia akan mengunjunginya melalui HTTPS. Meskipun mengetik http://example.com/ di browser, ia akan berakhir di HTTPS tanpa pernah membuat koneksi HTTP. Lebih baik lagi, jika browser mendeteksi sertifikat yang tidak valid (berpotensi mencoba meniru identitas server Anda), pengguna tidak akan diizinkan untuk melanjutkan melalui HTTP; semuanya atau tidak sama sekali, yang sangat bagus.

Browser akan menghentikan status HSTS server setelah max-age detik (sekitar sebulan dalam contoh ini); tetapkan 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 mencapai penerima yang dimaksud tanpa perubahan. Anda harus menyiapkan koneksi aman untuk situs dan aplikasi Anda sekarang. Proses ini cukup mudah, dan akan membantu menjaga keamanan data pelanggan Anda. Setelah menyiapkan saluran terenkripsi, Anda harus mengalihkan pengguna secara transparan ke koneksi aman ini, apa pun cara mereka membuka situs Anda, dengan mengirimkan respons HTTP 301. Kemudian, pastikan bahwa semua informasi sesi sensitif pengguna Anda hanya menggunakan koneksi aman tersebut dengan menambahkan kata kunci secure saat menetapkan cookie. Setelah melakukan semua hal tersebut, pastikan pengguna Anda tidak pernah tidak sengaja tertinggal: lindungi mereka dengan memastikan browser mereka melakukan hal yang benar dengan mengirim header Strict-Transport-Security.

Menyiapkan HTTPS tidak sulit, dan memiliki manfaat besar bagi situs Anda dan penggunanya. Hasilnya sepadan dengan upaya yang dilakukan.

Resource

StartSSL menawarkan sertifikat terverifikasi domain gratis. Anda tidak dapat mengalahkan gratis. Tentu saja, Anda dapat meningkatkan tingkat verifikasi 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 mendetail dengan baik yang menunjukkan apakah Anda benar-benar sudah siap dan berjalan.
Artikel terbaru Ars Technica "Securing your Web Server with SSL/TLS" layak dibaca untuk mengetahui detail latar belakang selengkapnya tentang seluk-beluk menyiapkan server.
Spesifikasi HTTP Strict Transport Security (RFC6797) layak dibaca sekilas untuk mengetahui semua informasi teknis tentang header Strict-Transport-Security yang mungkin Anda inginkan.
Setelah Anda benar-benar memahami apa yang Anda lakukan, salah satu kemungkinan langkah berikutnya adalah mengumumkan bahwa situs Anda hanya dapat dijangkau melalui kumpulan sertifikat tertentu. Ada beberapa pekerjaan yang sedang berlangsung di IETF yang memungkinkan Anda melakukan hal itu melalui header Public-Key-Pins; masih dalam tahap awal, tetapi menarik, dan patut diikuti.

Membingungkan perantara berbahaya dengan HTTPS dan HTTP Strict Transport Security Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.