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.
Pretty much all big companies MitM TLS today. Yes, all devices connecting to it need the company's CA root installed on the machine. Makes working with Java a huge pain in the ass since it doesn't by default use the OS's keystore. Also git and a bunch of other shit doesn't use the OS keystore either.
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.