Cara menyediakan HSTS tanpa menyebabkan anda terkunci keluar

HSTS mudah sehinggalah ia tidak lagi begitu

HTTP Strict Transport Security, biasanya dipendekkan kepada HSTS, memberitahu pelayar: “untuk laman ini, sentiasa gunakan HTTPS.” Setelah pelayar menerima pengepala tersebut melalui sambungan HTTPS yang sah, ia mengingati peraturan itu untuk tempoh yang anda tetapkan.

Itu berguna. Ia menghalang serangan penurunan taraf protokol, mengurangkan permintaan tidak selamat yang tidak disengajakan, dan mengelakkan detik janggal apabila pengguna menaip example.com lalu menyentuh HTTP biasa seketika sebelum dialihkan.

Ia juga melekat. Jika anda menerbitkan dasar HSTS yang salah, pelayar mungkin terus menguatkuasakannya lama selepas anda membuang pengepala itu daripada pelayan anda. Begitulah pasukan menyebabkan diri mereka terkunci keluar: bukan semestinya daripada panel pentadbir sendiri, tetapi daripada pelayar pengguna, subdomain, sistem staging, endpoint legasi, dan perkhidmatan terlupa yang belum bersedia untuk HTTPS paksa.

Matlamatnya bukan untuk mengelakkan HSTS. Matlamatnya ialah melaksanakannya seperti migrasi, bukan seperti suis togol.

Apa yang sebenarnya dilakukan oleh pengepala HSTS

Pengepala HSTS biasa kelihatan seperti ini:

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

Ia mempunyai tiga bahagian penting:

• max-age: berapa lama, dalam saat, pelayar harus menguatkuasakan HTTPS untuk hos ini.
• includeSubDomains: sama ada peraturan itu turut digunakan pada setiap subdomain.
• preload: isyarat bahawa anda mahu domain dimasukkan dalam senarai preload pelayar.

Pelayar hanya mempercayai pengepala ini apabila ia menerimanya melalui HTTPS yang sah. Jika sijil tidak sah, tamat tempoh, atau tidak sepadan, pelayar tidak sepatutnya menerima dasar HSTS baharu daripada respons tersebut.

Setelah dasar disimpan, percubaan seterusnya untuk melawat http://example.com akan dinaik taraf oleh pelayar kepada https://example.com sebelum permintaan dihantar. Itulah kemenangan privasi: permintaan tidak selamat tidak pernah meninggalkan peranti.

Senario terkunci keluar yang perlu dielakkan

Kebanyakan kegagalan HSTS bukan disebabkan oleh laman web utama. Ia berlaku di bahagian pinggir.

1. Subdomain yang terlupa belum bersedia untuk HTTPS

includeSubDomains kedengaran kemas, tetapi ia mutlak. Jika anda menetapkannya pada example.com, ia terpakai kepada:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• apa-apa lagi di bawah domain tersebut

Jika mana-mana hos tersebut tidak dapat menyediakan HTTPS yang sah, pengguna yang mempunyai dasar HSTS dalam cache tidak akan dapat mencapainya melalui HTTP.

2. Sijil tamat tempoh

Tanpa HSTS, pengguna kadangkala mengklik lalu amaran sijil. Itu bukan amalan keselamatan yang baik, tetapi ia berlaku.

Dengan HSTS, pelayar moden tidak membenarkan pintasan mudah terhadap ralat sijil untuk hos tersebut. Itulah tujuannya. Ini juga bermakna pembaharuan sijil perlu membosankan, dipantau, dan diuji.

3. Staging atau alat dalaman berada di bawah domain produksi

Meletakkan alat dalaman di bawah *.example.com boleh menjadi menyakitkan apabila domain induk menggunakan includeSubDomains. Jika alat tersebut menggunakan sijil self-signed, pihak berkuasa sijil persendirian, konfigurasi TLS lama, atau tiada HTTPS langsung, HSTS akan mendedahkan jalan pintas itu.

Inilah salah satu sebab banyak pasukan menyimpan sistem dalaman dan eksperimental di bawah domain berasingan yang mempunyai dasar keselamatannya sendiri.

4. Preload dianggap sebagai kotak semak rutin

HSTS preload bukan sekadar satu lagi arahan. Ia bermakna domain anda boleh dihantar di dalam pelayar sebagai HTTPS sahaja sebelum mana-mana pengguna pernah melawat laman anda.

Itu menutup jurang “lawatan pertama”, tetapi jauh lebih sukar untuk dibatalkan. Pembuangan daripada senarai preload boleh mengambil masa berminggu-minggu atau berbulan-bulan untuk sampai kepada pengguna, bergantung pada kitaran keluaran pelayar. Preload sesuai untuk domain yang stabil dan matang. Ia tidak sesuai untuk laman yang masih mencari inventori subdomainnya.

Pelan pelancaran yang selamat

Step 1: Audit setiap hostname yang anda kawal

Sebelum menetapkan includeSubDomains, senaraikan setiap hostname di bawah domain tersebut. Rekod DNS ialah permulaan, tetapi bukan keseluruhan cerita. Semak konfigurasi CDN, papan pemuka hosting, hostname berkaitan e-mel, alat pemasaran lama, storage buckets, dan dokumentasi dalaman.

Untuk setiap hostname, jawab:

• Adakah ia menyediakan HTTP, HTTPS, atau kedua-duanya?
• Adakah sijil HTTPS sah dan diperbaharui secara automatik?
• Adakah ia mengalihkan HTTP ke HTTPS dengan bersih?
• Adakah ia dimaksudkan untuk awam?
• Adakah ia masih diperlukan?

Jika pasukan anda sudah mempunyai tabiat menyahpepijat pengepala produksi, ini sesuai diletakkan bersama semakan redirect dan pengepala. Kami telah membincangkan aliran kerja itu dalam kit alat kecil untuk menyahpepijat redirect dan pengepala HTTP dalam produksi.

Step 2: Betulkan HTTPS sebelum menambah HSTS

HSTS tidak menjadikan persediaan HTTPS yang rosak selamat. Ia hanya menjadikan HTTPS wajib.

Sebelum mengaktifkannya, sahkan:

• Sijil TLS meliputi hostname yang betul.
• Sijil diperbaharui secara automatik.
• HTTP mengalihkan ke HTTPS dengan satu lompatan bersih jika boleh.
• Redirect hos kanonik adalah konsisten, contohnya bukan-www ke www, atau sebaliknya.
• Aset aplikasi tidak bergantung pada URL http:// yang tidak selamat.

Mixed content kurang biasa berbanding dahulu, tetapi ia masih muncul dalam tema CMS lama, coretan analitik, media terbenam, dan laluan imej yang dikod keras.

Step 3: Mulakan dengan max-age yang sangat pendek

Jangan bermula dengan satu tahun. Mulakan dengan lima minit:

Strict-Transport-Security: max-age=300

Laksanakan itu hanya pada hostname yang anda uji, biasanya laman web produksi kanonik. Tinggalkan includeSubDomains buat masa ini.

Kemudian uji dalam pelayar sebenar dan dengan permintaan baris perintah:

curl -I https://example.com

Anda sepatutnya melihat tepat satu pengepala Strict-Transport-Security. Pengepala HSTS berganda daripada pelayan aplikasi dan CDN ialah sumber kekeliruan yang biasa. Pelayar umumnya menggunakan dasar berkesan, tetapi manusia yang menyahpepijat insiden tidak memerlukan kekaburan.

Step 4: Tingkatkan secara beransur-ansur

Jika tiada apa-apa rosak, tingkatkan tempoh secara berperingkat:

Strict-Transport-Security: max-age=86400

Kemudian:

Strict-Transport-Security: max-age=604800

Kemudian mungkin:

Strict-Transport-Security: max-age=2592000

Jadual praktikal ialah:

• 5 minit
• 1 hari
• 1 minggu
• 1 bulan
• 6 bulan atau 1 tahun

Tiada hadiah untuk tergesa-gesa. Seluruh tujuan pelancaran berperingkat ialah memberi masa kepada pemantauan, peti masuk sokongan, dan kes pinggir untuk memberitahu anda apa yang terlepas daripada senarai semak anda.

Step 5: Tambah includeSubDomains hanya selepas audit benar-benar dilakukan

Setelah setiap subdomain awam bersedia untuk HTTPS, anda boleh mempertimbangkan:

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

Inilah masa untuk bersikap konservatif. Jika satu perkhidmatan legasi masih memerlukan HTTP, jangan tambah includeSubDomains pada domain induk. Sama ada migrasikan perkhidmatan itu, pindahkannya ke domain lain, atau terima bahawa dasar HSTS anda perlu kekal lebih sempit buat masa ini.

Pengepala keselamatan harus mencerminkan realiti. Ia tidak sepatutnya digunakan sebagai poster motivasi untuk infrastruktur yang anda harap akan ada kemudian.

Step 6: Anggap preload sebagai projek berasingan

Hanya pertimbangkan preload apabila semua yang berikut benar:

• Domain dan semua subdomain menyokong HTTPS yang sah.
• HTTP mengalihkan ke HTTPS.
• Pengepala HSTS menggunakan max-age sekurang-kurangnya 31536000 saat.
• Pengepala menyertakan includeSubDomains.
• Pengepala menyertakan preload.
• Anda yakin anda tidak akan memerlukan HTTP biasa di mana-mana di bawah domain tersebut.

Pengepala yang bersedia untuk preload kelihatan seperti ini:

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

Menghantar ke senarai preload ialah komitmen jangka panjang. Jika laman itu ialah microsite kempen, domain produk sementara, atau domain dengan sempadan pemilikan yang tidak jelas, langkau sahaja.

Contoh konfigurasi

Nginx

Gunakan always supaya pengepala dihantar pada respons ralat juga:

add_header Strict-Transport-Security "max-age=300" always;

Selepas pelancaran stabil:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Dengan mod_headers diaktifkan:

Header always set Strict-Transport-Security "max-age=300"

Kemudian:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN atau platform edge

Jika CDN anda menetapkan pengepala respons, lebih baik urus HSTS di satu tempat. Jangan tetapkan satu dasar di origin dan satu lagi di edge melainkan anda mempunyai sebab yang sangat jelas.

Semak juga sama ada CDN menggunakan pengepala pada redirect, ralat cache, dan halaman ralat tersuai. Laman produksi bukan hanya respons 200 OKnya.

Cara membatalkan HSTS dengan selamat

Jika anda perlu menyahaktifkan HSTS, hantar:

Strict-Transport-Security: max-age=0

Tetapi ada perangkap: pelayar mesti berjaya mencapai laman melalui HTTPS yang sah untuk menerima pengepala itu. Jika HTTPS itu sendiri rosak, pengguna dengan dasar HSTS dalam cache tidak boleh mengambil arahan yang akan mengosongkannya.

Jadi tertib pemulihan biasa ialah:

1. Pulihkan HTTPS yang sah.
2. Hidangkan Strict-Transport-Security: max-age=0.
3. Kekalkan cukup lama supaya pengguna yang kembali menerimanya.
4. Buang atau gantikan pengepala selepas insiden diselesaikan.

Jika domain dipreload, menghidangkan max-age=0 tidak mencukupi untuk profil pelayar baharu. Anda juga perlu meminta pembuangan daripada senarai preload dan menunggu perubahan itu dihantar melalui kemas kini pelayar.

Senarai semak ujian sebelum anda melancarkan

Gunakan senarai semak ini sebelum meningkatkan max-age atau menambah includeSubDomains:

• URL HTTPS kanonik mengembalikan sijil yang sah.
• HTTP mengalihkan ke HTTPS.
• Hanya ada satu pengepala HSTS.
• Pengepala muncul pada redirect dan respons ralat jika sesuai.
• Semua subdomain awam mempunyai HTTPS yang sah.
• Pembaharuan sijil dipantau.
• Tiada sistem dalaman kritikal bergantung pada HTTP di bawah domain induk yang sama.
• Preload telah dibincangkan secara jelas, bukan ditambah kerana kebiasaan.

Lighthouse juga mungkin menandakan pengepala keselamatan yang hilang atau lemah dalam sesetengah konteks, tetapi ia tidak sepatutnya menjadi satu-satunya kaedah pengesahan anda. Jika anda menggunakannya sebagai sebahagian daripada semakan yang lebih luas, baca dapatan sebagai isyarat dan bukannya keputusan muktamad; cara fikir yang sama terpakai apabila anda membaca laporan Lighthouse tanpa panik.

<!-- tool-cta:start -->

💡 Cuba ini: Sebelum dan selepas setiap perubahan HSTS, periksa respons Strict-Transport-Security dengan Get Headers untuk mengesahkan bahawa max-age, includeSubDomains dan preload adalah seperti yang anda jangkakan.

<!-- tool-cta:end -->

Hujah privasi untuk HSTS

HSTS sering digambarkan sebagai pengepala keselamatan, dan memang begitu. Ia juga mempunyai manfaat privasi: ia mengurangkan kemungkinan permintaan pertama pengguna bocor melalui HTTP biasa pada rangkaian yang tidak dipercayai.

Itu penting pada Wi-Fi lapangan terbang, rangkaian hotel, rangkaian tetamu korporat, dan di mana-mana trafik pengguna mungkin diperhatikan atau diubah suai. Permintaan HTTP biasa boleh mendedahkan hostname, laluan, cookies tanpa flag Secure, dan butiran permintaan lain. HTTPS bukan sihir, tetapi memaksanya secara konsisten membuang satu kelas penuh kebocoran yang boleh dielakkan.

Pelaksanaan HSTS terbaik tidak menarik perhatian. Ia dilancarkan perlahan-lahan, disokong oleh sijil yang boleh dipercayai, dan cukup membosankan sehingga tiada siapa menyedarinya. Itulah tepat yang anda mahukan daripada pengepala yang mod kegagalannya boleh menjadi dramatik.