Topik wawancara representatif

Wawancara Backend: Bagaimana Anda akan menerapkan autentikasi HTTP tersembunyi RFC 9729?

BackendSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Anda perlu menerapkan autentikasi Concealed RFC 9729 untuk layanan HTTP yang harus menyembunyikan keberadaan sumber daya yang dilindungi. Jelaskan penandatanganan klien, penerusan gateway, verifikasi origin, persyaratan TLS, rotasi kunci, fallback, dan diagnosis.

Konteks dan cakupan

Sebuah layanan enterprise menginginkan klien dengan kunci terotorisasi dapat mengakses sumber daya tertentu tanpa membiarkan klien yang tidak terautentikasi menyelidiki keberadaannya melalui respons atau tantangan 401. Tim sedang mempertimbangkan IETF RFC 9729, sebuah RFC Standards Track Februari 2025. Skema ini menggunakan TLS keying-material exporter untuk membuat input tanda tangan yang terikat koneksi dan mengirimkan bukti dalam Authorization: Concealed.

Rancang penerapan klien, edge gateway, dan origin. Jelaskan output exporter 48-byte, parameter autentikasi, persyaratan versi TLS, penggunaan kembali koneksi, pencabutan kunci, fallback lawas, dan pengujian peluncuran (rollout). Sertakan erratum 2026 yang telah diverifikasi dalam audit implementasi.

Apa yang dinilai oleh pewawancara

Pewawancara ingin Anda memisahkan antara kemampuan menyembunyikan autentikasi dan menjamin kesegaran (freshness): RFC 9729 tidak mengirimkan tantangan, tetapi kesegaran bukti dibatasi oleh masa pakai koneksi TLS yang mendasarinya.

Jawaban yang kuat mencakup penerusan Concealed-Auth-Export yang aman, kunci khusus protokol, isolasi multipleks HTTP/2 dan HTTP/3, konsistensi cache pencabutan, perilaku fallback, dan diagnosis kesalahan konfigurasi daripada sekadar menyebutkan beberapa header.

Klarifikasi yang perlu ditanyakan terlebih dahulu

  • Siapa yang menerbitkan kunci klien, apakah kunci bersifat spesifik untuk origin, dan apakah kunci berumur pendek didukung?
  • Apakah gateway dan origin terpisah, dan bagaimana output TLS exporter diteruskan di antara keduanya?
  • Apakah sumber daya memerlukan kesegaran tingkat koneksi atau kesegaran tingkat permintaan?
  • Jika klien lawas hanya mendukung TLS 1.2, apakah Extended Master Secret dinegosiasikan?
  • Apakah pencabutan harus berlaku dalam hitungan detik, atau apakah jendela cache dapat diterima?

Jawaban 30 detik

“Saya akan mengelola direktori kunci publik per origin. Klien menggunakan exporter RFC 9729 pada koneksi TLS, menandatangani konteks yang ditentukan, dan mengirimkan parameter; gateway hanya mem-parsing dan meneruskan materi exporter tepercaya, sementara origin membuat keputusan akhir autentikasi dan otorisasi. TLS 1.3 memenuhi persyaratan pengikatan; TLS 1.2 memerlukan Extended Master Secret atau permintaan dianggap tidak terautentikasi. Saya akan menggunakan rotasi kunci dual-read, single-write dan cache pencabutan singkat. Karena bukti memiliki cakupan koneksi, kesegaran yang lebih kuat memerlukan penggantian koneksi. Metrik peluncuran mencakup parsing, verifikasi, pencabutan, dan fallback tanpa mengungkapkan keberadaan sumber daya.”

Solusi langkah demi langkah

Bangun direktori kunci dan origin

Untuk setiap origin, petakan ID kunci ke kunci publik, algoritma, realm, waktu penerbitan, dan status pencabutan. Kunci privat klien didedikasikan untuk autentikasi Concealed dan tidak digunakan kembali dalam protokol lain. RFC 9729 menambahkan awalan tanda tangan tetap, tetapi penerapan tetap bertanggung jawab atas pemisahan kunci. ID kunci tidak boleh menyandikan privasi pengguna; log audit menggunakan pengenal internal yang tidak dapat dibalik.

Hitung bukti yang terikat koneksi

Klien menggunakan label exporter EXPORTER-HTTP-Concealed-Authentication, konteks yang ditentukan, dan output 48-byte. 32 byte pertama menjadi input tanda tangan dan 16 byte terakhir dikirim sebagai materi verifikasi. Konteks mencakup algoritma, ID kunci, kunci publik, skema, host, port, dan realm. Ketidakcocokan adalah kegagalan verifikasi; parser yang permisif tidak boleh ‘memperbaikinya’.

text
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 batas gateway-origin

Origin monolitik dapat membaca TLS exporter secara langsung. Saat dipisah, gateway memvalidasi sintaks parameter dan mengirimkan output exporter 48-byte dalam Concealed-Auth-Export melalui saluran internal tepercaya. Klien publik dapat memalsukan header dengan nama tersebut, sehingga gateway harus menimpa atau menghapus nilai eksternal. Origin tetap memeriksa field target, algoritma, ID kunci, kunci publik, dan tanda tangan; parsing gateway bukanlah otorisasi.

Terapkan batasan TLS dan protokol

RFC 9729 memerlukan TLS 1.3, atau TLS 1.2 dengan Extended Master Secret. Jika tidak, server memperlakukan permintaan sebagai tidak terautentikasi. HTTP/2 dan HTTP/3 dapat menggunakan pengikatan tersebut, tetapi bukti tingkat koneksi dapat mencakup beberapa permintaan dalam satu koneksi. Klien dan gateway harus mengisolasi konteks keamanan sehingga satu penyewa tidak dapat membaca header Authorization penyewa lain.

Tangani kesegaran, penggunaan kembali, dan replay

Kesegaran exporter berlangsung tidak lebih lama dari koneksi TLS; ini bukanlah nonce independen per permintaan HTTP. Jika sumber daya memerlukan jendela yang lebih pendek, wajibkan koneksi baru, misalnya dengan menutupnya atau mengirim HTTP/3 GOAWAY, dan gabungkan dengan ID kunci berumur pendek serta kebijakan waktu server. Jangan pernah memperlakukan v sebagai nonce permintaan atau menerima tanda tangan tanpa memeriksa host, port, dan realm.

Rotasi, cabut, dan lakukan fallback

Gunakan rotasi dual-read, single-write: publikasikan kunci baru, terima ID kunci lama untuk sementara, migrasikan klien, lalu cabut kunci lama. Pencabutan diperiksa sebelum otorisasi serta TTL cache dan pembatalan (invalidation) dibuat eksplisit. Klien lawas dapat menggunakan jalur autentikasi yang ada, tetapi respons fallback mempertahankan bentuk eksternal yang sama sehingga tidak mengungkapkan apakah suatu sumber daya ada.

Amati dan diagnosis kegagalan

Segmentasikan kegagalan parsing parameter, TLS yang tidak didukung, ID kunci yang tidak dikenal, ketidakcocokan kunci publik, kegagalan tanda tangan, hit pencabutan, kesalahan penerusan gateway, dan tingkat fallback berdasarkan origin, versi klien, protokol, dan algoritma. Jangan pernah mencatat kunci privat, tanda tangan lengkap, atau kunci pengguna yang dapat ditautkan. Audit erratum terverifikasi yang memengaruhi string konteks Bagian 3.3 dan ABNF bilangan bulat Bagian 4 pada RFC 9729.

Lakukan pentahapan dan pengujian dengan aman

Aktifkan satu origin dan sumber daya berhak istimewa rendah yang dapat dicabut terlebih dahulu. Uji TLS 1.3, TLS 1.2 plus EMS, HTTP/2, HTTP/3, gateway terpisah, dan penggantian koneksi. Suntikkan host, port, realm, algoritma, ID kunci, panjang exporter yang salah, header duplikat, cache pencabutan basi, dan kasus koneksi lintas penyewa; masing-masing harus diperlakukan sebagai tidak terautentikasi. Rollback menghentikan penerbitan kunci baru dan penerimaan skema sambil tetap mempertahankan direktori lama dan catatan audit.

Contoh jawaban berkualitas tinggi

“RFC 9729 adalah autentikasi non-probeable yang terikat koneksi, bukan nonce per permintaan. Klien membangun konteks exporter, memperoleh 48 byte, dan menandatangani dengan kunci khusus. Gateway memvalidasi sintaks dan meneruskan output exporter tepercaya; origin memeriksa kondisi TLS, field target, ID kunci, kunci publik, tanda tangan, pencabutan, dan otorisasi. Diperlukan TLS 1.3 atau TLS 1.2 plus EMS. Kunci dicakupkan ke origin dan dirotasi dengan dual read. Kesegaran yang lebih kuat berarti mengganti koneksi. Metrik peluncuran mencakup parsing, verifikasi, pencabutan, dan fallback, dan rollback menghentikan penggunaan skema baru tanpa mengekspos status sumber daya.”

Kesalahan umum

  • Memperlakukan exporter sebagai nonce per permintaan → bukti dapat digunakan kembali pada koneksi yang panjang → nyatakan kesegaran koneksi dan ganti koneksi bila diperlukan.
  • Hanya memverifikasi di gateway → origin dapat memercayai header internal yang dipalsukan → origin memverifikasi konteks dan otorisasi.
  • Menerima TLS 1.2 tanpa EMS → pengikatan exporter tidak memadai → perlakukan sebagai tidak terautentikasi.
  • Menggunakan kembali kunci di seluruh protokol → kebingungan tanda tangan lintas protokol → dedikasikan kunci untuk skema dan origin.
  • Menyimpan cache pencabutan terlalu lama → klien yang dicabut tetap memiliki akses → tentukan TTL, pembatalan, dan prioritas.
  • Mengembalikan kesalahan sumber daya yang berbeda pada fallback → keberadaan sumber daya menjadi dapat diamati → pertahankan keseragaman status eksternal dan catat alasannya secara internal.

Pertanyaan lanjutan dan jawaban

Pertanyaan lanjutan 1: Mengapa origin tidak mengirimkan tantangan?

Tantangan memberi tahu klien yang tidak terautentikasi bahwa sumber daya mengharapkan autentikasi, yang menggagalkan tujuan non-probeable. RFC 9729 memungkinkan klien mengirimkan bukti yang diturunkan dari materi TLS exporter yang terikat pada koneksi.

Pertanyaan lanjutan 2: Mengapa membagi 48 byte menjadi 32 dan 16?

Spesifikasi menandatangani 32 byte pertama dan mengirimkan 16 byte terakhir sebagai materi verifikasi sehingga server dapat mengonfirmasi output exporter. Implementasi harus menggunakan rentang yang tepat tersebut, bukan memperlakukan seluruh 48 byte sebagai satu nonce.

Pertanyaan lanjutan 3: Apakah aman meneruskan exporter dari gateway?

Hanya pada saluran gateway-ke-origin yang tepercaya dan integritasnya terlindungi. Klien publik dapat memalsukan nama header tersebut, sehingga gateway harus menimpa atau menghapusnya, dan origin harus mengautentikasi saluran internal serta memvalidasi panjangnya.

Pertanyaan lanjutan 4: Bagaimana Anda menangani pencabutan pada koneksi yang ada?

Periksa pencabutan pada setiap keputusan otorisasi, bukan hanya saat koneksi dibuat. Untuk kesegaran yang lebih kuat, cabut kunci lama, beri sinyal penutupan koneksi, dan wajibkan klien untuk menyambung kembali dengan kunci baru.

Sumber publik

Pertanyaan terkait