HSTS Memaksa HTTPS Setelah Policy Host Tersimpan

Redirect dari HTTP ke HTTPS memindahkan request ke TLS, tetapi request HTTP pertama tetap terjadi. Jika browser memulai dari http://example.com, browser dapat menghubungi endpoint HTTP sebelum menerima redirect. Penyerang yang berada di jalur jaringan dapat mengganggu pertukaran itu sebelum browser mencapai TLS.

HTTP Strict Transport Security (HSTS), yang distandardisasi dalam RFC 6797, mengubah perilaku navigasi berikutnya. User agent yang sesuai dan menerima response Strict-Transport-Security yang valid melalui transport aman menyimpan policy HTTPS-only untuk host tersebut. Selama policy masih aktif, URL HTTP untuk host itu diubah menjadi HTTPS sebelum request tidak aman dikirim.

tanpa HSTS tersimpan:

URL http -> request HTTP -> redirect -> HTTPS

dengan HSTS aktif:

URL http -> rewrite HTTPS lokal -> request HTTPS

Boundary keamanannya berada pada policy yang disimpan browser. HSTS tidak mengenkripsi HTTP dan tidak memperbaiki endpoint TLS yang telah dikompromikan. Mekanisme ini menutup jalur downgrade HTTP setelah user agent memiliki state policy yang dapat dipercaya.

Policy diterima melalui HTTPS

Server menyatakan HSTS dengan response header Strict-Transport-Security:

Strict-Transport-Security: max-age=31536000

max-age dihitung dalam detik. Setiap header yang diterima memperbarui masa browser memperlakukan host sebagai known HSTS host. Nilai nol memberi instruksi kepada user agent untuk menghapus policy yang tersimpan bagi host tersebut.

Header hanya bermakna ketika diterima melalui transport aman. Jika policy HSTS diterima dari HTTP biasa, pihak yang berada di jalur jaringan dapat membuat atau mengubah policy sebelum autentikasi. Aturan pengiriman aman membuat pembentukan policy tetap terikat pada koneksi TLS yang terautentikasi.

Karena itu, redirect HTTP dan HSTS menjalankan tugas berbeda. Redirect menangani request yang sudah mencapai HTTP. HSTS memengaruhi pembentukan request berikutnya di dalam user agent.

Error sertifikat tetap menjadi kegagalan keras

Setelah host dikenal sebagai HSTS, browser tidak hanya mengubah http menjadi https. RFC 6797 mewajibkan penghentian koneksi ketika transport aman menghasilkan error seperti kegagalan validasi sertifikat; user agent tidak menyediakan jalur untuk melanjutkan melewati error tersebut bagi HSTS host.

Properti ini penting karena rewrite HTTPS otomatis saja masih dapat menyisakan peluang bagi user untuk melewati peringatan sertifikat. HSTS mengikat keputusan HTTPS-only yang tersimpan dengan penanganan error TLS yang ketat.

Mekanisme ini tidak mengubah aturan validasi sertifikat. Pemeriksaan hostname, validasi chain, masa berlaku, trust anchor, dan policy TLS lain tetap berjalan normal. HSTS mengubah perilaku fallback yang diizinkan di sekelilingnya.

includeSubDomains memperluas boundary

Sebuah host dapat memperluas policy ke nama di bawahnya:

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

Dengan includeSubDomains, policy berlaku pada host dan subdomain-nya. Penerapannya karena itu memerlukan inventaris nama di bawah domain tersebut. Service HTTP-only yang terlupakan dapat menjadi tidak dapat diakses oleh browser yang sesuai setelah policy parent aktif.

Cakupan ini memang luas. Policy dapat melindungi nama yang belum memiliki state HSTS sendiri, tetapi keluasan yang sama membuat subdomain legacy menjadi constraint migrasi.

Subdomain juga dapat membuat entry HSTS sendiri. State browser untuk subdomain karena itu dapat bertahan lebih lama daripada entry parent atau memiliki konfigurasi berbeda. Menghapus policy parent dengan max-age=0 tidak menghapus policy terpisah yang sebelumnya dibuat oleh subdomain.

Celah kontak pertama tetap ada

HSTS biasa memakai model trust-on-first-use untuk pengiriman policy. Profil browser baru tanpa state HSTS masih dapat memulai dari URL HTTP. Jika response aman pertama tidak pernah diterima, browser belum memiliki policy dari host tersebut untuk ditegakkan.

profil baru
   |
   v
tidak ada state HSTS
   |
   +--> HTTP dapat terjadi sebelum policy aman pertama diterima

Batas ini terpisah dari kekuatan konfigurasi TLS setelah HTTPS dimulai. Konfigurasi TLS yang kuat tidak dapat membuat browser memiliki policy HSTS yang belum pernah diterimanya.

Preload list menangani celah bootstrap ini dengan membawa pengetahuan HTTPS-only bersama browser, bukan menunggu response langsung dari situs. Preloading merupakan mekanisme ekosistem dan bukan bagian dari RFC 6797.

Preloading adalah komitmen deployment

Situs yang menargetkan preload umumnya menyajikan header seperti:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Token preload menyatakan intent deployment kepada tooling preload list; token tersebut bukan fitur yang menyebabkan pemrosesan HSTS RFC 6797. Keberadaan domain dalam data preload browser yang menyediakan policy sebelum kontak pertama.

Program preload memiliki persyaratan submission sendiri. Panduan ekosistem browser saat ini umumnya meminta max-age panjang dan includeSubDomains. Persyaratan itu dapat berubah terpisah dari standar HSTS, sehingga automation deployment sebaiknya memperlakukan kelayakan preload sebagai policy eksternal, bukan semantic protokol yang di-hard-code.

Penghapusan juga lebih lambat daripada mengirim header baru. Situs dapat mengirim max-age=0 kepada client yang berhasil mencapainya melalui koneksi aman, tetapi entry yang sudah di-preload tetap berada dalam rilis browser sampai data preload diperbarui dan rilis tersebut sampai ke user. Karena itu, adopsi preload tidak cocok diperlakukan sebagai eksperimen ringan.

Rollout perlu mengikuti inventaris domain

Rollout bertahap mengurangi risiko membuat host HTTP-only yang masih diperlukan menjadi tidak dapat diakses. Urutan praktisnya adalah memastikan HTTPS stabil pada host target, memulai dengan max-age moderat, mengamati perilaku operasional, memperpanjang lifetime, lalu menambahkan includeSubDomains setelah service di bawah domain siap.

Nilai persisnya merupakan pilihan deployment, bukan konstanta keamanan universal. Constraint utamanya adalah durasi policy menciptakan komitmen. Setelah browser menyimpan lifetime panjang, rollback konfigurasi di server tidak langsung menghapus state client.

Monitoring perlu mencakup renewal sertifikat, reachability TLS, perilaku redirect untuk client tanpa state HSTS, dan daftar subdomain yang tercakup policy. HSTS dapat memaksa client menuju HTTPS, tetapi tidak dapat menjaga service HTTPS tetap sehat.

HSTS paling efektif ketika diperlakukan sebagai policy transport persisten di sisi client, bukan sekadar header redirect lain. Nilainya berasal dari perubahan perilaku browser sebelum request tidak aman keluar dari perangkat, sementara biaya operasionalnya berasal dari persistensi yang sama.