aws_smithy_experimental: support no TLS and custom TLS providers

[howardjohn]

Describe the feature

aws_smithy_experimental currently requires you to specify a CryptoMode - Ring, AwsLc, or AwsLcFips.

Internally this gets translated into an

#[derive(Clone)]
enum Inner {
    Standard(CryptoMode),
    #[allow(dead_code)]
    Custom(CryptoProvider),
}

The following are needed:

1. The ability to run with no crypto at all, for use cases where calls are made to only HTTP endpoints (IMDS, etc)
2. The ability to directly pass a custom crypto provider

Use Case

1. I have use cases that need a specific crypto provider for compliance
2. I have use cases where I know I will never do TLS and want to ensure that is the case.

Proposed Solution

1. Add CryptoMode::Custom
2. Add CryptoMode::None

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

A note for the community

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

[aajtodd]

Thanks for the request.

The purpose of the HTTP abstractions in smithy runtime is to serve as a suitable default that should work well for most use cases out of the box. It is not meant to handle every possible use case or customization.

I have use cases that need a specific crypto provider for compliance

One of the issues we have with this is how to expose it in a backwards compatible way. We can't really without exposing unstable 3P crates. We also aren't sure we want to given the point above. You're likely better off just wrapping your own HTTP client (which is what we will be recommending going forward for use cases that go beyond the level of customization/configuration that most users require).

I have use cases where I know I will never do TLS and want to ensure that is the case.

The client can still be used with HTTP endpoints (that's how IMDS and ECS credential providers work today). We are not inclined to add less secure defaults.

[howardjohn]

We can't really without exposing unstable 3P crates.

I wouldn't expect that and its not needed. Rustls already has a standardized interface to plugin in arbitrary providers (https://docs.rs/rustls/latest/rustls/crypto/struct.CryptoProvider.html). The interface to use this is already in the code, just in private enums (Inner).

You're likely better off just wrapping your own HTTP client

This would be an option but the interface required to implement this is massive -- the hyper 1.0 implementation in-tree is >1000 LOC. At that point we might as well just implement our own library entirely and drop aws-sdk-rust (which we are considering anyways due to binary size issues).

We are not inclined to add less secure defaults.

I am not looking for a default or something less secure -- only the ability to not depend on ring or aws_lc. its fine if it panics or otherwise restricts access to TLS endpoints.