InvalidSignatureException when using custom httpclient about aws-sdk-go HOT 7 CLOSED

@sarahzinger -- Is your custom HTTP client implementation modifying the request in any way? (it's not immediately clear to me from the linked code)

Modifying the request within the HTTP client itself is liable to invalidate the request signature.

from aws-sdk-go.

This issue has not received a response in 1 week. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.

from aws-sdk-go.

Hi @lucix-aws . We send the request via a SOCKs proxy, but the request is not modified in any way. As the code shows, however, we do replace the HTTPClient's transport to use our Transport which contains the socks dialer.

I wonder, what is happening within your transport that might cause replacing it to invalidate the signature?

from aws-sdk-go.

I wonder, what is happening within your transport that might cause replacing it to invalidate the signature?

As far as we're concerned the SDK is just using the default net/http client (not literally http.DefaultClient per se but we are using the standard library's implementation)

Note that I'm not necessarily just talking about mutation of the request, extension (generally via additional headers inserted by the proxy) can also invalidate the signature. We've seen this happen fairly often with inserting proxies into the request workflow - generally the proxy will add a forwarding header (usually X-Forwarded-For) which breaks the signature, which is calculated using all X-* headers.

from aws-sdk-go.

I am quite sure that the use of the SOCKS proxy dialer is completely transparent to the target of the original request: The socks proxy we use can forward any TCP requests, so it would not make any changes specific to the HTTP protocol (like headers).

Are anything other than X-* headers used to calculate the signature?

from aws-sdk-go.

You can read more about the sigv4 algorithm here.

Beyond that though I'm going to close this issue. If the default configuration is working, and a caller-provided custom transport causes the issue to surface, we can only assume it's a fault of that customization absent evidence to the contrary. The only advice I can give you based on this information is to compare requests as outgoing from the SDK and as outgoing from the proxy to verify whether anything is being changed.

from aws-sdk-go.

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

from aws-sdk-go.