I am behind the same gateway and if I go to this web page:
and press Connect button, I can't connect with either ws:// or wss://
Thus, I would tend to answer 'no' to your question, but let's wait for a more authoritative response.
From my understanding, NTLM, being 'just' an authentication protocol, shouldn't affect WebSocket. Authentication happens before the connection to the target host is established.
The authentication part I learnt from another site where they were discussing similar interoperability. Thanks for the Websocket test site, I did test the same in my environment and like I had stated, WS:// doesn't work, but WSS:// works perfectly fine even with NTLM authentication in place. The Browsers web socket messages do provide some insight on what's happening , though I am not sure whether the WS:// failure is due to compatibility issue with the product or with my config.
Hope to hear from someone who is more familiar with this.
I see the problem here. The initial problem lies with how the request looks to the proxy. In my testing using direct proxy when I attempted to connect, the browser generated a connect method to the proxy (this is by design)
[03/Sep/2013:13:07:43 -0400] "chris" XXXXX XXXXXX 173 500 TCP_MISS "CONNECT echo.websocket.org:80 HTTP/1.1" "Internet Services" "Minimal Risk" "-" 1710 0 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0" "-" "-" "103" "" "-"
The documentation for Web Sockets actually explicitly states that they will use a connect to establish the connection.
Many rulesets limit the ports allowed for connect to 443:
However, if we assume that anything with a connect is SSL, we'll either ignore it (no SSL scanning) or break it. At the moment, you cannot do non SSL web sockets through MWG and you cannot perform SSL scanning on web sockets.
As web sockets become more prevalent, we may need to implement directly.
Are there any recent developments on this topic ? Does McAfee/Intel plan to support rfc 6455 websocket communication ?
Today, even with the latest controlled release (22.214.171.124), the only way to allow websockets communication seems to be disabling "ssl inspection". During handshake, the websocket client issues a CONNECT request to the proxy (even when it does not intend to use TLS). If I allow the CONNECT (including for port tcp/80) *and* disable "ssl inspection", the proxy "looks the other way" and lets the traffic pass through. As the proxy doesn't even check for a tls handshake, you can allow any traffic this way (I think).
Of course, this isn't safe at all.
I see that KB84052 confirms what I wrote above. However, the release notes for 7.6.0 say that "WebSockets traffic can be detected and tunneled or blocked depending on its content.".