State HSTS Menutup Celah Downgrade pada Request Pertama
Sebuah situs dapat mengalihkan setiap request HTTP ke HTTPS dan tetap memiliki celah sebelum redirect itu tiba. Browser sudah lebih dahulu mengirim request HTTP melalui jaringan. Perantara aktif dapat mengubah pertukaran tersebut, menahan redirect, atau mempertahankan koneksi client pada HTTP plaintext.
HTTP Strict Transport Security (HSTS), yang ditetapkan dalam RFC 6797, memindahkan lokasi keputusan tersebut. Setelah menerima header Strict-Transport-Security yang valid melalui koneksi aman, user agent yang sesuai menyimpan state kebijakan untuk host itu. Navigasi HTTP berikutnya ke host tersebut diubah menjadi HTTPS secara lokal sebelum request tidak aman dikirim.
State lokal itulah batas keamanannya. Redirect tidak lagi bertugas memindahkan pertukaran plaintext yang sudah terbentuk ke TLS.
Redirect bekerja setelah traffic plaintext terbentuk
Redirect HTTP ke HTTPS merupakan respons aplikasi. Agar browser dapat menerimanya, browser harus lebih dahulu menghubungi server melalui HTTP. Request awal dan respons redirect karena itu melintasi jaringan tanpa perlindungan TLS.
Urutan ini penting pada jaringan yang tidak tepercaya. Jika perantara mengendalikan pertukaran plaintext, kebijakan server pada endpoint HTTPS tidak dapat memaksa request tersebut untuk mencapainya. Redirect 301 atau 308 berguna untuk routing normal, tetapi tidak dapat mengautentikasi respons yang dikirim sebelum TLS terbentuk.
HSTS memindahkan transisi skema ke depan pertukaran jaringan tersebut. Saat kebijakan tersimpan berlaku, URL http:// yang menargetkan host HSTS diperlakukan sebagai request HTTPS oleh user agent. Hop plaintext tidak pernah menjadi bagian transaksi.
Kebijakan hanya diterima melalui transport aman
Field Strict-Transport-Security yang diterima melalui HTTP tidak boleh membentuk kebijakan HSTS. Menerima kebijakan dari respons plaintext yang tidak terautentikasi akan memungkinkan perantara aktif mengubah state keamanan yang justru hendak dilindungi.
Field yang umum berbentuk seperti ini:
Strict-Transport-Security: max-age=31536000; includeSubDomainsmax-age menetapkan masa berlaku kebijakan yang disimpan user agent dalam satuan detik. Setiap respons aman yang valid dapat memperbarui masa tersebut. includeSubDomains memperluas kebijakan ke subdomain di bawah host HSTS sesuai aturan pemrosesan RFC 6797.
Desain ini menciptakan kondisi bootstrap yang penting: HSTS biasa melindungi kunjungan setelah kebijakan aman terbentuk, tetapi tidak dapat mengamankan secara retroaktif kontak HTTP pertama dari client yang belum memiliki state HSTS yang relevan.
Data preload mengubah sumber bootstrap
Mekanisme preload browser menangani celah kontak pertama dengan mendistribusikan informasi kebijakan HSTS tertentu bersama user agent, alih-alih menunggu respons situs. Untuk host yang masuk preload, enforcement HTTPS dapat tersedia sebelum kunjungan jaringan pertama.
Preload secara operasional berbeda dari penerimaan header HSTS. Mekanisme ini bergantung pada state yang didistribusikan browser serta proses penambahan dan penghapusan pada program preload. Server tidak dapat menganggap pengiriman header langsung memasukkan domainnya ke daftar bawaan setiap pengguna.
Perbedaan ini juga memengaruhi rollback. max-age yang pendek dapat membuat state dinamis kedaluwarsa, sedangkan penghapusan preload bergantung pada data browser baru yang sampai ke client. Deployment yang meminta status preload karena itu memerlukan HTTPS yang bertahan pada seluruh namespace terkait, bukan sekadar tersedia selama periode migrasi.
Cakupan subdomain mengubah radius kegagalan
Tanpa includeSubDomains, state HSTS untuk example.com tidak otomatis menerapkan kebijakan yang sama pada setiap host turunannya. Kondisi ini dapat menyisakan subdomain lama yang masih dapat dicapai melalui HTTP meskipun parent menggunakan HTTPS secara konsisten.
Dengan includeSubDomains, batas kebijakan menjadi lebih luas. Hal ini dapat menutup jalur downgrade di seluruh namespace, tetapi juga berarti kegagalan HTTPS pada subdomain yang tercakup tidak dapat diatasi dengan fallback ke HTTP. Perilaku tersebut memang disengaja: HSTS memperlakukan keamanan transport sebagai batasan, bukan preferensi.
Konsekuensi deployment-nya konkret. Cakupan sertifikat, terminasi TLS, host lama, dan subdomain yang didelegasikan perlu diperiksa sebelum kebijakan diperluas. Service yang terlupakan di bawah namespace dapat menjadi tidak dapat diakses setelah client menyimpan state HSTS yang berlaku.
Error sertifikat tetap merupakan error
HSTS tidak membuat sertifikat yang tidak valid menjadi valid. Perannya adalah mewajibkan transport aman dan membatasi perilaku user agent saat terjadi kegagalan TLS. Host dengan sertifikat kedaluwarsa, tidak cocok, atau tidak memenuhi autentikasi tetap memiliki masalah sertifikat.
Pemisahan ini menjaga model trust tetap konsisten. HSTS menentukan bahwa HTTP bukan jalur fallback yang dapat diterima. Validasi sertifikat TLS menentukan apakah peer HTTPS memenuhi persyaratan autentikasi user agent. Satu kontrol tidak menggantikan kontrol lainnya.
HSTS adalah kebijakan transport persisten di sisi client
Properti penting HSTS bukan header respons itu sendiri. Nilainya berada pada transisi state akibat kebijakan yang diterima secara aman dan enforcement di sisi client pada koneksi berikutnya sebelum traffic plaintext keluar dari browser.
Timing tersebut membedakan HSTS dari aturan redirect. Redirect dapat mengarahkan traffic yang sudah mencapai server. State HSTS yang tersimpan dapat mencegah request tidak aman dikirim sejak awal. Data preload dapat memperluas sifat ini ke client yang belum pernah menghubungi situs, dengan konsekuensi jalur rollback operasional yang lebih lambat.
Batas tersebut karena itu bersifat temporal sekaligus kriptografis: kebijakan aman yang terbentuk lebih awal mengendalikan pilihan transport untuk koneksi berikutnya.
Referensi: RFC 6797 — HTTP Strict Transport Security