aws-sdk-go icon indicating copy to clipboard operation
aws-sdk-go copied to clipboard

AWS SDK mutates http.DefaultTransport

Open jastBytes opened this issue 2 years ago • 3 comments

Describe the bug

When AWS_CA_BUNDLE env var is specified and a new session is created with defaults it mutates the http.DefaultTransport. This leads to a globally changed CA for all other parts of the same program using the http.DefaultTransport or http.DefaultClient to connect to another party which most likely will end up with an error like: x509: certificate signed by unknown authority.

Expected Behavior

Specifying AWS_CA_BUNDLE does not mutate the CAs of the http.DefaultTransport.

Current Behavior

Specifying AWS_CA_BUNDLE does mutate the CAs of the http.DefaultTransport.

Reproduction Steps

Specify AWS_CA_BUNDLE, create a new session, connect to another party with the default HTTPClient.

Possible Solution

Create a new HTTPClient/Transport not using the global one.

Additional Information/Context

No response

SDK version used

v1.44.60

Environment details (Version of Go (go version)? OS name and version, etc.)

go: 1.18.4

jastBytes avatar Aug 01 '22 13:08 jastBytes

Hi @jastBytes can you provide a sample of reproducible code that we can use to investigate this?

vudh1 avatar Aug 01 '22 20:08 vudh1

Hi! I will provide an example as soon as I get to it. :)

jastBytes avatar Aug 02 '22 07:08 jastBytes

Hello. We have a reproduction example for you that exhibits the problem in a slightly different way by connecting to the same server rather than a subsequent connection to another party.

The attached go module:

  • Generates a self-signed certificate
  • Starts minio in a docker container, and waits for it to become available
  • Creates three connections:
    1. Session without the caBundle set, and attempt to connect. We expect this to fail due to not trusting the self-signed cert.
    2. session with caBundle set. We expect this session to work, and it does.
    3. another session without the caBundle set. We expect this session to fail, just like the first one did. However, it succeeds.

In the third connection, the http.DefaultClient has the TLSClientConfig from the second session which allows it to connect even when the session is created without the CustomCABundle field set.

reproduction.tar.gz

cc: @smiller70

dsharp-pivotal avatar Sep 07 '22 22:09 dsharp-pivotal