Question/FR: Secure web-sockets (WSS) and firewalls/proxies/AV

[pedrojmendoza]

While working with a customer on a migration to AWS IoT for streaming using MQTT over WSS I got a request about whether IoT's client libraries supports falling back to HTTP long polling when there is a WSS connection being blocked by a proxy/firewall/AV

IFAIK, since WSS is basically WS over TLS it should not be the case as the proxy/firewall will only see cipher-text over the wire but they have confirmation from their clients about the issue still being there when using WSS so I want to make sure I am not missing something here (like the protocol switching phase) that could be potentially blocked by the proxy/firewall or whether AV are also a known source of problems while using WSS

Could you pls confirm/correct the above based on your experience with WSS and, if it is perceived as a limitation, whether it is feasible to implement support for a fallback strategy at the SDK level?

Thanks!

[JonathanHenson]

an http proxy would definitely see the web socket upgrade, if they're going TLS all of the way from client to server, then the proxy wouldn't see the traffic, but if it's an actual http proxy, it is decrypted and reencrypted at the proxy so it would see and possibly block the web socket upgrade.

[JonathanHenson]

There is no fallback to long-polling.

[github-actions]

Greetings! Sorry to say but this is a very old issue that is probably not getting as much attention as it deservers. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.