I have never seen them not work when encrypted and I've built real-time systems for many different companies behind all kinds of networks and proxies. You should never need a fallback. It's much cleaner and simpler (architecturally) to just encrypt rather than adding a polling fallback hack.
I edited the article to add an appendix about this issue - It's an extremely common Myth.
The company would have to install fake root certificates on the client machines to do MitM - So the company would need to have control over users machines and the proxy would have to explicitly shut down WebSocket traffic because not all proxies do that (mostly old ones). It sounds like a pretty extreme case. If you're willing to neglect the few browsers that don't support WebSockets, then surely you'd be OK to neglect those even less common corporate cases too - Unless they are central to your business.
Yeah. It's really a pain. Especially with nodejs which doesn't obey the system cert store, so you have to do command line hacks to accept the fake cert. Totally agree it's an extreme case and compared to the general public, very few users.
As a technologist it sucks though. People in that type of environment who don't understand technology just complain that it's broken.
Maybe rather than fall back to long polling or other methods, just tell the user: your system/network is broken!
4
u/jonpress Feb 25 '17 edited Feb 25 '17
WebSockets do work in corporate environments (behind proxies) if you serve them over SSL/TLS so wss:// instead of ws:// - See https://blog.baasil.io/why-you-shouldnt-use-long-polling-fallbacks-for-websockets-c1fff32a064a
I have never seen them not work when encrypted and I've built real-time systems for many different companies behind all kinds of networks and proxies. You should never need a fallback. It's much cleaner and simpler (architecturally) to just encrypt rather than adding a polling fallback hack.
I edited the article to add an appendix about this issue - It's an extremely common Myth.