HSTS Menetapkan Kebijakan HTTPS di Browser

Redirect dari HTTP ke HTTPS berguna, tetapi redirect tetap berupa response HTTP. Browser yang memulai dari http://example.com sudah mengirim request tanpa autentikasi sebelum server sempat menjawab dengan 301 atau 308. Penyerang yang dapat memodifikasi koneksi tersebut dapat menghilangkan atau mengganti redirect.

HTTP Strict Transport Security (HSTS) memindahkan sebagian kebijakan transport ke browser. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, browser yang mendukung HSTS mengingat bahwa host tersebut mewajibkan transport aman selama masa yang dinyatakan. Upaya berikutnya untuk memakai HTTP pada host itu diubah secara lokal sebelum request HTTP dikirim.

Kebijakan hanya diterima melalui HTTPS

Header response yang umum berbentuk:

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age dihitung dalam detik. Nilai ini menentukan berapa lama kebijakan HSTS tetap aktif setelah diterima. Setiap response HTTPS valid yang membawa header tersebut dapat memperbarui masa berlakunya.

Browser mengabaikan header HSTS yang diterima melalui HTTP biasa. Menerima kebijakan dari kanal tanpa autentikasi akan memberi penyerang jaringan kesempatan membuat atau mengubah kebijakan keamanan. Karena itu, server memerlukan endpoint HTTPS yang berfungsi dengan sertifikat valid sebelum HSTS dapat membentuk state di browser.

Kondisi ini menyisakan celah pada kontak pertama. Browser yang belum menyimpan kebijakan masih dapat memulai melalui HTTP. HSTS melindungi kunjungan berikutnya setelah kebijakan dikirim secara aman; HSTS tidak dapat mengamankan secara retroaktif request pertama yang tidak diautentikasi.

Navigasi HTTP ditulis ulang sebelum dikirim

Selama kebijakan aktif, browser memperlakukan URL HTTP untuk host HSTS sebagai koneksi yang wajib memakai HTTPS. Secara konseptual:

diminta:
http://example.com/account

kebijakan browser:
example.com -> HSTS aktif

request jaringan:
https://example.com/account

Batas pentingnya berada pada lokasi perubahan. Redirect di server memerlukan satu round trip HTTP. HSTS membuat user agent memilih transport aman sebelum request tidak aman keluar dari browser.

Aplikasi tetap sebaiknya mempertahankan redirect HTTP-ke-HTTPS. Client tanpa dukungan HSTS, kunjungan pertama tanpa state tersimpan, dan tooling operasional masih dapat mencapai listener HTTP. Redirect dan HSTS menangani bagian yang berkaitan, tetapi tidak identik.

Kegagalan sertifikat menjadi kegagalan final

HSTS juga mengubah penanganan error autentikasi TLS. Untuk host HSTS, browser tidak boleh menawarkan jalur normal yang memungkinkan pengguna melewati peringatan sertifikat tidak valid lalu melanjutkan koneksi.

Perilaku ini penting karena keamanan transport bergantung pada enkripsi sekaligus identitas endpoint yang terautentikasi. Fallback diam-diam ke HTTP atau opsi untuk melewati error sertifikat akan melemahkan kebijakan tepat saat koneksi aman tidak dapat diautentikasi.

Secara operasional, HSTS meningkatkan dampak kesalahan sertifikat. Sertifikat kedaluwarsa, hostname yang tidak cocok, atau deployment yang belum lengkap dapat membuat situs tidak dapat diakses oleh browser yang sudah menyimpan kebijakan. Proses renewal dan deployment sertifikat perlu andal sebelum max-age panjang digunakan.

includeSubDomains memperluas batas kebijakan

Directive includeSubDomains menerapkan kebijakan ke subdomain di bawah host HSTS. Jika example.com mengirim:

Strict-Transport-Security: max-age=31536000; includeSubDomains

browser juga memperlakukan host seperti api.example.com dan old.example.com sebagai bagian dari cakupan HSTS selama kebijakan induknya aktif.

Cakupan ini aman digunakan hanya jika setiap subdomain terkait dapat melayani HTTPS dengan benar. Host lama yang masih bergantung pada HTTP dapat menjadi tidak dapat diakses setelah kebijakan induk diperluas kepadanya.

Tim perlu menginventarisasi subdomain yang didelegasikan, sistem lama, dan host yang dikelola pihak eksternal sebelum mengaktifkan includeSubDomains. Kepemilikan DNS saja tidak cukup; setiap hostname dalam cakupan memerlukan jalur HTTPS dan konfigurasi sertifikat yang berfungsi.

Preload menutup celah kontak pertama

Browser utama dapat membawa daftar HSTS preload. Host dalam daftar tersebut diperlakukan sebagai HSTS sebelum browser menerima header dari situs, sehingga celah HTTP pada kunjungan pertama biasa hilang untuk browser yang membawa entri itu.

Preload merupakan komitmen operasional yang lebih kuat daripada sekadar mengirim header response. Penghapusan tidak berlangsung seketika karena release browser dan data preload memerlukan waktu untuk tersebar. Domain yang akan masuk preload harus siap mempertahankan HTTPS pada namespace yang tercakup sesuai persyaratan program preload.

Header response tetap relevan untuk domain yang sudah masuk preload. Header tersebut menyatakan kebijakan aktif situs dan dapat memperbarui state secara terpisah dari daftar bawaan browser.

HSTS tidak menggantikan kontrol keamanan aplikasi

HSTS membatasi pemilihan transport pada user agent yang mendukungnya. HSTS tidak mengotorisasi request, memvalidasi input aplikasi, mencegah cross-site scripting, mengatur scope cookie, atau menggantikan pertahanan CSRF.

HSTS juga tidak membuat origin yang sudah diambil alih menjadi tepercaya. Jika penyerang menguasai server aplikasi atau memperoleh sertifikat yang diterima untuk hostname tersebut, HSTS tidak membedakan endpoint itu dari service yang diharapkan. Batasnya lebih sempit: mencegah downgrade ke HTTP untuk host yang kebijakannya tersimpan dan mewajibkan autentikasi TLS valid tanpa opsi bypass oleh pengguna.

Session cookie tetap perlu memakai Secure jika sesuai. HSTS dapat mencegah browser mengirim request HTTP ke host yang tercakup, sedangkan atribut cookie secara terpisah memberi instruksi agar cookie tersebut tidak dikirim melalui transport tidak aman.

Rollout harus sesuai dengan kemampuan pemulihan

Deployment yang hati-hati dapat dimulai dengan max-age lebih pendek, memastikan perilaku HTTPS pada seluruh host yang dituju, lalu menaikkan masa kebijakan. includeSubDomains dan pendaftaran preload sebaiknya dilakukan setelah konsekuensi cakupan yang lebih luas diperiksa.

Monitoring perlu mencakup masa berlaku sertifikat, konfigurasi TLS, ketersediaan HTTPS, dan inventaris subdomain. Kebijakan browser berumur panjang mengubah gangguan HTTPS dari peringatan menjadi kegagalan akses, sehingga keandalan transport menjadi bagian dari kontrol keamanan.

HSTS efektif karena browser menyimpan keputusan yang tidak aman jika harus diserahkan kepada jaringan pada setiap kunjungan. Setelah kebijakan terbentuk, HTTP keluar dari jalur koneksi normal untuk host tersebut dan kegagalan autentikasi TLS menjadi final, bukan pilihan yang dapat dilewati.