https://linen.dev logo
Join Slack
Powered by
Hello Team, I am trying to debug the request to AW...
# wiremock-java
s
Hello Team, I am trying to debug the request to AWS sts service through wiremock which is resulting in 
SignatureDoesNotMatch
because wiremock is changing request in someway before forwarding it to aws. If I remove the wiremock proxy, the request is successful. Here is the comparison of clients with and without wiremock proxy
Copy code
ProxyConfiguration proxyConfig = ProxyConfiguration.builder().endpoint(URI.create("https://" + WIREMOCK_HOST + ":" + WIREMOCK_PORT)).build();
        TrustManager[] trustAllCerts = createTrustAllManager();
        SdkHttpClient httpClient = ApacheHttpClient.builder()
                .proxyConfiguration(proxyConfig)
                .tlsTrustManagersProvider(() -> trustAllCerts)
                .build();
        return StsClient.builder()
                .httpClient(httpClient) <---------removing this will be success
                .region(Region.US_WEST_2)
                .endpointOverride(
                        URI.create("<https://sts.us-west-2.amazonaws.com>"))
                .build();
    }
my wiremock server is configured as follow:
Copy code
wireMockServer = new WireMockServer(WireMockConfiguration.options()
                .httpsPort(WIREMOCK_PORT)
                .keystorePath("/Users/something/Desktop/wiremock-keystore.jks").keystorePassword("something")
                .withRootDirectory("src/test/resources")
                .enableBrowserProxying(true));

        wireMockServer.start();
With this we are sure that, wiremock is certainly changing the request in some way. How can I force the wiremock not to change anything in request? Thread in Slack Conversation
t
I’m not sure if this will make any difference, but generally it’s not a good idea to try to forward proxy over HTTPS, so I’d suggest changing to HTTP for the proxy endpoint.
s
Thanks for your response @Tom! The wiremock proxy was 
http
before this and it had the same results. I have 
https
a try just in case if that would help 🙂 But this didn't make any difference. Do you know if wiremock is injecting some headers in anyway which could break the signature mismatch ?
Ideally, if wiremock is proxy, it shouldn't change anything in the request before forwarding it to the target.
t
We’ve seen this issue in the past with reverse proxying because WireMock (by necessity) has to change the host header, given that the requested domain and the AWS API domain are different. But my experience is that it works when forward proxying as you are.
I suggest setting a breakpoint in the signer code to see which request attributes are being used to build the signature. Then we can figure out which is being changed.
👍 1
s
But my experience is that it works when forward proxying as you are.
Exactly!
@Tom Wanted to update on this thread, I tried to get some snapshots on the signed request and it doesn't seems like anything wiremock could change in the signed headers. The debug logs are also here and matches with the signed request. Couldn't figure out yet, what's getting changed in the request with wiremock as forward proxy.
Copy code
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> POST / HTTP/1.1
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Authorization: AWS4-HMAC-SHA256 Credential=ACCESSKEYID/20240822/us-west-2/sts/aws4_request, SignedHeaders=amz-sdk-invocation-id;amz-sdk-request;content-length;content-type;host;x-amz-date;x-amz-security-token, Signature=XXXXsigXXXX
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> X-Amz-Date: 20240822T051538Z
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> X-Amz-Security-Token: sectokenXXXXXXXsectoken=
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Host: <http://sts.us-west-2.amazonaws.com|sts.us-west-2.amazonaws.com>
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> amz-sdk-invocation-id: XXXX-ID-XXXX
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> amz-sdk-request: attempt=1; max=4
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Content-Type: application/x-www-form-urlencoded; charset=UTF-8
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Content-Length: 43
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> Connection: keep-alive
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.headers - http-outgoing-0 >> User-Agent: Apache-HttpClient/5.3.1 (Java/17.0.10.0.101)
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "POST / HTTP/1.1[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Authorization: AWS4-HMAC-SHA256 Credential=ACCESSKEYID/20240822/us-west-2/sts/aws4_request, SignedHeaders=amz-sdk-invocation-id;amz-sdk-request;content-length;content-type;host;x-amz-date;x-amz-security-token, Signature=XXXXsigXXXX[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "X-Amz-Date: 20240822T051538Z[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "X-Amz-Security-Token: sectokenXXXXXXXsectoken=[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Host: <http://sts.us-west-2.amazonaws.com[\r][|sts.us-west-2.amazonaws.com[\r][>\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "amz-sdk-invocation-id: XXXX-ID-XXXX[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "amz-sdk-request: attempt=1; max=4[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Content-Type: application/x-www-form-urlencoded; charset=UTF-8[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Content-Length: 43[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Connection: keep-alive[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "User-Agent: Apache-HttpClient/5.3.1 (Java/17.0.10.0.101)[\r][\n]"
05:17:45.391 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "[\r][\n]"
05:17:45.392 [qtp947647193-25] DEBUG org.apache.hc.client5.http.wire - http-outgoing-0 >> "Action=GetCallerIdentity&Version=2011-06-15"
@Tom I have a potential theory behind the signature mismatch when having wiremock as a forward proxy in between, the signed request doesn't have the path as 
/
but it's empty where as the wiremock changes the path to 
/
which be resulting in signature mismatch at the server side. WDYT ? I added the extension which should eliminate this extra URL but that doesn't work as expected
t
It’s definitely possible that this is the reason. Seems like maybe a more robust solution would be to build an extension that builds the signature based on the request being made from within WireMock, that way any small changes from the original request that can’t be avoided aren’t an issue.
s
@Tom FYI: I was able to partially fix the issue, the reason I say partially is because now it's intermittently failing with wiremock as a forward proxy. The changes I did are to calculate the signature in the stubfilter, but the signature mismatch was not due to 
/
in the URI. The Signature failure was because of clock skew between the client and server. The intermittent failures I get are exactly same as consistent failures before. And now it's intermittent because signature calculation is happening in a comparatively later stage (before proxying request vs while proxying request) and helping the skew a bit. I believe wiremock proxy request might be introducing some clock drift which is causing this issue and 
STS
in general have strict requirement for skew threshold. I didn't get chance to get deeper into at this point. Let me know if this makes sense.
t
Thanks for sharing your analysis of this. I’m still leaning pretty strongly towards an extension that creates the signature at the point the proxy request is made so that it’s constructed with a timestamp closer to send time.
👍 1
s
Yeah, we never face these issue with other cloud services such as s3. STS was an exception in this case and it seems like STS being a token service keeps the clock skew thresholds very low. I pretty much validated my theory by putting a couple seconds sleep in the extension and then we get failures 100% of the time.
t
OK, that’s very interesting to know, thanks again for sharing
42 Views
Open in Slack
PreviousNext
Powered by