New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http_aws_sigv4: Improve payload hashing #1
base: aws-sigv4-headers-rebased-master
Are you sure you want to change the base?
http_aws_sigv4: Improve payload hashing #1
Conversation
72d8a3c
to
b595a41
Compare
b595a41
to
3ebc602
Compare
First thanks you for tackling
kind of, |
3ebc602
to
afdfd05
Compare
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
Thanks. Now I see, you are right. |
Put here for reference: minio/minio#5340 |
f1d8bf9
to
1dc64b4
Compare
Actually, there is already such an option: when service is set to |
I've just double-checked. S3 rejects responses without
Also, S3 seems to be not validating payload when the payload is empty. In this case |
Up to this patch, canonical header, and signed header was hardcoded in the aws-sigv4 signature. This patch handle canonical headers and signed headers creation as it is explain here: https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html The algo tell that signed and canonical must contain at last host and x-amz-date. So we check whatever thoses are present in the curl http headers list. If they are, we use the one enter by curl user, otherwise we generate them. then we to lower, and remove space from each http headers plus host and x-amz-date, then sort them all by alphabetical order. This patch also fix a bug with host header, which was ignoring the port. Because I now handle the port in the signature, I had to hardcode the host in the tests, in which the port was random, which was making imposible to had a signature in the tests data. Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
afdfd05
to
af197f2
Compare
1. Allow the user to provide precomputed SHA256 of the payload by providing X-Provider-Content-Sha256 header. If X-Provider-Content-Sha256 header is present then its value MUST coincide with payload hash in the canonical request text, so we reuse its value for the canonical request. 2. Fallback to the empty SHA otherwise. There is no reason to calculate payload hash when X-Provider-Content-Sha256 is missed, since the server will fail to check the signature. Note, that X-Provider-Content-Sha256 is mandatory required for S3 API [1] while some implementations are known to rely on this header to reconstruct the canonical request [2]. [1] https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html [2] minio/minio#5340 Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
4640e7e
to
b857d01
Compare
b857d01
to
d6bea06
Compare
60d8d52
to
acfbf2d
Compare
0ebf434
to
8cf770a
Compare
62548a0
to
8c6e060
Compare
d11b05f
to
96eb43c
Compare
Hi,
I think the following could be useful for your PR curl#7966. Unfortunately, AWS SIGv4 implementation in curl is far from ideal currently.
Introduce X-Provider-Content-Sha256 header as it is required by the specs [1]
and we anyway need to know its value to calculate the CanonicalRequest.
Additionally:
Allow the user to provide precomputed SHA256 of the payload (when it is known in
advance)
Fallback to "Unsigned payload" when postdata is not available instead of
providing the hash for empty payload and having the wrong signature
verification. postdata is only (can be) available for POST method and may be
missed for non-empty payload.
For instance, the following valid use-case will lead to PUT request with
empty postdata:
[1] https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html
Signed-off-by: Matwey V. Kornilov matwey.kornilov@gmail.com