Replacing websocket implementation under mqtt with an other one for wider proxy support (feasibility check) #475
-
|
Hi, Motivation We have been using aws-iot-device-sdk-cpp-v2 for more than a year now and we got increasingly more requests recently to support more proxy types. (The current no auth + basic auth support is unfortunately not enough) I researched this topic and as this recent issue #444 got closed pretty fast it became clear that currently it is not in focus. What we have now We are currently using simple MQTT with MTLS: The idea As we did not want to implement proxy support from the scratch as it seemed way too time consuming, we came up with a bold/crazy idea. We are using Qt in our application as well and it supports a wide range of http proxies. So the idea would be that in a fork/patch of the iot-device-sdk we basically replace the mqtt over websocket implementation to use a qt websocket instead of the one the aws sdk provides. (For this to work first we also need to migrate our current devices from the earlier mentioned method to MQTT over Websocket: So the question would be: Is this idea even fesible? Is the mqtt implementation so intertwined and dependant on the aws websocket implementation and aws event loops that it would be impossible to switch it? Or with some smart interface changes and passing in a callback or socket object it can be implemented? If you have any other idea to solve this problem please feel free to share, as alone the migration to MQTT over Websocket would be a pretty big change for us, so I am ready to hear any kind of alternative solution as well. Thanks for the answer! |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
While the websocket implementation turns into a pass-through handler once the connection is negotiated, I do not think there's any remotely feasible way to swap out what's underneath. The mqtt implementation is strongly coupled to the event loop and io channel architecture from aws-c-io. Support for additional proxy types would certainly be nice, but represents a significant investment of time. If you have an AWS TAM, you could engage them with your use case and in turn that might be a way to get something prioritized and on the development road map. |
Beta Was this translation helpful? Give feedback.
-
|
This is rather unfortunate, but I suspected this would be the case. I check if we can go the TAM way. Thank you for the answer! |
Beta Was this translation helpful? Give feedback.
-
|
As I was checking the proxy support with various proxy types with this SDK I got the following result:
To me supporting digest proxy with password auth seems a low hanging fruit, since its also a http proxy type, and the mqtt is working fine with basic and NTLM proxies which are also http proxies. Supporting socks proxy is another question indeed. |
Beta Was this translation helpful? Give feedback.
-
|
A couple years ago I did a socks5 proof-of-concept up to the point of being able to make requests on TOR through the local daemon with our curl-like test app. In retrospect, I would do it very differently, and it only supported no-auth. With the rfc asserting that GSSAPI support must be implemented to be compliant, I didn't want to open that can of worms and moved on to other things. Digest auth doesn't look that bad, but there's still quite a decent amount of conditional complexity even if it's very straightforward to understand. I imagine we'd skip forwarding support entirely (I regret adding any forwarding support in the first place). We'd want to do a full implementation of rfc 7616 and the final version would probably need an internal security review. I feel like we do eventually need to revisit proxy support because the ntlm/kerberos interface isn't fully async and doesn't have integration testing against a real environment which makes me unwilling to touch the code to extend or refactor. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Reopening this discussion to make it searchable. |
Beta Was this translation helpful? Give feedback.
While the websocket implementation turns into a pass-through handler once the connection is negotiated, I do not think there's any remotely feasible way to swap out what's underneath. The mqtt implementation is strongly coupled to the event loop and io channel architecture from aws-c-io.
Support for additional proxy types would certainly be nice, but represents a significant investment of time. If you have an AWS TAM, you could engage them with your use case and in turn that might be a way to get something prioritized and on the development road map.