HTTP Message Signatures qua proxy: hop nào làm hỏng chữ ký

HTTP Message Signatures qua proxy là chuyện kiểm một chữ ký đặt trên các thành phần của request HTTP khi request đi qua một hay nhiều trung gian. Mỗi trung gian có thể thêm header, đổi đường dẫn, sửa nội dung, và chỉ một số thay đổi làm chữ ký hỏng. ProxyVN dùng thư viện http-message-signatures 3.0.0 ký request bằng Ed25519, cho đi qua hai hop tự viết có cấu hình sửa từng thứ, và verify ở mỗi hop cả bản nhận được lẫn bản gửi đi.

HTTP Message Signatures qua proxy: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và giới hạn.

Bài toán cần giải

Một đối tác yêu cầu mọi request xuất dữ liệu phải ký theo RFC 9421. Request của nhóm đi qua proxy công ty rồi qua reverse proxy của đối tác trước khi tới máy chủ xử lý. Thỉnh thoảng máy chủ báo chữ ký sai, dù mã ký không đổi. Câu hỏi là trung gian nào đã sửa gì, và sửa nào được phép.

Đầu ra nghiệm thu

Đầu ra là một request đã ký, tám cấu hình hop khác nhau, mỗi cấu hình sửa một thứ: không sửa, thêm Via, đổi đường dẫn, đổi Content-Type, sửa body, đảo query, đổi Host, ký thêm. Kèm theo là bảng kết quả verify ở hop 1, hop 2 và origin, trước và sau mỗi lần sửa.

Chữ ký HTTP khác chứng chỉ TLS

TLS bảo vệ đường truyền giữa hai đầu của một kết nối. Request đi qua proxy kết thúc TLS là có nhiều kết nối, mỗi đoạn một chứng chỉ. Chữ ký HTTP gắn với chính thông điệp, đi xuyên qua mọi đoạn. Bài này không bàn chứng chỉ, chỉ bàn chữ ký ở tầng HTTP.

Ranh giới với Content-Digest và SigV4

Content-Digest chỉ là mã băm của body, không có khóa, ai sửa body cũng tính lại được. AWS SigV4 là cách ký riêng của AWS với canonical request theo quy tắc của họ. RFC 9421 là chuẩn chung, chọn được thành phần nào được ký. Bài này dùng Content-Digest như một thành phần được ký, không bàn riêng về nó.

Ranh giới với DPoP

Bài DPoP trong cụm này ký một JWT nhỏ chỉ chứa phương thức, địa chỉ, thời điểm và mã băm token. RFC 9421 ký các trường thật của thông điệp, kể cả header tùy chọn. Hai cơ chế có thể dùng cùng nhau. Bài này không dùng chung test với bài DPoP.

Giới hạn của lab

Nói rõ ngay. Lab không dùng proxy hay máy chủ thật của bên thứ ba. Ba máy chủ Python tự viết trên cổng 9489, 9490 và 9491 đóng vai hop 1, hop 2 và origin. Thư viện ký và verify là http-message-signatures 3.0.0 thật, khóa Ed25519 sinh mới mỗi lần chạy.

Ai nên đọc bài này

Người tích hợp API yêu cầu ký RFC 9421. Người vận hành proxy hay reverse proxy đứng giữa client và API đó. Người gỡ lỗi chữ ký sai không rõ nguyên nhân, cần cách khoanh vùng hop gây lỗi.

HTTP Message Signatures qua proxy: kiểm chữ ký khi intermediary thay trường được ký

Phần này tóm tắt RFC 9421.

Ký thành phần, không ký cả thông điệp

RFC 9421 định nghĩa cách tạo chữ ký trên một danh sách thành phần của thông điệp HTTP. Thành phần có thể là header, hoặc thành phần dẫn xuất như phương thức, authority, đường dẫn, query. Thứ gì không nằm trong danh sách thì không được bảo vệ.

Thành phần dẫn xuất

Thành phần dẫn xuất bắt đầu bằng dấu a còng. Lab dùng bốn thành phần: phương thức, authority là host và cổng, đường dẫn, và query. Còn có target-uri cho cả địa chỉ, và query-param cho từng tham số riêng.

Bảng: Thành phần dẫn xuất

Thành phần	Lấy từ	Hop hay đổi không
@method	Phương thức	Hiếm
@authority	Host và cổng	Reverse proxy hay đổi
@path	Đường dẫn	Reverse proxy hay đổi
@query	Chuỗi query	Một số proxy chuẩn hóa
content-type	Header	Một số proxy thêm charset
content-digest	Header	Không, nếu body không đổi

Hai header kết quả

RFC định nghĩa header Signature-Input chứa danh sách thành phần và tham số, header Signature chứa chữ ký. Cả hai dùng nhãn, ví dụ pyhms trong lab, để một request chứa được nhiều chữ ký. Tham số gồm created, keyid, alg, và có thể có expires, nonce, tag.

Chuỗi cơ sở

Bên ký dựng một chuỗi cơ sở từ giá trị của từng thành phần theo đúng thứ tự trong danh sách, thêm dòng tham số cuối. Bên verify dựng lại chuỗi này từ thông điệp nhận được. Một ký tự khác ở bất kỳ thành phần nào là chuỗi khác, chữ ký không khớp.

Body không tự được ký

RFC 9421 không ký body trực tiếp. Muốn bảo vệ body, tính Content-Digest theo RFC 9530 rồi đưa header này vào danh sách thành phần. Bên verify phải tự kiểm body có khớp Content-Digest không. Lab sẽ cho thấy bỏ bước này là bỏ toàn bộ bảo vệ body.

Nhiều chữ ký trên một thông điệp

RFC cho phép một thông điệp mang nhiều chữ ký với nhãn khác nhau. Một trung gian có thể thêm chữ ký của chính nó, ví dụ để xác nhận đã kiểm tra hay đã thêm header. Bên nhận chọn chữ ký cần verify theo nhãn hoặc tag.

Trung gian được làm gì

Trung gian thêm header không nằm trong danh sách thì chữ ký vẫn đúng. Trung gian sửa thành phần nằm trong danh sách thì chữ ký hỏng. Quy tắc đơn giản này là cả bài. Việc khó là biết trung gian thật đang sửa những gì.

HTTP Message Signatures qua proxy: chọn trường HTTP cần bao phủ bởi chữ ký

Phần này chọn danh sách thành phần cho request xuất dữ liệu và lý do.

Request mẫu

Request là POST tới đường dẫn v1/export, query fmt bằng jsonl và day bằng 2026-11-05, body JSON chọn bộ dữ liệu gia-sp và giới hạn 10 dòng. Content-Type là application/json, User-Agent là cli-du-lieu.

Danh sách thành phần

Lab ký sáu thành phần: phương thức, authority, đường dẫn, query, content-type, content-digest.

COVER = ("@method", "@authority", "@path", "@query", "content-type", "content-digest")

Phương thức và đường dẫn quyết định thao tác. Query quyết định ngày và định dạng. Content-digest khóa body. Content-type quyết định cách máy chủ đọc body.

Vì sao không ký User-Agent

User-Agent không ảnh hưởng ý nghĩa request, và proxy công ty hay thay nó. Ký nó chỉ làm chữ ký dễ hỏng mà không thêm bảo vệ. Lab cố tình để User-Agent ngoài danh sách, rồi cho hop sửa nó.

Vì sao không ký Via

Via do trung gian thêm sau khi client đã ký. Client không biết trước giá trị này. Ký Via từ phía client là không thể. Nếu origin cần tin Via, trung gian phải tự ký, như ca S8.

Authority hay target-uri

Target-uri gồm scheme, host, đường dẫn và query trong một chuỗi. Tách thành authority, path, query giúp khi lỗi biết ngay thành phần nào khác. Lab chọn tách. Với hệ thống đã ổn định, target-uri gọn hơn.

Ký thời điểm

Tham số created ghi thời điểm ký. Bên verify của thư viện mặc định chấp nhận chữ ký trong một ngày. Lab giữ mặc định. Với API xuất dữ liệu, cửa sổ ngắn hơn giảm rủi ro gửi lại request cũ.

Tag phân biệt chữ ký

Lab đặt tag client cho chữ ký của client, tag proxy cho chữ ký của hop. Bên verify yêu cầu tag cụ thể, nên không nhầm chữ ký này với chữ ký kia. Thư viện 3.0.0 bắt buộc chọn tag khi có nhiều chữ ký.

HTTP Message Signatures qua proxy: ký request fixture và lưu thông điệp trước intermediary

Phần này ký request và xem nó trông thế nào trước khi đi.

Khóa và bộ ký

Lab sinh khóa Ed25519 cho client và cho hop 1, đặt vào bộ giải khóa theo keyid.

from http_message_signatures import HTTPMessageSigner, HTTPMessageVerifier, MappingKeyResolver, algorithms
 
KR = MappingKeyResolver(public_keys={"client-1": ck.public_key(), "hop-1": pk.public_key()},
                        private_keys={"client-1": ck, "hop-1": pk})
signer = HTTPMessageSigner(signature_algorithm=algorithms.ED25519, key_resolver=KR)

Với hệ thật, mỗi bên chỉ giữ khóa riêng của mình. Lab gộp cho gọn.

Ký

Hàm sign nhận request đã chuẩn bị của requests, keyid, tag, danh sách thành phần và body.

signer.sign(req, key_id="client-1", tag="client",
            covered_component_ids=COVER, body=body)

Khi có body, thư viện tự tính và thêm Content-Digest trước khi ký.

Header sau khi ký

Signature-Input

Output thật của lab.

Signature-Input: pyhms=("@method" "@authority" "@path" "@query" "content-type" "content-digest");created=1793865201;keyid="client-1";alg="ed25519";tag="client"
Content-Digest: sha-256=:qfx4Y6BwQxUQZ+kuuvqGs+r/UmCDBQf2EFdlOVrU4vI=:

Signature-Input cho biết chính xác những gì đã được ký. Đây là thứ đầu tiên cần đọc khi gỡ lỗi.

Lưu thông điệp trước khi gửi

Khi gỡ lỗi, lưu bản request ngay sau khi ký: phương thức, URL đầy đủ, mọi header, body. So bản này với bản origin nhận được là cách nhanh nhất để thấy hop nào sửa gì. Lab thay bước lưu bằng việc verify ở từng hop.

Verify ở từng hop

Mỗi hop lab verify request nhận được bằng khóa công khai của client, áp sửa đổi theo cấu hình, rồi verify lại bản sắp gửi đi. Hai kết quả cho biết hop này nhận bản tốt hay xấu, và có làm hỏng không.

v_in = check(name, method, url, headers, body)
path, hd2, body2 = mutate(name, method, path, headers, body)
v_out = check(name, method, new_url, hd2, body2)

Trên hệ thật, các hop không có khóa công khai của client. Đây là công cụ chẩn đoán của lab, không phải mô hình triển khai.

Authority là host mà client nhìn thấy

Client gọi hop 1 ở cổng 9489, nên authority trong chữ ký là 127.0.0.1:9489. Các hop chuyển tiếp giữ nguyên header Host. Origin dựng lại authority từ Host nhận được, nên vẫn khớp. Hop nào đổi Host là đổi authority.

HTTP Message Signatures qua proxy: sửa từng trường có và không được ký

Phần này chạy tám cấu hình hop và đọc kết quả.

S1: không sửa

Hai hop chuyển nguyên. Mọi lần verify đều hợp lệ, kể cả ở origin.

('hop1', 'nhan', 'HOP LE', 'gui di', 'HOP LE')
('hop2', 'nhan', 'HOP LE', 'gui di', 'HOP LE')
('origin', 'nhan', 'HOP LE', ...)

Ca đối chứng cho mọi ca sau. Nếu S1 đã sai, lỗi nằm ở cách dựng lại request phía verify, chưa cần nghĩ tới hop.

Đọc kết quả mỗi ca

Mỗi dòng output có năm phần: tên hop, kết quả verify bản nhận, kết quả verify bản gửi. Riêng origin có thêm kết quả verify khi bỏ qua body và kết quả verify chữ ký proxy nếu có. Ca nào cũng chạy cùng request gốc, cùng khóa, chỉ khác cấu hình hop.

S2: thêm Via và đổi User-Agent

Hop 1 thêm Via, X-Forwarded-For và đổi User-Agent. Cả ba header đều ngoài danh sách ký. Mọi lần verify vẫn hợp lệ.

('hop1', 'nhan', 'HOP LE', 'gui di', 'HOP LE')

Đây là hành vi bình thường của proxy, chữ ký chịu được.

S3: reverse proxy bỏ tiền tố

Hop 2 bỏ tiền tố v1 khỏi đường dẫn trước khi chuyển vào origin. Hop 2 nhận bản hợp lệ, gửi đi bản sai. Origin báo sai.

('hop2', 'nhan', 'HOP LE', 'gui di', 'SAI: InvalidSignature')
('origin', 'nhan', 'SAI: InvalidSignature', ...)

Bảng verify khoanh vùng ngay: lỗi sinh ra ở hop 2.

S4: thêm charset vào Content-Type

Hop 1 đổi Content-Type thành application/json kèm charset utf-8. Ý nghĩa gần như không đổi, nhưng chuỗi khác. Từ hop 1 trở đi, mọi lần verify đều sai.

Thay đổi vô hại vẫn làm hỏng

Thay đổi nhỏ vẫn hỏng

Ca S4 là kiểu lỗi khó chịu nhất. Proxy chuẩn hóa header với ý tốt, máy chủ đọc body vẫn đúng, nhưng chữ ký hỏng. Chọn ký content-type thì phải chắc mọi trung gian không chạm vào nó. Nếu không chắc, cân nhắc bỏ nó khỏi danh sách và để content-digest lo phần body.

S5: sửa body

Hop 2 đổi giới hạn trong body từ 10 thành 1000, giữ nguyên mọi header. Verify có kiểm body báo sai ngay ở hop 2 với lý do Content-Digest không khớp body.

('hop2', 'nhan', 'HOP LE', 'gui di', 'SAI: InvalidSignature Content-Digest does not match the message body')
('origin', 'nhan', 'SAI: ...', 'bo qua body: HOP LE', ...)

Cột thứ tư của origin là phát hiện quan trọng nhất của lab.

Verify không truyền body thì bị lừa

Origin verify lần hai mà không truyền body vào hàm verify. Kết quả: hợp lệ. Chữ ký phủ header Content-Digest, header đó không đổi, nên chữ ký đúng. Body đã bị sửa nhưng chữ ký vẫn báo hợp lệ. Bên verify phải luôn kiểm body với Content-Digest, như RFC yêu cầu.

S6: đảo thứ tự query

Hop 1 đảo thứ tự hai tham số query, ngày đứng trước định dạng. Máy chủ đọc tham số vẫn đúng, nhưng chuỗi query khác. Verify sai từ hop 1. Nếu trung gian hay chuẩn hóa query, ký từng tham số bằng query-param thay vì cả chuỗi query.

S7: đổi Host

Hop 2 đổi Host sang tên nội bộ trước khi chuyển vào origin. Authority khác, verify sai. Reverse proxy thường làm việc này khi chuyển vào dịch vụ nội bộ.

S8: hop ký thêm

Hop 1 thêm Via rồi ký thêm một chữ ký với tag proxy, phủ phương thức, authority, đường dẫn và Via. Origin verify được cả hai: chữ ký client và chữ ký proxy.

('origin', 'nhan', 'HOP LE', 'bo qua body: HOP LE', 'chu ky proxy: HOP LE')

Lần đầu ký thêm, lab gặp lỗi của thư viện: Content-Digest đã có, phải truyền use_existing_digest bằng True. Sửa xong thì chạy.

HTTP Message Signatures qua proxy: xác minh ở origin và phân biệt với digest payload

Phần này gom bảng kết quả, tài sản chính của bài, và nói về cách origin nên verify.

Bảng verify trước và sau từng hop

Bảng verify từng hop

Bảng dưới là đầu ra nghiệm thu, gom từ output thật.

Bảng: Bảng verify trước và sau từng hop

Ca	Sửa ở đâu	Sửa gì	Hop 1 nhận	Hop 1 gửi	Hop 2 nhận	Hop 2 gửi	Origin
S1	Không		Hợp lệ	Hợp lệ	Hợp lệ	Hợp lệ	Hợp lệ
S2	Hop 1	Via, User-Agent	Hợp lệ	Hợp lệ	Hợp lệ	Hợp lệ	Hợp lệ
S3	Hop 2	Bỏ v1 khỏi path	Hợp lệ	Hợp lệ	Hợp lệ	Sai	Sai
S4	Hop 1	Charset Content-Type	Hợp lệ	Sai	Sai	Sai	Sai
S5	Hop 2	Body	Hợp lệ	Hợp lệ	Hợp lệ	Sai	Sai, bỏ body thì hợp lệ
S6	Hop 1	Đảo query	Hợp lệ	Sai	Sai	Sai	Sai
S7	Hop 2	Host	Hợp lệ	Hợp lệ	Hợp lệ	Sai	Sai
S8	Hop 1	Via và ký thêm	Hợp lệ	Hợp lệ	Hợp lệ	Hợp lệ	Cả hai hợp lệ

Đọc bảng để tìm hop gây lỗi

Hop gây lỗi là hop có nhận hợp lệ mà gửi sai. S3 và S7 ở hop 2, S4 và S6 ở hop 1. Trên hệ thật không có verify ở mỗi hop, nhưng lưu request ở mỗi đầu rồi so cũng cho kết quả tương tự.

Signature và digest khác nhau thế nào

Content-Digest là mã băm, ai cũng tính được. Một hop sửa body rồi tính lại Content-Digest thì digest khớp body mới. Chỉ khi Content-Digest nằm trong danh sách ký, chữ ký mới phát hiện được việc tính lại, vì header đã đổi. Digest phát hiện body hỏng do truyền, chữ ký phát hiện body bị sửa có chủ đích.

Origin verify thế nào cho đúng

Verify phải kiểm body

Origin verify với ba yêu cầu: chọn đúng tag, yêu cầu danh sách thành phần tối thiểu, và truyền body để kiểm Content-Digest.

verifier.verify(req, expect_tag="client", body=body,
                require_components=COVER)

Thiếu require_components, một chữ ký chỉ phủ phương thức cũng được coi là hợp lệ. Thiếu body, ca S5 lọt qua.

Tách lỗi chữ ký và lỗi digest

Thư viện trả InvalidSignature cho cả hai loại, với thông báo khác nhau. Lỗi digest có câu Content-Digest không khớp body. Lỗi chữ ký thường không có mô tả. Log của origin ghi cả thông báo để phân biệt hop sửa header với hop sửa body.

Origin biết authority công khai

Ca S7 cho thấy origin dựng authority từ Host nhận được. Nếu reverse proxy đổi Host, origin cần biết host công khai để dựng lại chuỗi cơ sở. Cách sửa giống bài DPoP: cấu hình địa chỉ công khai ở origin, đừng bắt client ký địa chỉ nội bộ.

Chữ ký của trung gian

Ca S8 cho thấy một trung gian có khóa riêng có thể ký xác nhận những gì nó thêm. Origin tin Via hay X-Forwarded-For chỉ khi chữ ký proxy hợp lệ. Cách này chỉ dùng được khi origin có khóa công khai của trung gian, tức hai bên đã thỏa thuận.

Thời điểm ký và cửa sổ chấp nhận

Mỗi lần verify, thư viện so created với giờ hiện tại theo cửa sổ max_age, mặc định một ngày. Request đi qua hai hop trong lab mất vài mili giây, không gần cửa sổ. Trên hạ tầng thật, request bị giữ trong hàng đợi lâu có thể quá hạn. Cửa sổ quá ngắn gây lỗi lẻ tẻ, khó lần ra.

Verify sớm ở biên

Nếu đối tác có cổng API ở biên, verify ở đó giúp từ chối request hỏng trước khi tốn tài nguyên phía sau. Nhưng nếu cổng biên verify rồi cổng sau sửa request, origin vẫn phải verify lại. Lab cho thấy một request hợp lệ ở hop 1 có thể sai ở origin.

HTTP Message Signatures qua proxy: cấu hình trung gian cho đúng

Phần này nói với người vận hành proxy và reverse proxy.

Danh sách những thứ không được chạm

Lấy Signature-Input của một request mẫu, liệt kê thành phần được ký. Proxy không được đổi bất kỳ thành phần nào trong đó. Với lab, đó là phương thức, host, đường dẫn, query, content-type, content-digest và body.

Chuẩn hóa header

Nhiều proxy chuẩn hóa header: thêm charset, viết lại chữ hoa thường của giá trị, gộp header trùng. Tắt chuẩn hóa cho đường dẫn của API có chữ ký. Ca S4 cho thấy một thay đổi nhỏ là đủ làm hỏng.

Viết lại đường dẫn

Reverse proxy hay bỏ tiền tố như ca S3. Có ba cách: không bỏ tiền tố, origin dựng chuỗi cơ sở với đường dẫn công khai, hoặc client ký đường dẫn tương đối đã thỏa thuận. Cách thứ hai ít đụng tới client nhất.

Nén và giải nén

Proxy giải nén hay nén lại body sẽ làm body đổi, Content-Digest không còn khớp. RFC 9530 phân biệt digest của nội dung và digest của biểu diễn. Lab chỉ dùng Content-Digest trên byte gửi đi, không thử nén.

Proxy kết thúc TLS

Proxy kết thúc TLS rồi mở kết nối mới tới origin không làm hỏng chữ ký, nếu nó không sửa thành phần được ký. Đây là lợi thế của chữ ký tầng HTTP so với cơ chế gắn vào TLS. Lab chạy HTTP thường, không thử TLS.

Kiểm cấu hình bằng bộ ca của lab

Chạy tám ca của lab qua proxy thật thay cho hop tự viết. Ca nào verify sai ở origin mà trong lab là hợp lệ, proxy thật đang sửa thứ gì đó. So request trước và sau proxy để tìm ra.

HTTP Message Signatures qua proxy: thiết kế phía client

Phần này nói về những quyết định phía client mà bảng kết quả gợi ra.

Ký ngay trước khi gửi

Client ký sau khi request đã hoàn chỉnh: mọi header, body, URL cuối cùng. Thư viện HTTP tự thêm header sau bước ký thì không sao nếu header đó ngoài danh sách. Nhưng nếu thư viện tự đổi URL, như thêm dấu gạch chéo cuối, chữ ký sẽ sai từ trước khi request rời máy.

Đừng để thư viện chuẩn hóa query

Một số thư viện HTTP sắp xếp lại hay mã hóa lại tham số query. Ký trên chuỗi query trước khi thư viện xử lý, rồi gửi chuỗi đã xử lý, là sai ngay từ client. Lab dựng request bằng requests, ký trên request đã chuẩn bị, nên chuỗi ký và chuỗi gửi là một.

Retry phải ký lại

Khi request được gửi lại sau lỗi mạng, chữ ký cũ vẫn đúng nếu request không đổi và chưa quá hạn. Nhưng nếu máy chủ dùng nonce hay cửa sổ thời gian ngắn, ký lại cho mỗi lần gửi. Ký lại tốn rất ít so với một request mạng.

Giữ khóa riêng

Khóa riêng của client nằm trong kho bí mật, không nằm trong mã hay tệp cấu hình chung. Keyid trong chữ ký giúp máy chủ chọn khóa công khai, và giúp xoay khóa: phát hành khóa mới với keyid mới, chạy song song một thời gian, rồi bỏ khóa cũ.

Log Signature-Input, không log Signature

Signature-Input cho biết đã ký gì, đủ để gỡ lỗi. Signature là giá trị chữ ký, log nó không giúp gì mà còn để lộ dữ liệu không cần thiết. Lab in Signature-Input và Content-Digest, không in Signature.

Bắt đầu với danh sách ngắn

Danh sách thành phần càng dài, càng nhiều chỗ để trung gian làm hỏng. Bắt đầu với phương thức, authority, path, content-digest. Thêm query và content-type khi đã chắc trung gian không chạm. Bảng của lab cho thấy mỗi thành phần thêm vào là thêm một cột rủi ro.

Thỏa thuận với đối tác

Danh sách thành phần bắt buộc thường do bên nhận quy định. Hỏi đối tác danh sách tối thiểu họ yêu cầu, thuật toán họ nhận, cửa sổ thời gian. Ghi các thông tin này vào tài liệu tích hợp, cùng một request mẫu đã ký để hai bên đối chiếu.

HTTP Message Signatures qua proxy: đầu ra nghiệm thu và phần chưa chạy

Phần này gom tiêu chí đạt, tệp đầu ra và những gì còn phải kiểm.

Danh sách kiểm tra

Hệ thống đạt khi mọi dòng dưới đây đúng.

• Danh sách thành phần ký được chọn có lý do, không ký header proxy hay đổi.
• Body được bảo vệ bằng content-digest trong danh sách ký.
• Origin truyền body khi verify để kiểm Content-Digest.
• Origin yêu cầu danh sách thành phần tối thiểu và đúng tag.
• Origin dựng authority và path theo địa chỉ công khai.
• Proxy không chuẩn hóa header được ký, không đảo query.
• Chữ ký của trung gian chỉ được tin khi có khóa đã thỏa thuận.
• Có bộ ca kiểm proxy chạy lại khi đổi cấu hình.

Tệp đầu ra của lab

Lab có run.py chứa hai hop, origin, client và tám ca. Output in Signature-Input, Content-Digest và bảng verify ở từng hop. Chạy lại mất vài giây, mỗi lần sinh khóa mới.

Những gì lab chưa chạy

Chưa chạy proxy thật như nginx hay proxy doanh nghiệp, chưa có TLS, chưa thử nén, chưa thử query-param, target-uri, expires, nonce, chữ ký trên response. Các hop chỉ sửa những gì lab cấu hình.

Kiểm lại trên hạ tầng thật

Gửi request đã ký qua proxy công ty và reverse proxy của đối tác, lưu bản trước và sau mỗi đoạn nếu được phép. Với đoạn không kiểm soát, nhờ đối tác chia sẻ Signature-Input và chuỗi cơ sở họ dựng được.

Proxy ở đâu trong luồng này

Proxy là trung gian của bài: forward proxy không sửa thì chữ ký vẫn đúng, như ca S1 và S2. Với API được phép truy cập, khi cần IP Việt Nam ổn định, anh em có thể mua proxy tại trang chủ ProxyVN. Proxy dạng CONNECT không chạm vào header nên không làm hỏng chữ ký. Vai trò proxy có ở bài Web Scraping proxy là gì, cách ghi chuỗi proxy ở bài định dạng proxy.

HTTP Message Signatures qua proxy: câu hỏi thường gặp

Các câu dưới đây gom những điểm anh em hay hỏi.

Proxy thêm header có làm hỏng chữ ký không?

Không, nếu header đó không nằm trong danh sách ký. Ca S2 thêm Via và đổi User-Agent, chữ ký vẫn hợp lệ.

Vì sao thêm charset cũng làm hỏng?

Vì content-type nằm trong danh sách ký, và chuỗi đã khác. Ca S4 tái lập đúng chuyện này.

Chữ ký có bảo vệ body không?

Chỉ khi content-digest nằm trong danh sách ký và bên verify kiểm body với digest. Ca S5 cho thấy verify không truyền body thì body bị sửa vẫn lọt.

Reverse proxy đổi đường dẫn thì làm sao?

Origin dựng chuỗi cơ sở với đường dẫn công khai, hoặc reverse proxy không đổi đường dẫn. Ca S3 cho thấy lỗi sinh ra ở hop bỏ tiền tố.

Trung gian có thể ký không?

Có. RFC cho phép nhiều chữ ký trên một thông điệp. Ca S8 cho thấy origin verify được cả chữ ký client và chữ ký proxy theo tag.

Nên dùng Ed25519 hay thuật toán khác?

Lab dùng Ed25519 vì khóa ngắn và ký nhanh. Thư viện còn hỗ trợ ECDSA P-256, RSA-PSS, HMAC. Chọn theo yêu cầu của bên nhận. HMAC dùng khóa chung nên không hợp khi bên nhận không được phép ký thay client.

Content-Digest có cần khi request không có body?

Request GET không body thì không cần. Lab dùng POST có body nên ký content-digest. Thư viện tự thêm digest khi được truyền body lúc ký.

Bài có chạy proxy thật không?

Không. Hai hop và origin là máy chủ Python tự viết, thư viện ký và verify là thật. Hành vi của proxy cụ thể cần kiểm riêng.

HTTP Message Signatures qua proxy và những điều cần nhớ

HTTP Message Signatures qua proxy chỉ hỏng khi trung gian chạm vào thành phần đã ký, nên biết danh sách ký là biết proxy được làm gì. Hãy ký content-digest, luôn truyền body khi verify, cấu hình origin theo địa chỉ công khai. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em chạy bộ ca HTTP Message Signatures qua proxy trên hạ tầng thật.