I have been doing some research on using the right security mechanism for our REST web service. I was going through the documentation on HTTP Signatures -> https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12. Based on this documentation some of HTTP headers are selected, hashed and digitally signed. This signed string is updated in the HTTP header. The service provider will recreate the hash (based on received HTTP headers) and verify the signed string to authenticate the client. This also in turn proves the message is not tampered with. Is it possible for some hacker who has access to the network to just change the HTTP body without changing the header attributes that are part of the signature. If yes, then the message received by service provider is not the one intended by the client is it not? So, how does this way of signing the HTTP request ensure message integrity?
1 1 1 silver badge asked Jan 23, 2020 at 21:23 947 6 6 silver badges 13 13 bronze badges Note: Draft-cavage is now being developed at the IETF HTTP-Bis working group. ietf.org/archive/id/… Commented Mar 22, 2021 at 8:42Is it possible for some hacker who has access to the network to just change the HTTP body without changing the header attributes that are part of the signature.
Yes. Anything that isn't covered by the signature can be altered without detection — given, of course, that the attacker is also able to subvert other integrity protection mechanisms (TLS also provides this).
If yes, then the message received by service provider is not the one intended by the client is it not?
True. There is just one correction. The parts of the message that are integrity protected cannot be altered without detection. So while the whole message may be forged, there may be some parts that are still intact and match the original.
So, how does this way of signing the HTTP request ensure message integrity?
It only ensures integrity for the parts that the client chooses to sign. To provide integrity for the full message, you also need to check the headers , which were signed and make sure it covers everything you would like to process.
If you would like to learn more about signature schemes and alternatives, check out a post I wrote about precisely this: Web API Authentication Guide, Signature Schemes.