HSTS Mengunci Policy HTTPS di Browser

Redirect HTTPS baru bekerja setelah request HTTP mencapai server. Request cleartext pertama itu tetap menjadi titik lemah: penyerang pada jaringan yang mampu mengubah traffic dapat mengganggu koneksi sebelum browser menerima redirect.

HTTP Strict Transport Security, atau HSTS, memindahkan sebagian keputusan tersebut ke browser. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, user agent yang sesuai menyimpan policy untuk host. Selama policy masih berlaku, navigasi HTTP berikutnya ke host tersebut diubah menjadi HTTPS sebelum koneksi HTTP dibuat.

https://example.test
        |
        v
Strict-Transport-Security: max-age=31536000
        |
        v
browser menyimpan policy HSTS
        |
        v
http://example.test/path
        |
        v
https://example.test/path

Header ini tidak membuat sertifikat TLS menjadi opsional, tidak memperbaiki error sertifikat, dan tidak mengenkripsi traffic yang tidak pernah mencapai HTTPS. Fungsinya lebih sempit: setelah policy terbentuk, browser tidak lagi menganggap HTTP cleartext sebagai transport yang dapat diterima untuk host tersebut.

Policy hanya diterima melalui HTTPS

Browser harus mengabaikan Strict-Transport-Security yang diterima melalui HTTP tidak aman. Jika header dari HTTP diterima, penyerang dapat menyisipkan policy transport berumur panjang untuk host yang tidak semestinya.

Aturan ini menciptakan celah bootstrap. Pada browser yang belum memiliki state HSTS, user yang mengetik hostname tanpa skema masih dapat memulai dari HTTP. Server dapat mengarahkan request ke HTTPS lalu mengirim HSTS, tetapi penyerang aktif pada jalur pertama dapat mengganggu koneksi sebelum response aman menetapkan policy.

Perbedaannya terlihat pada dua alur berikut:

kunjungan pertama tanpa cached policy:
HTTP -> redirect -> HTTPS -> HSTS disimpan

kunjungan berikutnya saat policy aktif:
URL HTTP -> rewrite HTTPS lokal -> HTTPS

HSTS melindungi koneksi berikutnya setelah policy tepercaya diterima. Preload menangani kasus kontak awal melalui mekanisme terpisah.

max-age menentukan masa policy

Directive wajib HSTS adalah max-age, dengan nilai dalam detik:

Strict-Transport-Security: max-age=31536000

Browser mencatat waktu kedaluwarsa relatif terhadap saat response aman diproses. Response HSTS valid berikutnya dapat memperbarui masa tersebut.

Nilai panjang mengurangi kemungkinan policy kedaluwarsa di antara kunjungan, tetapi juga membuat kesalahan konfigurasi bertahan lebih lama. Sebelum memasang masa panjang, host perlu memiliki HTTPS yang andal, sertifikat valid, dan rencana pemulihan yang tidak bergantung pada HTTP biasa.

Server dapat meminta penghapusan policy HSTS dinamis dengan mengirim header berikut melalui HTTPS:

Strict-Transport-Security: max-age=0

Instruksi itu tetap memerlukan koneksi HTTPS yang berhasil. Jika host sama sekali tidak dapat menyelesaikan TLS, HTTP biasa tidak dapat menghapus policy.

includeSubDomains memperluas boundary

Penambahan includeSubDomains menerapkan policy ke subdomain sekaligus host yang mengirimkannya:

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

Untuk policy pada example.test, cakupan dapat mencakup host seperti api.example.test dan old.example.test. Cakupan tersebut aman digunakan hanya ketika setiap nama yang mungkin diakses user sudah siap melayani HTTPS.

Ini adalah boundary deployment, bukan directive kosmetik. Subdomain lama yang masih bergantung pada HTTP dapat menjadi tidak dapat diakses pada browser yang menegakkan policy parent. Inventaris host, cakupan sertifikat, kepemilikan DNS, dan endpoint legacy perlu masuk ke review rollout sebelum directive diaktifkan pada parent domain.

Subdomain juga dapat menetapkan policy HSTS sendiri. Cakupan parent dan policy khusus host dapat berjalan bersamaan sesuai aturan pemrosesan pada spesifikasi HSTS.

HSTS mengubah penanganan error sertifikat

Saat HSTS berlaku, user agent harus menghentikan koneksi pada error TLS yang tercakup policy, bukan menawarkan jalur click-through yang melewati warning.

Perilaku tersebut merupakan bagian penting dari mekanisme ini. Jika user dapat mengabaikan error sertifikat dan tetap melanjutkan, penyerang aktif dapat menyajikan sertifikat tidak valid lalu mengandalkan user untuk melewati aturan transport secara manual.

Konsekuensinya, kegagalan sertifikat menjadi lebih mahal secara operasional. Sertifikat kedaluwarsa, hostname mismatch, atau trust chain yang rusak dapat menjadi hard failure pada host HSTS. Renewal dan monitoring sertifikat karena itu menjadi bagian dari operasi HSTS.

Preload menutup celah yang berbeda

Browser utama dapat membawa HSTS preload list. Domain yang diterima ke daftar tersebut diperlakukan sebagai HSTS sebelum browser menerima header dari situsnya.

Preload dapat menutup celah bootstrap pada kunjungan pertama, tetapi bukan sekadar nilai header yang lebih kuat. Penambahan dan penghapusan domain merupakan proses distribusi browser dengan persyaratan dan jeda tersendiri. Operator domain perlu memperlakukan preload sebagai komitmen bahwa HTTPS bekerja pada seluruh scope yang diwajibkan, terutama saat subdomain ikut tercakup.

Token preload lazim muncul pada header deployment:

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

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

HSTS tidak menggantikan redirect HTTPS

Browser yang memiliki policy HSTS aktif dapat meng-upgrade URL HTTP secara lokal, tetapi server tetap perlu menangani HTTP dengan tepat. Tidak semua client menerapkan HSTS, cached policy dapat kedaluwarsa, dan automated client dapat mengikuti aturan transport yang berbeda.

Redirect tetap berguna untuk client yang mencapai endpoint HTTP. HSTS menambahkan enforcement di sisi browser setelah policy terbentuk; mekanisme ini tidak mengubah HTTP listener menjadi security boundary.

Kedua kontrol bekerja pada momen berbeda:

redirect HTTP:
request mencapai service HTTP -> server mengarahkan client ke HTTPS

policy HSTS aktif:
browser menulis ulang URL -> request HTTP tidak dikirim

Rollout perlu mengecilkan failure surface lebih dulu

Rollout yang hati-hati dimulai dari HTTPS yang sudah berfungsi dan max-age yang moderat, lalu memperpanjang masa setelah renewal sertifikat, redirect, subdomain, dan monitoring sudah teruji. includeSubDomains baru layak ditambahkan ketika namespace yang tercakup siap. Preload perlu keputusan terpisah karena rollback bergantung pada update daftar yang sampai ke rilis browser.

HSTS adalah konfigurasi ringkas dengan state client yang bertahan. Nilai keamanannya berasal dari pemindahan keputusan HTTPS ke titik sebelum request jaringan, sedangkan risiko operasionalnya berasal dari properti yang sama. Deployment yang kokoh memastikan domain mampu mempertahankan HTTPS untuk seluruh scope dan masa yang diminta agar browser menegakkannya.

Referensi

Cybersecurity HTTPS HSTS Keamanan Web