Upstreaming SOCKS5 proxy support across CRT libraries

[carlos-apex]

Describe the feature

Hello,

As part of an internal project, we implemented SOCKS5 proxy support across several AWS CRT libraries:

• aws-crt-cpp
• aws-c-io
• aws-c-http
• aws-c-mqtt
• aws-c-auth

We’re planning to upstream these changes, but before submitting any PRs, we’d like to gather feedback and ensure that our implementation aligns well with the existing CRT architecture and design principles.

The implementation currently includes:

• Support for both unauthenticated and username/password SOCKS5 proxies
• Integration with TLS connections
• Both client-side and proxy-side DNS resolution
• Initial unit and integration tests at the socket and protocol layers (to be adapted and extended for upstream)

Could you please advise us on the preferred next steps for contributing these changes?

For example:

• Would you prefer a design summary or draft PR for initial review?
• How this feature should be properly tested? We are currently including some integration tests we run locally which will have to be adapted.

We appreciate your guidance and are happy to share additional design details or testing results as needed.

Thank you!

Use Case

Our internal use cases require routing MQTT over websocket and HTTP connections through SOCKS5 proxies.

Proposed Solution

Here you can find a preview of the changes we are planing to upstream:

• Add socks5 proxy support #797
• Add socks5 proxy support aws-c-io#771
• Add socks5 proxy support  aws-c-http#536
• Add socks5 proxy support aws-c-mqtt#410
• Add socks5 proxy support aws-c-auth#277

Other Information

No response

Acknowledgements

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

[bretambrose]

Briefly skimmed some of the changes and I like what I see. I've wanted socks support for years and this is clearly solid work. I'll bring it up with the team and see if it can be prioritized; it'll probably require a significant time investment on our part as well (review + testing infrastructure setup).

[carlos-apex]

Hi @bretambrose, thanks for taking a look.

Had you had the chance to share this with the rest of the team to get their input?
Also, could you let me know what the next steps would be on your side once it’s discussed and whether do you have a rough estimate of when the team might be able to start the review and move toward merging it?

Thanks again for the thoughtful note and for considering this for prioritization.

[bretambrose]

Well first step would be to create the PRs.

[carlos-apex]

Done, I created the PRs and updated the PR list in my first comment.

[bretambrose]

So there are a couple of different ways we could do this:

1. A long cycle of (me) review, (you) make changes, repeat, which would involve us iterating on each review until it's in line with current practices (some of which aren't necessarily obvious because in spots you're working in some of the older, clumsier parts of the code base).
2. I pull the PRs into branches and perform these changes myself. I might occasionally ask some questions.

If this were an internal contribution, (1) would be standard as the iteration process leads to good onboarding and team member integration. The advantage of (2) is that it will likely go significantly quicker despite the fact that it requires more from me.

[carlos-apex]

Option 2 makes sense for us.

The use case we need to support is MQTT 5.0 communication over WebSockets, where the connection is authenticated and authorized using AWS IAM credentials.

I assume this use case will be supported in the implementation you will merge, correct?