HTTPS melindungi koneksi setelah klien memilih HTTPS dan menyelesaikan TLS. Pengguna yang memasukkan hostname tanpa skema, membuka bookmark http://, atau menerima tautan HTTP masih dapat memulai melalui HTTP tanpa enkripsi sebelum server mengalihkan request. HTTP Strict Transport Security (HSTS), yang didefinisikan dalam RFC 6797, memindahkan keputusan pengalihan tersebut ke user agent setelah origin menetapkan kebijakan melalui koneksi aman.
Kebijakan HSTS merupakan state yang disimpan klien. Setelah diterima, state ini mengubah perilaku navigasi dan koneksi berikutnya untuk host yang tercakup sampai kebijakan kedaluwarsa atau diganti.
Kebijakan hanya diterima melalui HTTP yang aman
Server mendeklarasikan HSTS melalui header respons Strict-Transport-Security. Kebijakan dasar dapat berbentuk:
Strict-Transport-Security: max-age=31536000max-age adalah jumlah detik selama user agent memperlakukan host sebagai known HSTS host. Respons yang diterima melalui HTTP tidak aman tidak boleh menetapkan atau memperbarui state ini. Jika header dari kanal tanpa autentikasi diterima, pihak on-path dapat membuat state kebijakan tanpa autentikasi server terlebih dahulu.
Kebijakan juga dapat mencakup subdomain:
Strict-Transport-Security: max-age=31536000; includeSubDomainsDengan includeSubDomains, kebijakan berlaku pada host pengirim dan nama DNS di bawahnya sesuai aturan pemrosesan RFC 6797. Operator perlu memperhitungkan setiap layanan yang terdampak sebelum mengaktifkan directive ini pada domain induk.
Known HSTS host ditulis ulang sebelum akses jaringan
Untuk known HSTS host, user agent yang sesuai mengubah URI HTTP tidak aman menjadi URI HTTPS sebelum mengirim request. Mekanisme ini berbeda secara penting dari redirect HTTP 301 atau 308: request HTTP awal tanpa enkripsi tidak dikirim untuk memperoleh redirect.
Perbedaan tersebut menutup celah downgrade setelah state HSTS tersedia. Penyerang aktif pada jalur jaringan tidak dapat sekadar menahan redirect HTTP-ke-HTTPS dari server karena user agent tidak lagi bergantung pada redirect itu untuk host yang tercakup.
HSTS tidak mengenkripsi DNS dengan sendirinya, tidak mengautentikasi sembarang jawaban DNS, dan tidak menggantikan validasi sertifikat TLS. Koneksi HTTPS yang terbentuk tetap harus memenuhi aturan autentikasi TLS milik user agent.
Error sertifikat menjadi kegagalan keras
HSTS sengaja menerapkan perilaku ketat ketika autentikasi TLS gagal. Untuk known HSTS host, user agent harus menghentikan koneksi pada error sertifikat yang dicakup spesifikasi, bukan menawarkan opsi biasa untuk melewati peringatan.
Perilaku ini penting karena peringatan sertifikat yang dapat dilewati akan melemahkan kebijakan. Jika penyerang dapat memicu error sertifikat, pengguna dapat terdorong dari koneksi TLS terautentikasi ke state tanpa autentikasi yang diterima secara manual.
Kebijakan tidak membuat sertifikat yang tidak valid menjadi valid. Yang berubah adalah penanganan kegagalan: akses diblokir alih-alih menyerahkan pengecualian autentikasi kepada pengguna.
Celah kontak pertama tetap ada
Host yang belum pernah memberikan state HSTS kepada user agent tertentu tidak memiliki kebijakan HSTS lokal pada klien tersebut. Jika kontak pertama pengguna dimulai melalui HTTP, pihak aktif on-path dapat mengganggu koneksi sebelum browser menerima header HSTS yang valid melalui HTTPS.
Ini adalah batas bootstrap utama HSTS biasa. Header melindungi kontak berikutnya setelah kebijakan diperoleh melalui kanal aman; header tersebut tidak dapat melindungi request tanpa enkripsi yang sudah terjadi sebelumnya.
Nilai max-age yang panjang mengurangi frekuensi state yang sudah terbentuk menjadi kedaluwarsa, tetapi tidak menghapus kondisi kontak pertama pada profil klien atau perangkat baru.
Preload memindahkan state bootstrap ke klien
Vendor browser dapat mendistribusikan daftar preload HSTS berisi domain yang diperlakukan sebagai HSTS host sebelum kontak jaringan apa pun. Preload menangani celah bootstrap bagi nama yang tercantum karena klien sudah memiliki state kebijakan sejak awal.
Program preload merupakan mekanisme operasional, bukan directive header HSTS baru yang didefinisikan RFC 6797. Proses preload browser umumnya memiliki syarat pengajuan dan penghapusan tersendiri. Operator situs perlu memperlakukan pendaftaran preload sebagai keputusan deployment yang tahan lama karena penghapusan dapat memerlukan waktu untuk tersebar melalui rilis browser.
Token preload lazim dikirim dalam Strict-Transport-Security sebagai sinyal bagi ekosistem preload, tetapi RFC 6797 tidak menetapkan semantik pemrosesan HSTS untuk token tersebut. Perilaku preload user agent berasal dari kebijakan browser dan data yang didistribusikan bersama browser.
includeSubDomains memperluas domain kegagalan
Kebijakan pada domain induk dengan includeSubDomains dapat mengamankan namespace yang luas, tetapi kesiapan HTTPS di seluruh namespace tersebut juga menjadi satu batas operasional. Subdomain terlupakan yang hanya melayani HTTP dapat menjadi tidak dapat diakses pada user agent yang menyimpan state HSTS dari domain induk.
Risiko yang sama berlaku pada nama internal atau legacy yang masih dapat dijangkau melalui DNS publik di bawah domain induk yang tercakup. HSTS tidak menilai maksud organisasi; hubungan hostname menentukan cakupan.
Rollout bertahap dapat memakai max-age pendek terlebih dahulu, memverifikasi penerbitan sertifikat dan perilaku HTTPS pada namespace yang dituju, lalu meningkatkan durasinya. Pendekatan ini memperpendek waktu pemulihan dari kesalahan konfigurasi awal, tetapi tidak menggantikan inventaris dan pengujian.
HSTS bukan kebijakan keamanan konten
HSTS bekerja pada pemilihan transport dan penanganan kegagalan TLS untuk host yang tercakup. HSTS tidak mengatur sumber script, frame ancestor, tujuan form, atau izin lain pada tingkat dokumen. Kontrol tersebut berada pada mekanisme seperti Content Security Policy.
HSTS juga tidak memaksa setiap resource tertanam di web memakai HTTPS. Cakupan mengikuti aturan host HSTS. Sebuah halaman masih dapat merujuk host lain yang tidak memiliki kebijakan HSTS; aturan keamanan browser yang terpisah dapat memengaruhi resource tersebut.
Batas ini perlu tetap eksplisit agar HSTS tidak dianggap menyediakan proteksi yang sebenarnya berasal dari kontrol lain.
Masa berlaku kebijakan menjadi bagian dari batas keamanan
Setiap respons HSTS yang valid dapat memperbarui waktu kedaluwarsa yang tersimpan. Host dapat menonaktifkan state HSTS berikutnya dengan mengirim max-age=0 melalui koneksi aman, mengikuti pemrosesan user agent dan status preload yang terpisah.
Jalur keluar ini berguna saat dekomisioning terkontrol, tetapi juga berarti kontinuitas sertifikat dan HTTPS penting selama masa kebijakan. Jika host dikonfigurasi dengan kebijakan panjang lalu kehilangan kemampuan menyajikan TLS yang dapat diterima, klien dengan state HSTS aktif tidak dapat kembali ke HTTP sebagai jalur pemulihan.
HSTS dengan demikian mengubah HTTPS dari transport yang diutamakan menjadi persyaratan yang ditegakkan klien selama periode cakupan. Nilainya berasal dari komitmen berbasis state tersebut: setelah kebijakan terautentikasi diterima, HTTP tanpa enkripsi dan kegagalan sertifikat yang dilewati pengguna tidak lagi menjadi jalur fallback bagi host yang dilindungi.