Gesaan dan skop
Rakan kongsi pembayaran memerlukan bukti penghantar dan integriti setiap permintaan HTTP. Menggunakan RFC 9421, reka bentuk tandatangan dan pengesahan serta terangkan komponen yang diliputi, pertahanan replay, giliran kunci, dan penulisan semula proksi.
RFC 9421 memisahkan input tandatangan, komponen HTTP yang diliputi, dan parameter seperti created, expires, dan nonce. Soalan ini menguji sama ada calon boleh menjadikan "siapa yang menandatanganinya" dan "bait mana yang ditandatangani" saling beroperasi (interoperable), dan bukannya sekadar mencincang (hashing) badan permintaan.
Perkara yang dinilai oleh penemu duga
Menilai sama ada komponen yang diliputi mengikat semantik permintaan; sama ada kedua-dua pihak mengkanonisasikan signature base secara serupa; sama ada masa, nonce, dan ID kunci menghalang replay; bagaimana proksi, percubaan semula, pemampatan, dan penyewa (tenants) mempengaruhi pengesahan; serta sama ada penerbitan, pembatalan, dan pemantauan kunci boleh dikendalikan.
Rangka kerja jawapan 30 saat
"Saya akan mewajibkan method, laluan sasaran, authority, medan perniagaan penting, dan Content-Digest diliputi, dengan algoritma, susunan parameter, dan toleransi jam yang tetap. Pelayan menghuraikan Signature-Input, membina semula base yang sama, mencari kunci, mengesahkan tandatangan, memeriksa created, expires, dan nonce sekali guna, dan hanya selepas itu memasuki logik perniagaan. ID kunci yang berversi menyokong pengesahan dwi-kunci dan pembatalan. Proksi hanya boleh menulis semula medan yang tidak diliputi; jika tidak pengesahan akan gagal."
Jawapan mendalam langkah demi langkah
Langkah 1: Tentukan sifat yang perlu dibuktikan
Tandatangan membuktikan bahawa pemegang kunci telah menandatangani komponen HTTP yang dipilih dan membantu mengesan pengubahan (tampering). Ia tidak menggantikan TLS, kebenaran (authorization), pengesahan input, atau keidempoteman perniagaan. Nyatakan sama ada protokol memerlukan pengesahan identiti (authentication), integriti, atau tanpa sangkalan (non-repudiation).
Langkah 2: Pilih komponen yang diliputi
Liputi method, laluan sasaran, dan authority sebagai keperluan minimum. Tambahkan content-digest, kunci keidempoteman, ID penyewa, atau medan perniagaan kritikal seperti yang diperlukan. Jangan tandatangani satu medan yang boleh diganti atau meliputkan pengepala yang ditulis semula oleh proksi yang sah secara membuta tuli. Versikan senarai komponen sebagai sebahagian daripada protokol.
Langkah 3: Kanonisasikan signature base
Kedua-dua pihak mesti mematuhi pengecam komponen, penyusunan, pengekodan parameter, dan peraturan komponen terbitan RFC 9421. Pelayan harus membina semula base daripada permintaan yang dihuraikan dan Signature-Input, bukan meneka dengan menggabungkan rentetan pengepala mentah. Tolak komponen kritikal yang tidak diketahui atau pendua.
Langkah 4: Lindungi kandungan permintaan
Bagi permintaan yang mempunyai badan (body), kira Content-Digest dan sertakannya dalam tandatangan. Sebelum pengesahan, lakukan cincangan pada bait yang diterima supaya pemampatan, transkod, atau pemformatan semula JSON tidak dapat mengubah kandungan secara senyap. Jika proksi menyahmampat atau mengekod semula, tentukan sama ada penandatanganan berlaku sebelum atau selepas transformasi tersebut.
Langkah 5: Tambahkan pertahanan masa dan replay
Wajibkan created, dan jika berguna wajibkan expires serta nonce yang unik. Periksa tetingkap masa dan sipi jam (clock skew), dan simpan nonce yang telah digunakan secara ringkas bagi setiap penyewa. Percubaan semula bagi permintaan perniagaan yang sama bergantung pada kunci keidempoteman dan bukannya jangka hayat tandatangan tanpa had. Lulus pemeriksaan masa tidak menjadikan operasi penulisan selamat untuk dilaksanakan dua kali.
Langkah 6: Temui dan gilirkan kunci
ID kunci dalam Signature-Input memilih kunci awam daripada direktori terkawal atau titik akhir seakan JWKS. Simpan hasil berversi dalam cache. Semasa penggantian, terbitkan kunci baharu, benarkan kunci lama dan baharu untuk tempoh pertindihan yang terhad, kemudian batalkan kunci lama selepas trafik selesai dialihkan. Simpan kunci persendirian pada titik akhir penandatanganan dan jangan sekali-kali log bahan kunci atau signature base yang lengkap.
Langkah 7: Tentukan sempadan proksi dan percubaan semula
Dokumentasikan lapisan mana yang boleh menambah medan penjejakan, mencuba semula permintaan, atau menukar authority. Penulisan semula tanpa kebenaran pada komponen yang diliputi mesti menggagalkan pengesahan. Proksi tidak boleh menyalin nonce sekali guna atau memajukan tandatangan ke sasaran lain. Jangan jalankan operasi penulisan atau logik perniagaan yang mahal sebelum pengesahan.
Langkah 8: Kendalikan kegagalan dengan selamat
Catat ID kunci, versi tandatangan, kelas kegagalan, sipi jam, pertembungan nonce, komponen yang hilang, dan sumber proksi bersama-sama ID permintaan. Berikan rakan kongsi kelas yang boleh diambil tindakan seperti tamat tempoh, kunci tidak diketahui, atau ketidakpadanan digest, tanpa mengembalikan bahan kunci atau base terperinci yang membantu penyerang menyiasat.
Pertukaran (trade-offs) dan sempadan
Tandatangan asimetrik berbanding kunci kongsi
Kunci asimetrik memudahkan pengesahan berbilang pihak dan pembatalan bebas tetapi memerlukan lebih banyak infrastruktur. HMAC kongsi adalah lebih murah, namun setiap pengesah boleh memalsukan permintaan; gunakannya hanya apabila sempadan kepercayaan adalah jelas.
Liputan berbanding keserasian proksi
Liputan yang lebih banyak memberikan integriti yang lebih kukuh tetapi boleh gagal apabila get laluan mengubah medan secara sah. Letakkan kontrak proksi dalam protokol dan tandatangan semula di sempadan apabila diperlukan dan bukannya melemahkan pengesahan secara senyap.
Tetingkap ketat berbanding percubaan semula luar talian
Tetingkap yang singkat mengurangkan risiko replay tetapi memerlukan penyegerakan jam dan percubaan semula yang pantas. Klien luar talian harus meminta tandatangan baharu dan bukannya menggunakan semula tandatangan yang bertahan lama; pelayan boleh menggunakan toleransi khusus rakan kongsi yang terhad.
Latih tubi kegagalan dan evolusi
Proksi menukar laluan
Tulis semula laluan atau authority dalam proksi ujian dan sahkan bahawa pengesahan gagal sebelum logik perniagaan. Perubahan pengepala penjejakan yang dibenarkan tidak boleh menjejaskan tandatangan.
Permintaan lama dimainkan semula (replayed)
Hantar tandatangan dan nonce yang sama dua kali dan sahkan bahawa percubaan kedua ditolak. Gunakan nonce baharu dengan kunci keidempoteman yang sama dan sahkan keidempoteman lapisan perniagaan.
Kunci digilirkan
Terbitkan kunci lama dan baharu bersama-sama dan sahkan tandatangan yang mematuhi dasar. Selepas pembatalan, tandatangan lama mesti gagal dan cache lapuk tidak boleh mengekalkannya sah selama-lamanya.
Kesilapan lazim dan tindakan susulan
Kesilapan 1: Menandatangani cincangan badan sahaja
Tanya sama ada tandatangan boleh disalin ke laluan atau kaedah lain; komponen sasaran yang diliputi mesti mengikat makna permintaan.
Kesilapan 2: Menganggap HTTPS sudah mencukupi
Tanya bagaimana penghantar asal dan kandungan disahkan selepas melalui proksi dalaman yang menamatkan TLS.
Kesilapan 3: Mengabaikan nonce dan masa
Tanya sama ada permintaan pembayaran yang ditangkap boleh dimainkan semula semasa tetingkap kesahihannya; gabungkan masa, nonce, dan keidempoteman.
Kesilapan 4: Memadamkan kunci lama serta-merta
Tanya bagaimana permintaan dalam penerbangan dan cache berbilang rantau bertindih; lakukan pengesahan dwi-kunci sebelum pembatalan.
Kesilapan 5: Mengembalikan butiran signature-base apabila berlaku kegagalan
Tanya bagaimana rakan kongsi menyahpepijat tanpa mendedahkan bahan kunci, input yang ditandatangani, atau butiran proksi dalaman.
Tindakan susulan lanjutan dan jawapan rujukan
Mengapa memasukkan Content-Digest dalam tandatangan?
Digest mewakili bait badan permintaan; tandatangan mengikat digest tersebut kepada method, sasaran, dan komponen lain supaya digest yang sah tidak boleh dipindahkan ke permintaan lain.
Patutkah proksi menandatangani semula selepas menulis semula?
Jika penulisan semula adalah sebahagian daripada protokol hiliran, proksi sempadan harus menandatanganinya sebagai identitinya sendiri. Jika tidak, ia mesti mengekalkan komponen yang diliputi supaya tandatangan asal kekal boleh disahkan.
Bagaimanakah pengesahan identiti dan kebenaran berbeza?
Pengesahan membuktikan bahawa pemegang kunci telah menandatangani permintaan tersebut. Kebenaran masih memeriksa penyewa, akaun, jumlah, keidempoteman, dan keadaan perniagaan; tandatangan sahaja tidak boleh memberi kebenaran untuk pelaksanaan.