TLS melindungi koneksi HTTPS setelah klien memilih HTTPS dan menyelesaikan TLS handshake. Masih ada persoalan terpisah pada batas skema. Pengguna dapat mengetik hostname tanpa skema, membuka tautan lama http://, atau mencapai redirect yang dimulai melalui cleartext. Penyerang yang mampu mengganggu pertukaran HTTP pertama dapat mencoba mempertahankan browser agar tidak beralih ke HTTPS.
HTTP Strict Transport Security (HSTS), yang didefinisikan dalam RFC 6797, memindahkan keputusan tersebut ke user agent. Setelah sebuah host mengirim header Strict-Transport-Security yang valid melalui koneksi aman, user agent yang sesuai menyimpan kebijakan itu. Selama masa berlakunya, percobaan berikutnya untuk menghubungi host tersebut melalui HTTP diubah menjadi HTTPS sebelum request HTTP dikirim.
HSTS tidak memperkuat TLS. Mekanisme ini mengubah kapan HTTPS menjadi wajib dan cara klien menangani kegagalan.
Kebijakan diterima melalui HTTPS
Server dapat mengirim header seperti:
Strict-Transport-Security: max-age=31536000; includeSubDomainsmax-age adalah masa berlaku kebijakan dalam detik. includeSubDomains memperluas kebijakan dari host HSTS ke subdomainnya.
Transport yang membawa header tersebut penting. User agent tidak boleh menerima kebijakan HSTS yang dikirim melalui HTTP tidak aman. Jika diizinkan, penyerang aktif pada jalur HTTP dapat membuat atau mengubah kebijakan keamanan. Karena itu, kebijakan ditetapkan melalui koneksi HTTPS yang terautentikasi.
Respons dapat menghapus kebijakan yang sebelumnya tersimpan dengan mengirim max-age=0 melalui koneksi aman. Penghapusan tersebut tidak selalu menghilangkan perlindungan yang diwarisi dari host induk HSTS yang menggunakan includeSubDomains.
Navigasi HTTP ditulis ulang secara lokal
Setelah sebuah host dikenal sebagai host HSTS, user agent memperlakukan URI HTTP untuk host itu secara berbeda. Skema diubah menjadi HTTPS sebelum request jaringan yang tercakup kebijakan dibuat. Untuk port HTTP standar 80, URI dipetakan ke HTTPS pada port 443; port selain 80 yang ditulis secara eksplisit tetap dipertahankan ketika skema berubah.
Perubahan lokal tersebut menutup celah yang masih ada pada redirect di sisi server. Pola umum seperti:
http://example.com/ -> 301 -> https://example.com/tetap membutuhkan pertukaran HTTP cleartext pertama. Dengan kebijakan HSTS aktif, browser tidak bergantung pada redirect tersebut untuk navigasi yang tercakup.
Perbedaan ini menjadi inti HSTS. Perlindungan berasal dari state klien yang sudah tersedia sebelum request tidak aman berikutnya keluar dari perangkat.
Error sertifikat menjadi kegagalan keras
HSTS juga mengubah penanganan error TLS. Untuk host HSTS, user agent harus menghentikan koneksi ketika sertifikat TLS tidak dipercaya atau mengalami error sertifikat lain yang dicakup spesifikasi. User agent tidak boleh memberi pengguna pilihan untuk melewati error lalu tetap membuka situs.
Perilaku tersebut mencegah HSTS berubah menjadi sekadar preferensi HTTPS dengan tombol pengecualian. Koneksi HTTPS yang dipaksakan tetapi disertai peringatan sertifikat yang dapat dilewati masih memungkinkan pengguna melintasi batas autentikasi secara manual.
Aturan ini tidak menjamin bahwa setiap sertifikat yang diterima platform mewakili operator yang dimaksud pengguna. HSTS bergantung pada validasi sertifikat dan model kepercayaan milik user agent; HSTS tidak menggantikan model tersebut.
Kontak pertama tetap menjadi batas
Sebuah host tidak dapat memasang kebijakan HSTS pertamanya secara aman melalui respons HTTP. Jika pengguna belum pernah mencapai situs itu secara aman dan belum ada kebijakan yang diketahui, penyerang yang mengendalikan pertukaran HTTP pertama dapat mencoba menahan redirect menuju HTTPS.
Daftar preload browser menangani celah bootstrap ini untuk situs yang berpartisipasi dengan membawa pengetahuan mirip HSTS bersama browser, bukan menunggu header yang diamati saat runtime. Preload merupakan mekanisme ekosistem, bukan bagian dari model inti pemrosesan header RFC 6797, dan setiap program browser menetapkan persyaratan pengajuan serta penghapusannya sendiri.
Untuk deployment yang hanya mengandalkan header respons, kontak aman pertama tetap penting. Setelah kebijakan tersimpan, nilai max-age menentukan berapa lama user agent dapat menegakkannya tanpa menerima kebijakan baru.
Cakupan subdomain perlu deployment yang terencana
includeSubDomains kuat karena satu kebijakan dapat mencakup seluruh subtree. Konsekuensi operasionalnya juga ketat. Setiap hostname terdampak yang mungkin dihubungi pengguna harus mampu menyediakan HTTPS yang valid selama kebijakan warisan masih berlaku.
Pertimbangkan:
example.com
api.example.com
legacy.example.comJika example.com menetapkan HSTS dengan includeSubDomains, percobaan HTTP menuju legacy.example.com juga terkena penegakan HTTPS. Layanan lama yang tidak dapat menyelesaikan TLS secara valid dapat menjadi tidak terjangkau dari klien yang sesuai selama kebijakan itu berlaku.
Ini bukan alasan untuk menghindari cakupan subdomain; namespace perlu diinventarisasi sebelum fitur tersebut diaktifkan. Penerbitan sertifikat, terminasi TLS, hostname yang terlupakan, layanan pihak ketiga, dan rencana dekomisioning menjadi bagian dari batas deployment.
HSTS memiliki tugas yang sempit
HSTS tidak mengenkripsi DNS, mengautentikasi pengguna aplikasi, menetapkan atribut cookie, mencegah cross-site scripting, atau memperbaiki konfigurasi TLS yang lemah. HSTS juga tidak melindungi protokol lain hanya karena memakai hostname yang sama.
Tugasnya lebih sempit: setelah user agent memiliki kebijakan HSTS yang valid untuk sebuah host, HTTP bukan lagi jalur yang dapat diterima menuju host tersebut selama masa berlaku kebijakan, dan kegagalan autentikasi TLS tidak dapat dilewati pengguna pada koneksi HSTS.
State machine yang sempit itu berguna karena pilihan downgrade dihapus sebelum penyerang dapat memengaruhi pertukaran HTTP berikutnya.