HSTS Mengunci Navigasi HTTP ke Kebijakan Origin HTTPS-Only

Browser menerima link yang diawali http:// untuk host yang sebelumnya pernah dihubungi secara aman. Tidak ada request HTTP yang keluar dari perangkat. Sebaliknya, user agent menulis ulang navigasi menjadi HTTPS berdasarkan kebijakan lokal dan langsung memulai TLS. Redirect di sisi server yang sering dikaitkan administrator dengan migrasi HTTPS tidak pernah terlibat dalam jalur request tersebut.

HTTP Strict Transport Security (HSTS), yang distandardisasi dalam RFC 6797, menghasilkan perilaku ini dengan memungkinkan host HTTPS mendeklarasikan kebijakan transport berbatas waktu. Setelah user agent yang sesuai menyimpan kebijakan tersebut, HTTP tidak aman tidak lagi menjadi pilihan transport yang diizinkan untuk request yang cocok selama masa berlaku kebijakan. Batas penting pun berpindah dari penanganan respons server ke pemilihan koneksi di sisi client.

Perbedaannya penting karena redirect baru dapat bekerja setelah koneksi HTTP lebih dahulu mengekspos request ke jaringan. HSTS dapat menghilangkan first hop cleartext itu, tetapi hanya setelah user agent memperoleh kebijakan yang valid atau memiliki state preload yang setara.

Redirect dan kebijakan transport bekerja pada waktu yang berbeda

Redirect HTTP-ke-HTTPS biasa dimulai dengan request HTTP. Server merespons dengan status redirect dan lokasi HTTPS, lalu client membuat request kedua melalui TLS. Susunan ini berguna untuk migrasi dan canonicalization, tetapi pertukaran pertama tetap dapat diintervensi pihak yang berada di jalur jaringan.

Penyerang yang menguasai jalur tersebut dapat mencegah redirect mencapai client, mengubah respons yang tidak aman, atau mempertahankan korban pada representasi HTTP yang disediakan penyerang. TLS tidak melindungi trafik yang tidak pernah mencapai TLS.

HSTS mengubah urutan tersebut untuk host HSTS yang sudah dikenal. User agent memperlakukan request tidak aman sebagai request yang tunduk pada kebijakan tersimpan dan mengubah skema URI sebelum transmisi jaringan. Endpoint HTTP karena itu bukan enforcement point keamanan untuk navigasi tersebut. Endpoint itu mungkin masih tersedia bagi client di luar pemrosesan HSTS, tetapi user agent yang sesuai dengan kebijakan aktif tidak bergantung padanya untuk mencapai HTTPS.

Sifat ini juga membedakan HSTS dari konvensi aplikasi. Server tidak dapat mengganti kebijakan client yang belum ada hanya dengan mengirim redirect yang lebih kuat. Kebijakan harus sudah tersedia ketika pemilihan transport dilakukan.

Akuisisi kebijakan memerlukan respons HTTPS yang terautentikasi

Host mendeklarasikan HSTS melalui header respons Strict-Transport-Security pada transport aman. Directive max-age menyatakan berapa detik user agent harus menganggap host sebagai known HSTS host. Directive opsional includeSubDomains memperluas kebijakan ke subdomain sesuai aturan yang ditentukan.

Header tersebut sengaja diabaikan jika diterima melalui HTTP tidak aman. Menerima kebijakan transport dari channel yang tidak terautentikasi akan memungkinkan pihak di jalur jaringan membuat atau mengubah state keamanan. Deklarasi memperoleh otoritas dari koneksi TLS terautentikasi yang membawanya.

Desain ini menghasilkan bootstrap gap. User agent yang menghubungi host untuk pertama kali belum memiliki state HSTS dinamis. Jika navigasi awal memakai HTTP, request pertama masih dapat melintasi jaringan dalam cleartext sebelum respons aman memiliki kesempatan memasang kebijakan.

Mekanisme HSTS preload menutup gap tersebut untuk domain yang berpartisipasi dengan mengirim informasi kebijakan bersama software user agent, bukan memperolehnya saat kunjungan pertama. Preload adalah mekanisme ekosistem, bukan kemampuan yang dihasilkan header RFC saja, dan persyaratan pendaftarannya dikendalikan browser atau program preload terkait. Keputusan operasional karena itu perlu membedakan HSTS yang diperoleh secara dinamis dari state preload.

Error sertifikat menjadi hard failure

HSTS bukan mekanisme untuk menerima TLS yang tidak sempurna. Nilainya bergantung pada pemindahan trafik ke HTTPS terautentikasi tanpa menyediakan jalur fallback yang tidak aman.

Untuk known HSTS host, kegagalan validasi sertifikat diperlakukan sebagai fatal dalam model HSTS. User agent tidak seharusnya membiarkan pengguna melewati warning dan melanjutkan ke koneksi yang gagal memenuhi pemeriksaan secure transport. Jika override seperti itu diizinkan, kebijakan mandatory secure transport akan berubah menjadi preferensi yang dapat dilewati tepat saat serangan berlangsung.

Konsekuensi operasionalnya penting bagi pengelolaan sertifikat. Setelah site menetapkan kebijakan HSTS berumur panjang, sertifikat kedaluwarsa, name mismatch, chain rusak, atau kegagalan validasi lain dapat menjadi hard availability event bagi client yang sesuai. Menyediakan HTTP sebagai fallback darurat tidak memulihkan akses bagi client yang kebijakan aktifnya melarang fallback tersebut.

Keuntungan keamanan dan constraint pemulihan adalah sifat yang sama dilihat dari dua sisi: client menolak downgrade ketika HTTPS tidak tersedia atau tidak valid.

Cakupan host tidak otomatis sama dengan cakupan organisasi

State HSTS dikaitkan dengan nama host DNS, dengan perilaku inheritance yang dipengaruhi includeSubDomains. Kebijakan pada example.com tanpa directive tersebut tidak otomatis melindungi api.example.com. Setiap host dapat memperoleh kebijakan sendiri, tetapi mengandalkan kunjungan pertama yang independen akan mengulang bootstrap exposure untuk setiap hostname.

Dengan includeSubDomains, kebijakan yang dideklarasikan parent dapat mencakup host di bawahnya. Ini kuat ketika organisasi mengendalikan seluruh namespace, tetapi juga mengubah subdomain terlupakan atau yang didelegasikan ke pihak luar menjadi constraint deployment. Service di bawahnya yang tidak dapat menyediakan HTTPS valid dapat menjadi tidak dapat diakses oleh client yang menerapkan kebijakan parent.

Directive tersebut karena itu dapat melintasi batas administratif ketika delegasi DNS dan kepemilikan service tidak sesuai dengan kontrol operasional parent domain. Sebelum memakai lifetime panjang dengan cakupan subdomain, namespace terkait perlu diperlakukan sebagai inventaris keamanan, bukan sekadar kumpulan aplikasi web yang sedang aktif.

Kebalikannya juga berlaku. HSTS tidak melindungi sibling domain atau registrable name yang tidak terkait hanya karena dioperasikan organisasi yang sama. Kebijakan mengikuti cakupan hostname, bukan identitas perusahaan.

Penulisan ulang port memiliki batas yang presisi

Aturan pemuatan URI HSTS juga memperhitungkan port. Ketika URI tidak aman untuk known HSTS host menggunakan port 80, user agent mengubah skema menjadi HTTPS dan memetakan port ke 443. Untuk port non-80 yang disebutkan secara eksplisit, skema berubah tetapi port dipertahankan.

Perilaku ini dapat mengungkap asumsi pada service yang memakai HTTP di port tidak biasa. HSTS tidak menyimpulkan port aman alternatif dari maksud deployment. URL seperti http://example.com:8080/ umumnya tidak diubah menjadi request ke port 443; request aman tetap diarahkan ke port eksplisit tersebut sesuai model pemrosesan yang ditentukan.

Detail ini menegaskan peran arsitektural HSTS. HSTS adalah kebijakan transport dengan aturan transformasi URI yang terdefinisi, bukan mekanisme service discovery umum.

Lifetime kebijakan sengaja membuat rollback lambat

Nilai max-age membuat HSTS bertahan pada kunjungan berikutnya. Setiap respons aman yang valid dan membawa header dapat memperbarui state tersebut. Nilai yang cukup panjang melindungi client yang kembali meski selama beberapa waktu tidak menerima deklarasi kebijakan baru.

Host dapat meminta penghapusan state HSTS dinamis dengan mengirim max-age=0 melalui koneksi aman yang valid. Ini tidak menghasilkan rollback universal seketika. Client yang tidak kembali mengunjungi host secara aman tidak dapat menerima instruksi penghapusan, dan state preload mengikuti proses terpisah dalam ekosistem user agent.

Lifetime panjang karena itu menciptakan komitmen. Nilai tersebut mengurangi kemungkinan kebijakan kedaluwarsa selama host tidak dikunjungi, tetapi juga meningkatkan ketergantungan pada HTTPS yang selalu benar. Kebijakan harus diperlakukan sebagai state client persisten, bukan header respons yang efeknya hilang ketika satu baris konfigurasi server dihapus.

Kebijakan yang tersimpan juga berarti dua pengguna dapat melihat perilaku transport berbeda untuk URL yang sama. Satu mungkin memiliki state HSTS aktif, sementara yang lain melakukan kontak pertama. Troubleshooting yang mengabaikan kebijakan client dapat salah mengaitkan perbedaan ini dengan redirect, DNS, atau routing di sisi server.

HSTS mempersempit downgrade exposure tetapi tidak mengamankan aplikasi

HSTS menangani kelas tertentu dari transport downgrade dan perilaku navigasi tidak aman. HSTS tidak mengotorisasi pengguna, mencegah cross-site scripting, memvalidasi data aplikasi, menghentikan kompromi server, atau menggantikan autentikasi sertifikat. HSTS juga tidak membuat protokol plaintext lain menjadi aman hanya karena memakai hostname yang sama.

Sifat terkuatnya bersifat temporal dan lokal: setelah kebijakan valid tersedia, user agent dapat menolak HTTP sebelum penyerang pada jalur jaringan saat ini memperoleh pertukaran HTTP untuk dimanipulasi. Kondisi bootstrap yang tersisa sama pentingnya. Kebijakan dinamis tidak dapat secara retroaktif melindungi request tidak aman yang mendahului akuisisinya.

Batas ini menjaga HSTS tetap berguna tanpa mengubahnya menjadi jaminan yang lebih luas. Mekanisme tersebut mengubah state host yang diingat menjadi keputusan transport HTTPS-only, dengan trade-off berupa ketahanan terhadap downgrade di satu sisi serta tuntutan lebih ketat pada ketersediaan sertifikat, disiplin namespace, dan constraint rollback di sisi lain. Konsekuensi tersebut bukan detail deployment sampingan; itulah bentuk operasional dari kebijakannya.