Makluman dan skop
Sebuah perkhidmatan perusahaan mahu klien berkunci sah mengakses sumber terpilih tanpa membiarkan klien yang tidak disahkan menyiasat kewujudannya melalui respons atau cabaran 401. Pasukan sedang mempertimbangkan IETF RFC 9729, sebuah RFC Standards Track Februari 2025. Skim ini menggunakan pengeksport bahan penguncian TLS untuk mencipta input tandatangan terikat sambungan dan menghantar bukti dalam Authorization: Concealed.
Reka bentuk penggunaan klien, get laluan pinggir, dan origin. Terangkan output pengeksport 48-bait, parameter pengesahan, keperluan versi TLS, penggunaan semula sambungan, pembatalan kunci, sandaran legasi, dan ujian pelancaran. Sertakan ralat (erratum) 2026 yang disahkan dalam audit pelaksanaan.
Perkara yang dinilai oleh penemu bual
Penemu bual mahu anda membezakan antara menyembunyikan keupayaan pengesahan dan menjamin kesegaran: RFC 9729 tidak menghantar cabaran, tetapi kesegaran bukti dibatasi oleh jangka hayat sambungan TLS asas.
Jawapan yang mantap merangkumi pemajuan selamat Concealed-Auth-Export, kunci khusus protokol, pengasingan pemultipleksan HTTP/2 dan HTTP/3, ketekalan cache pembatalan, tingkah laku sandaran, dan diagnosis ralat konfigurasi dan bukannya sekadar menamakan beberapa pengepala.
Penjelasan untuk ditanya terlebih dahulu
- Siapakah yang mengeluarkan kunci klien, adakah kunci khusus untuk origin, dan adakah kunci jangka pendek disokong?
- Adakah get laluan dan origin berasingan, dan bagaimanakah output pengeksport TLS diserahkan antara kedua-duanya?
- Adakah sumber memerlukan kesegaran tahap sambungan atau kesegaran tahap permintaan?
- Jika klien legasi hanya menyokong TLS 1.2, adakah Extended Master Secret dirundingkan?
- Adakah pembatalan mesti berkuat kuasa dalam beberapa saat, atau adakah tetingkap cache boleh diterima?
Jawapan 30 saat
“Saya akan mengekalkan direktori kunci awam bagi setiap origin. Klien menggunakan pengeksport RFC 9729 pada sambungan TLS, menandatangani konteks yang ditetapkan, dan menghantar parameter; get laluan hanya menghuraikan dan memajukan bahan pengeksport yang dipercayai, manakala origin membuat keputusan pengesahan dan pembenaran muktamad. TLS 1.3 memenuhi keperluan pengikatan; TLS 1.2 memerlukan Extended Master Secret atau permintaan dianggap tidak disahkan. Saya akan menggunakan putaran kunci baca-dua, tulis-satu dan cache pembatalan pendek. Oleh kerana bukti berskop sambungan, kesegaran yang lebih kukuh memerlukan penggantian sambungan. Metrik pelancaran meliputi penghuraian, pengesahan, pembatalan, dan sandaran tanpa mendedahkan kewujudan sumber.”
Penyelesaian langkah demi langkah
Bina direktori kunci dan origin
Bagi setiap origin, petakan ID kunci kepada kunci awam, algoritma, realm, masa pengeluaran, dan status pembatalan. Kunci peribadi klien dikhususkan untuk pengesahan Concealed dan tidak digunakan semula dalam protokol lain. RFC 9729 menambah awalan tandatangan tetap, tetapi penggunaan tetap bertanggungjawab terhadap pengasingan kunci. ID kunci tidak boleh mengekod privasi pengguna; log audit menggunakan pengecam dalaman yang tidak boleh diterbalikkan.
Kira bukti terikat sambungan
Klien menggunakan label pengeksport EXPORTER-HTTP-Concealed-Authentication, konteks yang ditentukan, dan output 48-bait. 32 bait pertama membekalkan input tandatangan dan 16 bait terakhir dihantar sebagai bahan pengesahan. Konteks merangkumi algoritma, ID kunci, kunci awam, skim, hos, port, dan realm. Ketidakpadanan adalah kegagalan pengesahan; penghurai yang permisif tidak boleh ‘memperbaikinya’.
exported = TLS-Exporter(label, context, 48)
signature_input = exported[0:32] + domain_separation_prefix
verification = exported[32:48]
Authorization: Concealed k=..., a=..., s=..., p=..., v=...Tentukan sempadan get laluan-origin
Origin monolitik boleh membaca pengeksport TLS secara terus. Apabila diasingkan, get laluan mengesahkan sintaks parameter dan menghantar output pengeksport 48-bait dalam Concealed-Auth-Export melalui saluran dalaman yang dipercayai. Klien awam boleh memalsukan pengepala dengan nama tersebut, jadi get laluan mesti menulis ganti atau membuang nilai luaran. Origin masih memeriksa medan sasaran, algoritma, ID kunci, kunci awam, dan tandatangan; penghuraian get laluan bukanlah pembenaran.
Kuat kuasakan kekangan TLS dan protokol
RFC 9729 memerlukan TLS 1.3, atau TLS 1.2 dengan Extended Master Secret. Jika tidak, pelayan menganggap permintaan sebagai tidak disahkan. HTTP/2 dan HTTP/3 boleh menggunakan pengikatan tersebut, tetapi bukti tahap sambungan mungkin meliputi beberapa permintaan pada satu sambungan. Klien dan get laluan mesti mengasingkan konteks keselamatan supaya satu penyewa tidak dapat membaca pengepala Authorization penyewa lain.
Kendalikan kesegaran, penggunaan semula, dan main semula
Kesegaran pengeksport tidak bertahan lebih lama daripada sambungan TLS; ia bukan nonce bebas bagi setiap permintaan HTTP. Jika sumber memerlukan tetingkap yang lebih pendek, wajibkan sambungan baharu, contohnya dengan menutupnya atau menghantar HTTP/3 GOAWAY, dan gabungkan itu dengan ID kunci jangka pendek serta dasar masa pelayan. Jangan sekali-kali menganggap v sebagai nonce permintaan atau menerima tandatangan tanpa memeriksa hos, port, dan realm.
Putar, batal, dan sandar (fallback)
Gunakan putaran baca-dua, tulis-satu: terbitkan kunci baharu, terima ID kunci lama buat sementara waktu, migrasikan klien, kemudian batalkan kunci lama. Pembatalan diperiksa sebelum pembenaran dan TTL cache serta pembatalan tidak sah dinyatakan secara eksplisit. Klien legasi boleh menggunakan laluan pengesahan sedia ada, tetapi respons sandaran mengekalkan bentuk luaran yang sama supaya tidak mendedahkan sama ada sesuatu sumber itu wujud.
Perhatikan dan diagnosis kegagalan
Segmentasikan kegagalan penghuraian parameter, TLS tidak disokong, ID kunci tidak diketahui, ketidakpadanan kunci awam, kegagalan tandatangan, capaian pembatalan, ralat pemajuan get laluan, dan kadar sandaran mengikut origin, versi klien, protokol, dan algoritma. Jangan sekali-kali merekodkan kunci peribadi, tandatangan penuh, atau kunci pengguna yang boleh dipautkan. Audit ralat (erratum) disahkan yang menjejaskan rentetan konteks Seksyen 3.3 dan ABNF integer Seksyen 4 bagi RFC 9729.
Peringkatkan dan uji dengan selamat
Dayakan satu origin dan sumber berkeistimewaan rendah yang boleh dibatalkan terlebih dahulu. Uji TLS 1.3, TLS 1.2 serta EMS, HTTP/2, HTTP/3, get laluan berasingan, dan penggantian sambungan. Suntik hos, port, realm, algoritma, ID kunci, panjang pengeksport yang salah, pengepala pendua, cache pembatalan lapuk, dan kes sambungan rentas penyewa; setiap satu mesti dianggap sebagai tidak disahkan. Rollback menghentikan pengeluaran kunci baharu dan penerimaan skim sambil mengekalkan direktori lama dan rekod audit.
Model jawapan berkualiti tinggi
“RFC 9729 ialah pengesahan terikat sambungan dan tidak boleh disiasat (non-probeable), bukan nonce bagi setiap permintaan. Klien membina konteks pengeksport, memperoleh 48 bait, dan menandatangani dengan kunci khusus. Get laluan mengesahkan sintaks dan memajukan output pengeksport yang dipercayai; origin memeriksa syarat TLS, medan sasaran, ID kunci, kunci awam, tandatangan, pembatalan, dan pembenaran. TLS 1.3 atau TLS 1.2 serta EMS diperlukan. Kunci diskopkan mengikut origin dan diputar dengan bacaan dua kali. Kesegaran yang lebih kukuh bermakna menggantikan sambungan. Metrik pelancaran meliputi penghuraian, pengesahan, pembatalan, dan sandaran, dan rollback menghentikan penggunaan skim baharu tanpa mendedahkan keadaan sumber.”
Kesilapan biasa
- Menganggap pengeksport sebagai nonce bagi setiap permintaan → bukti boleh digunakan semula pada sambungan yang panjang → nyatakan kesegaran sambungan dan gantikan sambungan apabila diperlukan.
- Mengesahkan pada get laluan sahaja → origin mungkin mempercayai pengepala dalaman yang dipalsukan → origin mengesahkan konteks dan pembenaran.
- Menerima TLS 1.2 tanpa EMS → pengikatan pengeksport tidak mencukupi → anggap ia sebagai tidak disahkan.
- Menggunakan semula kunci merentasi protokol → kekeliruan tandatangan rentas protokol → khususkan kunci untuk skim dan origin.
- Menge-cache pembatalan terlalu lama → klien yang dibatalkan mengekalkan akses → tentukan TTL, pembatalan tidak sah, dan keutamaan.
- Mengembalikan ralat sumber yang berbeza semasa sandaran → kewujudan sumber menjadi boleh dicerap → kekalkan keadaan luaran yang seragam dan log sebabnya secara dalaman.
Soalan dan jawapan susulan
Soalan susulan 1: Mengapa origin tidak menghantar cabaran?
Cabaran memberitahu klien yang tidak disahkan bahawa sumber itu menjangkakan pengesahan, sekali gus menggagalkan matlamat tidak boleh disiasat. RFC 9729 membenarkan klien menghantar bukti yang diperoleh daripada bahan pengeksport TLS yang terikat pada sambungan.
Soalan susulan 2: Mengapa membahagikan 48 bait kepada 32 dan 16?
Spesifikasi menandatangani 32 bait pertama dan menghantar 16 bait terakhir sebagai bahan pengesahan supaya pelayan dapat mengesahkan output pengeksport. Pelaksanaan mesti menggunakan julat tepat tersebut, bukan menganggap semua 48 bait sebagai satu nonce.
Soalan susulan 3: Adakah selamat memajukan pengeksport dari get laluan?
Hanya pada saluran get laluan-ke-origin yang dipercayai dan dilindungi integritinya. Klien awam boleh memalsukan nama pengepala tersebut, jadi get laluan mesti menulis ganti atau membuangnya, dan origin harus mengesahkan saluran dalaman serta menyemak ketepatan panjangnya.
Soalan susulan 4: Bagaimanakah anda mengendalikan pembatalan pada sambungan sedia ada?
Semak pembatalan pada setiap keputusan pembenaran, bukan hanya semasa sambungan dibuat. Untuk kesegaran yang lebih kukuh, batalkan kunci lama, beri isyarat penutupan sambungan, dan minta klien menyambung semula dengan kunci baharu.