HSTS Mengikat Kebijakan HTTPS ke Hostname

HTTPS melindungi pertukaran HTTP setelah koneksi aman terbentuk dan terautentikasi. Ada persoalan terpisah sebelum titik itu: pengguna dapat mengetik hostname tanpa skema, mengikuti link http://, atau mencapai endpoint HTTP yang melakukan redirect sebelum browser memiliki kebijakan transport untuk situs tersebut.

HTTP Strict Transport Security (HSTS) menangani transisi itu. Server HTTPS mengirim header response Strict-Transport-Security, lalu user agent yang sesuai menyimpan kebijakan untuk host tersebut. Selama kebijakan masih aktif, request HTTP yang cocok diubah menjadi HTTPS sebelum request tanpa enkripsi dikirim ke jaringan.

Karena itu, HSTS adalah state yang disimpan user agent, bukan pengaturan cipher TLS dan bukan aturan redirect di server.

Kebijakan datang melalui HTTPS yang terautentikasi

Response yang umum berisi:

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

max-age menyatakan, dalam detik, berapa lama user agent menyimpan kebijakan sejak header diterima. includeSubDomains memperluas kebijakan ke subdomain di bawah host HSTS.

Header hanya diterima ketika datang melalui transport aman. Salinan yang dikirim lewat HTTP biasa tidak dapat membuat atau memperbarui state HSTS. Jika hal itu diizinkan, pihak pada jalur jaringan yang mampu mengubah response HTTP dapat membuat kebijakan transport atas nama situs.

Urutannya memang dirancang seperti ini:

response HTTPS terautentikasi
        |
        | Strict-Transport-Security
        v
kebijakan HSTS tersimpan
        |
        v
navigasi HTTP berikutnya
        |
        v
request HTTPS sebelum transmisi jaringan

Response aman pertama penting karena HSTS dinamis belum berlaku sebelum user agent menyimpan kebijakan.

Upgrade terjadi sebelum request tanpa enkripsi

Redirect HTTP ke HTTPS dan HSTS dapat menghasilkan alamat akhir yang serupa di browser, tetapi batas keamanannya berbeda.

Dengan redirect, browser lebih dahulu mengirim request HTTP lalu menerima response yang menunjuk ke URL HTTPS. Request pertama itu melewati jaringan tanpa perlindungan TLS. Penyerang jaringan pada posisi yang sesuai dapat mengganggu alur sebelum redirect mencapai browser.

Dengan kebijakan HSTS aktif, user agent menulis ulang request menjadi HTTPS secara internal. Request tanpa enkripsi tidak dikirim hanya untuk memperoleh redirect.

Redirect tetap berguna bagi client yang belum memiliki state HSTS dan untuk canonicalization biasa. Namun, redirect tidak memberikan aturan transport sebelum request dikirim.

Error sertifikat tetap fatal pada HSTS

HSTS tidak membuat sertifikat yang invalid menjadi valid. Mekanisme ini memperkuat kewajiban memakai HTTPS yang terautentikasi.

Untuk host HSTS, user agent yang mengikuti RFC 6797 menghentikan koneksi ketika secure transport mengalami error, alih-alih menyediakan jalur agar pengguna dapat melanjutkan melewati masalah sertifikat. Override semacam itu akan melemahkan kebijakan transport tepat ketika autentikasi gagal.

Kebijakan ini juga tidak memilih certificate authority, merotasi sertifikat, atau memperbaiki certificate chain yang rusak. Penerbitan sertifikat dan konfigurasi TLS tetap menjadi tanggung jawab operasional yang terpisah.

includeSubDomains mengubah batas deployment

Tanpa includeSubDomains, kebijakan untuk example.com berlaku pada host tersebut sesuai aturan pencocokan HSTS. Menambahkan directive itu memperluas kebijakan ke nama DNS di bawahnya.

Perluasan ini berguna ketika setiap subdomain memang mendukung HTTPS, tetapi juga memperbesar dampak salah konfigurasi. Service lama di legacy.example.com yang hanya mendukung HTTP dapat menjadi tidak dapat diakses dari user agent yang menyimpan kebijakan parent.

Sebelum mengaktifkan kebijakan parent berumur panjang dengan includeSubDomains, tim perlu menginventarisasi subdomain. Cakupan tersebut termasuk endpoint yang kurang terlihat, seperti portal internal yang terekspos melalui DNS publik, host campaign lama, integrasi vendor, dan nama service sementara.

Child host juga dapat memiliki kebijakan HSTS sendiri. Pencarian kebijakan mengikuti aturan pencocokan host, bukan memperlakukan HSTS sebagai satu switch global pada browser.

Expiry dan penghapusan memerlukan waktu

Situs dapat meminta penghapusan kebijakan dinamis yang tersimpan dengan mengirim:

Strict-Transport-Security: max-age=0

Instruksi itu juga harus tiba melalui transport aman. Instruksi tersebut tidak dapat membantu client yang sudah tidak mampu membentuk koneksi HTTPS yang diperlukan untuk menerima header baru.

Kondisi ini menciptakan asimetri operasional. Menaikkan max-age mudah ketika HTTPS berfungsi; pemulihan dari kebijakan berumur panjang yang salah dapat sulit jika endpoint HTTPS justru rusak.

Karena itu, rollout bertahap lebih aman daripada langsung memilih durasi panjang. Operator dapat memulai dengan lifetime pendek, memverifikasi renewal sertifikat dan cakupan subdomain, lalu menaikkan lifetime setelah deployment stabil.

Preload menutup celah kontak pertama melalui mekanisme terpisah

HSTS dinamis baru dimulai setelah user agent menerima header HSTS yang valid dari host. Profile browser baru belum memiliki state tersebut, sehingga kontak pertama masih dapat diawali melalui HTTP.

Mekanisme preload browser menangani celah itu dengan membawa daftar host yang harus diperlakukan sebagai HSTS sebelum kunjungan pertama. Preload tidak dibentuk oleh RFC 6797 saja; mekanisme ini merupakan bagian dari ekosistem browser dengan persyaratan pendaftaran di luar protokol inti HSTS.

Situs yang mempertimbangkan preload perlu memperlakukannya sebagai komitmen operasional yang lebih kuat dibanding sekadar mengirim header secara dinamis. Penghapusan tidak berlangsung seketika karena versi browser yang sudah terpasang membawa salinan data preload masing-masing.

Token preload yang umum ditempatkan pada header berkaitan dengan pendaftaran preload list. Token itu bukan directive yang didefinisikan RFC 6797, dan keberadaannya saja tidak memasukkan domain ke preload list browser.

HSTS terbatas pada transport, bukan keamanan aplikasi

HSTS memblokir kelas downgrade transport tertentu bagi user agent yang memiliki kebijakan yang sesuai. Mekanisme ini tidak mencegah cross-site scripting, request forgery, cacat authorization, penanganan file yang tidak aman, kode aplikasi yang telah dikompromikan, atau pencurian credential di luar jalur transport yang dilindungi.

HSTS juga tidak dapat menjamin setiap client mengimplementasikannya. HTTP stack non-browser dapat mengabaikan header atau menerapkan kebijakan sendiri. Sistem service-to-service karena itu memerlukan persyaratan TLS eksplisit pada client dan tidak semestinya bergantung pada response header yang berorientasi browser.

Invariant yang diberikan lebih sempit: setelah user agent yang mendukung HSTS memiliki state yang berlaku, HTTP bukan lagi jalur transport yang dapat diterima untuk hostname tersebut selama lifetime kebijakan. Menjaga invariant itu bergantung pada HTTPS yang andal, sertifikat valid, cakupan subdomain yang disengaja, dan durasi kebijakan yang sesuai dengan kemampuan operator mempertahankan seluruh properti tersebut.