Verifying client certificate by passing client cert in the header

Question

I'm implementing client certificate authentication. My server is behind a proxy to which I have no control of. And also I don't have any control over the client side communication. During every request, the client side sends an additional header containing the client cert.

From the client help doc,

If your server is behind an HTTPS proxy that does not convey client certificates, then the client identity could be placed in an additional HTTP header as BASE64-encoded CMS Detached Signature of the message. Your server can validate the body with the detached signature with this header. If the validation is successful, your server can assume that the message came from the signer, whose certificate is stored in the signature.

I tried this and it worked fine.

I then set up burp proxy to the client, made the client to trust burp server certificate and captured one of client's request in burp. Then with repeater, I resend the request, and the request passed.

I'm a beginner, so I'm unsure whether this burp style capturing is an easy thing for any attacker. is it?

My doubt is "Is depending solely on this detached signature in the header a good idea to verify the authenticity of clients?" or should I go with the TLS handshake route by forwarding requests from the proxy to my server (but still I'm unsure if I could configure the proxy).

Answer 1

A client certificates at TLS level authenticates a TLS session while the CMS detached message signature you use only authenticates the specific message.

This means the signature is not a proof that the sender of the HTTP request owns the client certificate but only that the message inside the request was created by the client. It does not protect against somebody else taking this message and replaying it together with the signature.

HTTPS usually protects the transport against sniffing and modification, so normally a MITM can not grab the message and signature and replay it. Even with burp or similar the client would not to trust the certificate generated by the MITM, since the attacker cannot forward the original server certificate. With proper client configuration the client will not trust the MITM though.

But for example somebody at the server side could extract the message + signature and misuse it. So you should not trust a single signed message as proof that a connection was created by the client. You might probably do this though if you can make sure that the message was not replayed, for example because the content of the message contain some random data given by the server and reflected with signature by the client.