TLS melindungi pertukaran HTTP selama trafik bergerak melalui koneksi TLS, tetapi beberapa desain aplikasi memerlukan pernyataan kriptografis yang melekat pada pesan HTTP itu sendiri. Gateway dapat menghentikan TLS sebelum meneruskan request, layanan dapat perlu mengautentikasi metadata request tertentu, atau pesan dapat melewati beberapa hop HTTP ketika perlindungan transport dan kepercayaan aplikasi berada pada batas yang berbeda.
HTTP Message Signatures, yang ditetapkan dalam RFC 9421, menangani batas tersebut. Signer memilih komponen pesan HTTP, membentuk signature base sesuai aturan, menandatanganinya, lalu mengirim metadata yang memberi tahu verifier komponen dan parameter yang tercakup. Mekanisme ini sengaja bersifat selektif: sebuah tanda tangan tidak otomatis mencakup setiap field atau setiap properti pesan.
Daftar komponen menentukan cakupan yang ditandatangani
Tanda tangan dimulai dengan kumpulan covered components yang eksplisit. Kumpulan ini dapat memuat field HTTP dan derived components seperti @method, @authority, @path, atau @status, sesuai aturan RFC 9421.
Daftar tersebut bersifat kritis bagi keamanan. Jika otorisasi bergantung pada method request dan path target, menandatangani hanya sebuah field aplikasi akan membiarkan properti routing itu berada di luar pernyataan kriptografis. Jika verifier membuat keputusan dari komponen yang tidak dicakup tanda tangan, tanda tangan tersebut tidak dapat mengautentikasi input itu.
Desain ini memisahkan validitas kriptografis dari kebijakan aplikasi. Sebuah tanda tangan dapat valid secara matematis tetapi tetap tidak memadai untuk keputusan otorisasi tertentu. Verifier memerlukan kebijakan yang menetapkan komponen wajib untuk setiap operasi.
Signature-Input membawa metadata penandatanganan
RFC 9421 menggunakan field Signature-Input untuk mendeskripsikan tanda tangan berlabel. Nilainya mengidentifikasi covered components dan dapat membawa parameter seperti created, expires, nonce, alg, dan keyid.
Field Signature membawa byte tanda tangan yang sesuai. Label menghubungkan entri dalam Signature-Input dengan entri dalam Signature, sehingga satu pesan dapat membawa lebih dari satu tanda tangan ketika aplikasi memerlukan pernyataan terpisah.
Parameter tidak dapat menggantikan kebijakan eksternal. keyid dapat membantu verifier memilih material key, tetapi identifier itu sendiri tidak menetapkan bahwa key tersebut tepercaya untuk tindakan yang diminta. Demikian pula, parameter alg membawa informasi algoritme dalam metadata tanda tangan; penerimaan tetap bergantung pada kebijakan kriptografi dan aplikasi milik verifier.
Parameter terkait waktu juga memerlukan pemeriksaan lokal. Verifier yang memakai created atau expires harus membandingkannya dengan clock dan jendela kebijakan yang dapat diterima. Timestamp bertanda tangan tidak dengan sendirinya mencegah replay.
Serialisasi kanonis membentuk signature base
HTTP mengizinkan representasi yang setara pada tingkat protokol meski byte mentahnya berbeda. Menandatangani byte wire secara sembarang akan membuat tanda tangan rapuh saat melewati pemrosesan yang tetap sesuai protokol. HTTP Message Signatures mendefinisikan aturan untuk menurunkan nilai covered component dan menyerialisasikannya menjadi signature base.
Signer dan verifier membentuk base tersebut secara independen dari komponen yang dipilih dan parameter tanda tangan. Verifikasi berhasil hanya ketika verifier merekonstruksi material yang sesuai dengan tanda tangan kriptografis.
Hal ini tidak berarti intermediary bebas mengubah semantik yang ditandatangani. Transformasi proxy yang mengubah covered component dapat membuat verifikasi gagal. Komponen yang diperkirakan berubah antar-hop perlu ditempatkan dengan hati-hati dalam cakupan, atau tanda tangan perlu dibuat dan diverifikasi pada batas tempat nilai tersebut stabil.
Canonicalization karena itu merupakan bagian dari protokol keamanan, bukan sekadar kemudahan formatting. Implementasi sebaiknya mengikuti model pemrosesan yang ditetapkan RFC, bukan membuat aturan penggabungan string sendiri.
Integritas content memerlukan komponen yang tepat
Message signature dapat mengautentikasi field yang mendeskripsikan content, tetapi tidak secara implisit melakukan hash terhadap body HTTP hanya karena request memiliki tanda tangan. Aplikasi yang memerlukan integritas body umumnya menggabungkan message signature dengan field content digest untuk HTTP dan memasukkan field digest terkait ke dalam covered components.
Komposisi itu penting. Jika digest tersedia tetapi tidak dicakup tanda tangan, penyerang yang mampu mengubah body dan digest yang tidak terlindungi dapat menjaga keduanya tetap konsisten tanpa mempertahankan pernyataan signer. Kebijakan verifier perlu mengikat content digest ke tanda tangan ketika integritas body diwajibkan.
Prinsip yang sama berlaku untuk metadata routing dan otorisasi. Properti keamanan berasal dari kumpulan input yang benar-benar diautentikasi, bukan sekadar dari keberadaan field Signature.
Kontrol replay tetap menjadi tanggung jawab aplikasi
Tanda tangan valid membuktikan bahwa material yang ditandatangani cocok dengan tanda tangan yang dibuat menggunakan signing key terkait di bawah algoritme yang dipilih. Tanda tangan itu tidak membuktikan bahwa pesan masih fresh atau bahwa request bertanda tangan yang sama belum pernah dikirim sebelumnya.
RFC 9421 menyediakan parameter yang dapat mendukung pertahanan replay, termasuk timestamp dan nonce, tetapi aplikasi harus menetapkan serta menegakkan kebijakan terkait. Nonce bernilai hanya ketika verifier dapat menentukan apakah nilainya dapat diterima dan, bila diperlukan, apakah nilai tersebut sudah pernah digunakan. Batas expiration dapat mempersempit jendela replay tetapi tidak otomatis memberi semantik sekali pakai.
Otorisasi key juga tetap berada di luar verifikasi tanda tangan. Layanan harus memetakan key terverifikasi ke identitas, role, tenant, capability, atau konteks otorisasi lain sebelum memberikan operasi.
Keamanan transport dan message signature melindungi batas yang berbeda
HTTP Message Signatures tidak menggantikan TLS. TLS dapat menyediakan confidentiality, peer authentication, dan integrity untuk trafik pada sebuah koneksi. Message signature menyediakan pernyataan kriptografis atas komponen HTTP terpilih yang dapat dievaluasi pada layer aplikasi.
Penggunaan keduanya dapat sesuai ketika trust boundary berbeda. TLS dapat melindungi setiap network leg sementara message signature membawa pernyataan aplikasi melintasi gateway atau rantai layanan. Nilai keamanan tanda tangan bergantung pada pemilihan komponen yang disiplin, pengelolaan key, kebijakan replay, dan pemeriksaan otorisasi pada verifier.
Properti keamanan yang dihasilkan bersifat sempit dan eksplisit: komponen HTTP terpilih terikat pada tanda tangan kriptografis beserta metadatanya. Segala sesuatu di luar covered set tetap berada di luar pernyataan tersebut.