Gesaan dan konteks
Anda mengendalikan sambungan pentadbiran yang berjalan lama. Kebanyakan permintaan harus mengelakkan kerja sijil klien, tetapi operasi berisiko tinggi mesti mengenal pasti klien. Reka bentuk pengesahan klien pasca-jabat tangan TLS 1.3 dan terangkan sempadannya berbanding dengan mutual TLS semasa jabat tangan awal.
Perkara yang sedang diuji oleh penemuduga
Jawapan harus menganggap pengesahan pasca-jabat tangan sebagai aliran mesej TLS 1.3 pilihan, bukan sebagai sambungan TLS kedua. Rangkumi klien yang mengiklankan keupayaan post_handshake_auth dalam ClientHello awalnya, pelayan menghantar CertificateRequest kemudian, klien mengembalikan rantaian sijilnya dan CertificateVerify, pengendalian kegagalan, dan pengikatan hasilnya kepada HTTP/2, HTTP/3, atau permintaan aplikasi.
Soalan penjelasan untuk ditanya terlebih dahulu
Skop pengesahan
Tanya sama ada pengesahan adalah sekali bagi setiap sambungan, sekali bagi setiap permintaan berisiko tinggi, atau bergantung pada penyewa (tenant). Menyimpannya dalam cache terlalu lama meluaskan tetingkap pembatalan (revocation window); memintanya terlalu kerap menambah kos pengesahan sijil dan mesej protokol.
Sempadan protokol dan pelaksanaan
Sahkan sama ada sambungan membawa HTTP/1.1, HTTP/2, HTTP/3, atau protokol tersuai, dan sama ada pustaka TLS mendedahkan API pasca-jabat tangan. Aplikasi mesti menyekat operasi yang dilindungi sehingga pengesahan selesai.
Dasar kegagalan dan pembatalan
Tentukan sama ada sijil yang tamat tempoh, CA yang tidak diketahui, tandatangan yang tidak sah, atau keupayaan yang tidak disokong menolak satu permintaan, menutup sambungan, atau mengekalkan sesi keistimewaan rendah. Kenal pasti sumber OCSP, sijil jangka pendek, atau senarai pembatalan (CRL).
Rangka jawapan 30 saat
"Pengesahan pasca-jabat tangan TLS 1.3 memerlukan klien untuk mengiklankan post_handshake_auth dalam ClientHello awalnya. Pelayan kemudiannya menghantar CertificateRequest; klien mengembalikan Certificate, CertificateVerify, dan Finished. Pelayan mengesahkan rantaian, penggunaan, tandatangan, dan status pembatalan sebelum mengikat identiti kepada permintaan terkemudian. Jika keupayaan tidak dirundingkan atau pengesahan gagal, dasar mesti menolak operasi yang dilindungi atau menutup sambungan dan bukannya menurunkan taraf secara senyap (silent downgrade)."
Jawapan mendalam langkah demi langkah
Langkah 1: Rundingkan keupayaan dan cipta sesi disulitkan yang tidak disahkan
Klien mengiklankan sokongan dalam ClientHello. Pelayan melengkapkan jabat tangan TLS 1.3 biasa tetapi menandakan sambungan sebagai disulitkan dan tidak disahkan klien. Klien yang tidak mengiklankan keupayaan tersebut tidak boleh diminta untuk mengemukakan sijil kemudian; halakan ia kepada keistimewaan rendah atau sambung semula mengikut dasar.
Langkah 2: Hantar CertificateRequest apabila dasar memerlukannya
Apabila titik akhir berisiko tinggi atau dasar penyewa memerlukan identiti, pelayan menghantar CertificateRequest dengan algoritma tandatangan dan kekangan pihak berkuasa sijil (certificate authority) yang boleh diterima. Mesin keadaan (state machine) TLS mesti menyusun atur (serialize) proses ini dengan penulisan aplikasi supaya strim serentak tidak dapat memerhati keadaan yang dikemas kini separuh jalan.
Langkah 3: Sahkan respons klien
Klien menghantar rantaian sijilnya, CertificateVerify, dan Finished. Sahkan rantaian, identiti SAN atau URI, penggunaan kunci, algoritma tandatangan, kesahihan tempoh, dan pembatalan. Hanya selepas itu lampirkan identiti, cap jari sijil, dan masa pengesahan pada konteks sambungan. Permintaan sensitif yang tiba lebih awal mesti dimasukkan ke dalam giliran atau ditolak.
Langkah 4: Kendalikan kegagalan dan percubaan semula (retries)
Bagi keupayaan yang tidak disokong, sijil tiada, tandatangan tidak sah, atau pembatalan, kembalikan ralat aplikasi, hantar amaran TLS (TLS alert), atau tutup mengikut dasar. Bataskan percubaan semula mengikut kiraan dan masa. Jangan sekali-kali menukar permintaan berisiko tinggi yang gagal menjadi permintaan tanpa nama secara automatik. Log kelas ralat dan versi konfigurasi tanpa bahan kunci peribadi atau kandungan sijil yang tidak perlu.
Langkah 5: Ambil kira penyambungan semula (resumption), keserentakan, dan penghijrahan
Penyambungan semula sesi tidak membuktikan secara automatik bahawa kebenaran (authorization) aplikasi semasa masih sah. Nilaikan semula dasar pada sambungan yang disambung semula. Dengan pemultipleksan HTTP/2, satu strim boleh mencetuskan pengesahan manakala strim lain menghantar permintaan, jadi tentukan sempadan sekatan. Sahkan bahawa pelaksanaan QUIC/TLS HTTP/3 menyokong aliran mesej tersebut sebelum menjanjikannya.
Langkah 6: Kendalikan kepercayaan dan bahan kunci
Gunakan CA klien khusus, sijil jangka pendek, dan pelancaran gedung amanah (trust-store) yang boleh diaudit. Semasa giliran CA, kekalkan tetingkap dwi-kepercayaan dan laluan pengunduran (rollback path). Asingkan kebenaran untuk kunci peribadi pelayan, gedung amanah, dan penerbitan dasar; pengesahan klien tidak boleh memberikan akses kepada operasi kunci pelayan.
Langkah 7: Uji dan perhati
Bina matriks klien dengan dan tanpa keupayaan tersebut. Uji kejayaan, sijil tamat tempoh, tandatangan salah, pembatalan, tamat masa (timeout), strim serentak, dan penyambungan semula. Pantau kadar CertificateRequest, kadar kejayaan, kelas kegagalan, pendam pengesahan, permintaan dilindungi yang ditolak, dan penutupan sambungan. Pastikan log ujian tidak mendedahkan kunci peribadi atau muatan sensitif yang lengkap.
Contoh jawapan berkualiti tinggi
Saya akan memodelkan dua keadaan: disulitkan-tetapi-tidak-disahkan dan disahkan-klien. Klien mesti mengiklankan post_handshake_auth dalam ClientHello sebelum pelayan boleh menghantar CertificateRequest. Klien mengembalikan rantaiannya, CertificateVerify, dan Finished; pelayan menyemak CA, SAN, penggunaan, tandatangan, kesahihan, dan pembatalan sebelum mengikat identiti kepada permintaan berisiko tinggi.
Jika keupayaan tidak dirundingkan atau pengesahan gagal, tolak operasi yang dilindungi; jangan turunkan taraf secara senyap. Bekukan strim HTTP/2 yang dilindungi semasa pengesahan masih belum selesai, dan sahkan sokongan pustaka untuk HTTP/3. Nilaikan semula kebenaran selepas penyambungan semula. Lancarkan dengan matriks klien dan perhatikan permulaan, kejayaan, sebab kegagalan, kependaman, dan tingkah laku pembatalan.
Kesilapan biasa
- Kesilapan: Menganggap sambungan yang telah diwujudkan bermaksud klien telah disahkan. → Sebab ia gagal: Penyulitan dan identiti klien adalah keadaan yang berasingan. → Pembetulan: Jejak kedua-dua keadaan secara eksplisit.
- Kesilapan: Memerlukan sijil daripada klien yang tidak merundingkan keupayaan tersebut. → Sebab ia gagal: Keupayaan mesti diiklankan dalam ClientHello awal. → Pembetulan: Gunakan dasar keistimewaan rendah atau sambung semula.
- Kesilapan: Melaksanakan permintaan selepas pengesahan gagal. → Sebab ia gagal: Mesej pengesahan tiba secara tak segerak dan tidak menjamin kerja secara retroaktif. → Pembetulan: Sekat strim yang dilindungi sehingga pengesahan selesai.
- Kesilapan: Menggunakan semula identiti sambungan lama untuk kebenaran penyewa baharu. → Sebab ia gagal: Penyambungan semula dan perubahan dasar boleh membatalkan keadaan aplikasi yang lama. → Pembetulan: Nilaikan semula menggunakan versi kebenaran.
Soalan dan jawapan susulan
Soalan susulan 1: Mengapakah mutual TLS awal masih biasa digunakan?
Mutual TLS awal memilih dan mengesahkan identiti sebelum jabat tangan berakhir, jadi pengurusan keadaan dan keserasiannya lebih mudah apabila setiap permintaan memerlukan pengesahan. Pengesahan pasca-jabat tangan sesuai untuk sambungan yang berjalan lama di mana hanya sebilangan kecil operasi memerlukan identiti tambahan, dengan kos lebih banyak keadaan dan peraturan keserentakan.
Soalan susulan 2: Bolehkah ia menggantikan kebenaran aplikasi?
Tidak. Ia hanya membuktikan pemilikan kunci peribadi dan rantaian sijil yang sah. Aplikasi masih memetakan SAN, penyewa, peranan, operasi, dan status pembatalan kepada keputusan kebenaran dan merekodkan versi keputusan tersebut.
Soalan susulan 3: Adakah klien tanpa sijil mesti diputuskan sambungannya?
Tidak semestinya. Dasar boleh mengekalkan sesi keistimewaan rendah dan menolak permintaan yang dilindungi. Satah pengurusan (management plane) yang memerlukan pengesahan berterusan harus mengembalikan ralat yang jelas dan menutup sambungan. Jadikan pilihan tersebut boleh diaudit dan boleh diperhatikan.
Soalan susulan 4: Bagaimanakah anda membuktikan bahawa sesebuah pustaka menyokong aliran ini?
Semak API berversi dan ujian kesalingoperasian untuk rundingan sambungan, CertificateRequest, sijil tidak sah, strim serentak, dan penyambungan semula. Satu bendera konfigurasi sahaja tidak membuktikan bahawa keseluruhan mesin keadaan telah dilaksanakan.