HSTS Memaksa HTTPS Setelah Origin Aman Menetapkan Kebijakan

HTTPS melindungi pertukaran HTTP setelah koneksi aman digunakan. Pengguna masih dapat mengetik hostname tanpa scheme, mengikuti link http://, atau membuka aplikasi yang mengalihkan HTTP ke HTTPS. Request HTTP awal itu terjadi sebelum redirect biasa dapat memindahkan browser ke TLS.

HTTP Strict Transport Security (HSTS) memindahkan keputusan redirect ke user agent. Sebuah host mengirim header response Strict-Transport-Security melalui HTTPS. Setelah browser menerima kebijakan tersebut, percobaan akses berikutnya ke host yang tercakup melalui HTTP diubah menjadi HTTPS sebelum request HTTP yang tidak aman dikirim.

Kebijakan diterima melalui response aman

Header yang umum memiliki directive wajib max-age:

Strict-Transport-Security: max-age=31536000

max-age dinyatakan dalam detik. Nilai ini menentukan berapa lama host tetap tercatat sebagai known HSTS host sejak kebijakan diterima atau diperbarui.

Header diabaikan ketika diterima melalui HTTP biasa. Jika kebijakan HSTS dapat diterima dari response HTTP tanpa autentikasi, pihak on-path dapat membuat atau mengubah kebijakan transport sebelum TLS menetapkan identitas server.

Browser yang sudah memiliki kebijakan HSTS aktif tidak bergantung pada redirect HTTP dari server untuk navigasi yang tercakup. Browser melakukan upgrade secara lokal lalu menerapkan validasi sertifikat HTTPS seperti biasa.

HSTS mengubah perilaku saat terjadi kegagalan

Redirect HTTP ke HTTPS adalah response aplikasi. Jika koneksi pertama memakai HTTP, penyerang on-path dapat mengganggu pertukaran sebelum response tersebut mencapai browser.

HSTS menutup peluang downgrade itu untuk host yang kebijakannya sudah tersimpan. HSTS juga mengubah penanganan error sertifikat. Untuk host HSTS, user agent harus menghentikan koneksi pada error TLS yang tercakup model pemrosesan HSTS, bukan menawarkan jalur agar pengguna meneruskan koneksi melalui peringatan sertifikat.

Sifat ketat ini memang disengaja. Site dengan sertifikat kedaluwarsa, tidak cocok dengan hostname, atau tidak dapat diterima karena alasan lain dapat menjadi tidak dapat diakses oleh client yang menyimpan kebijakan HSTS sampai konfigurasi TLS diperbaiki atau kebijakan yang berlaku berakhir.

includeSubDomains memperluas batas

Sebuah host dapat memperluas HSTS ke subdomain:

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

Dengan includeSubDomains, kebijakan berlaku pada host dan hostname turunannya. Pilihan ini tepat hanya ketika semua nama tersebut dapat melayani HTTPS dengan benar selama masa berlaku kebijakan.

Sebagai contoh, HSTS pada example.com dengan includeSubDomains memengaruhi nama di bawah host tersebut. Service lama pada old.example.com yang masih bergantung pada HTTP dapat berhenti berfungsi di browser yang membawa kebijakan itu.

Directive ini merupakan komitmen operasional, bukan sekadar flag hardening. Inventaris DNS, cakupan sertifikat, reverse proxy, host yang didelegasikan ke pihak ketiga, dan subdomain yang jarang dipakai perlu masuk dalam pemeriksaan deployment.

Celah kontak pertama tetap ada

Browser tanpa state HSTS tersimpan dapat membuat request HTTP awal. Server tidak dapat melindungi secara retroaktif request yang sudah melintasi jaringan dalam bentuk cleartext.

Ini merupakan batas kontak pertama dari HSTS yang dikirim secara dinamis. Site biasanya menggabungkan HSTS dengan redirect HTTP ke HTTPS agar client tanpa kebijakan tersimpan dipindahkan ke HTTPS ketika pertukaran HTTP pertama mencapai server yang sah.

Setelah response HTTPS yang valid menetapkan HSTS, request berikutnya yang tercakup memperoleh perilaku upgrade di browser sampai kebijakan berakhir atau diganti.

Preload dapat menutup celah kontak pertama dinamis

Browser utama dapat membawa HSTS preload list. Host yang tercantum dalam daftar tersebut diperlakukan sebagai HSTS host sebelum mengirim header runtime ke profil browser itu.

Preload merupakan mekanisme distribusi terpisah, bukan arti tambahan dari response header. Pendaftaran memiliki persyaratan operasional, sedangkan penghapusan tidak menjadi rollback seketika pada setiap browser yang sudah terpasang. Domain perlu siap mempertahankan HTTPS pada seluruh scope yang diminta sebelum menjadikan preload sebagai langkah deployment.

Token preload lazim muncul pada header domain yang mengajukan status preload:

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

Token tersebut sendiri tidak memasukkan domain ke preload list browser. Inklusi bergantung pada program preload dan proses distribusi browser.

Penghapusan kebijakan memiliki jeda yang disengaja

Server dapat mengirim:

Strict-Transport-Security: max-age=0

Melalui koneksi HTTPS yang valid, nilai ini meminta user agent menghapus kebijakan HSTS dinamis milik host. Tindakan itu tidak menjamin penghapusan langsung terhadap kebijakan yang diwarisi dari parent host melalui includeSubDomains, dan juga tidak langsung menghapus domain dari data preload browser.

Perbedaan tersebut penting saat rollback. State HSTS berada pada client, sehingga perubahan konfigurasi server saja tidak menghapus kebijakan yang sudah tersimpan pada browser yang belum menerima response aman terbaru.

Nilai max-age yang lebih pendek berguna pada rollout awal karena membatasi durasi kesalahan. Setelah cakupan HTTPS dan operasi sertifikat stabil, masa berlaku dapat dinaikkan secara terencana.

HSTS adalah kebijakan transport, bukan otorisasi aplikasi

HSTS membatasi scheme yang dipakai browser untuk host yang tercakup. Mekanisme ini tidak mengautentikasi pengguna aplikasi, mengotorisasi request, mencegah cross-site request forgery, menentukan kebijakan eksekusi konten, atau menggantikan atribut cookie yang aman.

HSTS juga tidak membuat origin HTTPS yang sudah dikompromikan menjadi tepercaya. Jika penyerang secara sah mengendalikan endpoint server atau memperoleh kendali di dalam trust boundary aplikasi, pemaksaan HTTPS tidak memperbaiki kompromi tersebut.

Peran mekanisme ini sempit: setelah kebijakan ditetapkan, browser yang mendukung HSTS dicegah memilih HTTP yang tidak aman untuk host yang tercakup, sementara kegagalan TLS yang relevan dibuat tidak dapat dilewati. Batas yang jelas ini membuat keputusan deployment lebih terarah, terutama ketika includeSubDomains dan preload memperluas durasi serta scope komitmen.