cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

In the Rule Set Library Under Common Rules > WebSocket Handling you find a rule that of course handles web sockets.  And, you need these rules (or at least one rule with the event "Enable WebSocket") for sites like slack.com or websocket.org to work correctly. 

My Questions are:

  1. Why would you not turn this on all of the time?
  2. Is there a security risk inherent with websockets that Web Gateway cannot account for?
  3. In the ruleset there are pre-configured rules to only allow for certain sites for request or response cycle, but why?
  4. I have read up a little on websockets, and I would be able to use SSL Inspection, but would it not be able to scan the websocket content?  I thought MWG would be able to.

I guess I could block websockets for categories that I would not be SSL Inspecting, but again what is the risk of not?

Lab Version 7.6.2.13

14 Replies
McAfee Employee aloksard
McAfee Employee
Report Inappropriate Content
Message 2 of 15

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

Hi,

CONNECT qliksense-qap.brazilsouth.cloudapp.azure.com:80 HTTP/1.1

Host: qliksense-qap.brazilsouth.cloudapp.azure.com:80

Proxy-Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

HTTP/1.0 200 Connection established

GET /app/05636c4e-42fd-4921-80e4-a3e2acb04ebe?reloadUri=http%3A%2F%2Fpaineldeprecos.planejamento.gov.br%2FPainelMateriais.html%3Ftipo%3DMATERIAIS HTTP/1.1

Host: qliksense-qap.brazilsouth.cloudapp.azure.com

Connection: Upgrade

Pragma: no-cache

Cache-Control: no-cache

Upgrade: websocket

Origin: http://paineldeprecos.planejamento.gov.br

Sec-WebSocket-Version: 13

User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Accept-Encoding: gzip, deflate

Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Cookie: X-Qlik-Session=715eb0eb-f3b3-4fbc-85ca-00881727c0b5

Sec-WebSocket-Key: fwv77qIBRP8rlaeombktCA==

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: +p3jCtnNnAfObosyBhmyLabOn5A=

Access-Control-Allow-Origin: ws://paineldeprecos.planejamento.gov.br

The protocol switch from HTTP to WebSocket is referred to as a WebSocket handshake. The browser sends a request to the server, indicating that it wants to switch protocols from HTTP to WebSocket. The client expresses its desire through the Upgrade header. Below is working of Web Socket. Above connection trace output is while accessing URL http://paineldeprecos.planejamento.gov.br/PainelMateriais.html?tipo=MATERIAIS

wherein it makes use of Web Socket while displaying numbers and Graphs.

-> Generally Web Sockets are always Client initiated.One the "client initiated" rule matches and the tunnel is setup the response will no longer be inspected. Yes now traffic through the tunnel is allowed back from the destination end.

The rule Enable WebSockets for Special Sites (Server Initiated) will only trigger if the client does not send an upgrade request, but the server does. Which is unlikely to happen.

The rule “Enable WebSockets for Special Sites (Server Initiated)” works in the same way for the response cycle. It is disabled by default. If that should be enabled, the proxy configuration must also be changed:

-> Configuration -> Proxies -> Advanced Settings: disable

“Omit response cycle for responses that must not contain a body”

Once the Web Socket tunnel is established MWG will no longer look into the traffic.

The WebSocket (WS) protocol uses a single TCP connection for the traffic in both directions and uses a handshake to establish an upgrade connection prior to data being transferred. This behavior can cause problems with the SSL Scanner rule set.

There is no security risk inherent with websockets that Web Gateway cannot account for.

Regards

Alok Sarda

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

aloksard, you state that "There is no security risk inherent with websockets that Web Gateway cannot account for."  Inside MWG I do not see a way to send the websocket traffic to NDLP or to scan the content inside the tunnel in any real way.  I would really like to know how what you said can be accomplished.  There are several key sites that I would need to enable websockets for but still need to properly validate the data traffic is allowed/approved.

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

Um, this topic needs deeper discussion.  There is a serious lack of documentation on how MWG deals with WebSocket, which I know because two of us here have been trying to dig up information on this for a month or so.

I don't find the "Enable WebSocket" event anywhere in my rules, yet I fixed a WebSocket problem just yesterday by bypassing SSL inspection (and a couple others before that).

Here's what a WebSocket error looks like:

WebSocket Error.png

Note that there's no blocking associated with this error, so a rule trace won't enlighten you (except where you can see the upgrade header).

So, why does the ruleset from the library enable WebSocket by default?  What is the cost of this event?  Why wouldn't I enable it selectively (and only where necessary)?

So far, we've not had any WebSocket related complaints that couldn't be fixed by bypassing SSL inspection.  So, either no one here is using WebSocket applications without SSL, or no one is complaining about it. 

Since WebSocket is really a different protocol, I would definitely want to know more about how MWG treats it.  Do we really lose content inspection with this (as I do when bypassing SSL inspection for it).  And, there's a good reason I ask this: would I get anything if I removed the SSL inspection bypass and enable WebSocket for those destinations that I've fixed?

McAfee Employee aloksard
McAfee Employee
Report Inappropriate Content
Message 5 of 15

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

Hi ,

Please refer below link regarding Web Socket traffic issue with SSL Scanning:-

https://kb.mcafee.com/agent/index?page=content&id=KB84052&actp=null&viewlocale=en_US&showDraft=false...

With an explicit proxy, a client WebSocket request on port 80 will contain an Upgrade: websocket header. If the SSL Scanner rule set is enabled, a 500 handshakefailed error response is returned.

Solution

MWG 7.5 and earlier does not support the WebSocket protocol; therefore, the WebSocket and WebSocket Secure (WSS) traffic must be tunneled by bypassing the SSL Scanner rule set and the Enable SSL Client Context with CA event.

Example MWG WebSocket tunnel rule:

URL.Host.BelongsToDomains(WebSockets) equals true Stop cycle

Place this rule above the SSL Scanner rule set.

  • MWG 7.6.0 and later supports WebSockets and for that you need to import Web Socket Handling rule from rule set library. Rule set library->Common Rules->Web Socket Handling.

In Web Socket Handling rule set their is rule Enable WebSockets for Special Sites( Client Initiated),Once the "client initiated" rule matches and the tunnel is setup the response will no longer be inspected.

once the Web Socket tunnel is established MWG will no longer look into it.

Regards

Alok Sarda

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

I had already shared that link with my team.

It really doesn't address the questions being asked here.

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

To be clear, any education material on this is useful, but we need to take this farther.

The OWASP discussion and others are worth a careful read.  Just search WebSocket vulnerabilities.

But, we need to understand exactly what we are getting with WebSocket support in the more recent versions of MWG, like can we do DLP for these two-way channels.

timode
Level 9
Report Inappropriate Content
Message 8 of 15

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

At the moment I have exactly the same problem. There is no documentation about websocket and MWG. So far I spend a few hours doing trial and error. But I am still not sure what happens exactly. Especially what MWG is doing with the websocket traffic? What is scanned? What is the advantage of enabling websocket handling instead of tunneling it through. I also noted that even unencrypted websocket is affected by the SSL-Scanning rule because it seems to use CONNECT-Method. Also I had some strange issues enabling websocket handling for all traffic as it is default using the rule set from the library. Also some websites seems to behave strange, if using websocket handling instead of tunneling it through.

There really should be a good KB artible about web socket handling and some documentation within the product guide.

Currently this feature is not useable for me like it is. For me currently MWG does not support websocket in a usefull way.

McAfee Employee mkutrieba
McAfee Employee
Report Inappropriate Content
Message 9 of 15

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

Hi,

At first, thanks for all your feedback.

Here is a little description:

SSL scanner must be enabled to look inside the connection to know the "Upgrade" header present in the GET request (this header is a criteria for the block rule).

The event "Enable WebSocket" must be used to avoid the handshake error described in the KB article:

https://kb.mcafee.com/agent/index?page=content&id=KB84052

After that, whitlist entries must exist to get specific websites to work. Otherwise, they would run into the block rule since the "Upgrade" header is known and criteria is matching.

Let's say, it is more safer since websocket/URL host must be specifically mentioned and all other are running into the block rule.

Please notice, that if SSL scanner is disabled and no whitlist is configured, other websites using websocket are still working because the "Upgrade" header is not known and therefore block rule is not matching.

We are currently working on this topic internally and will update the KB article as soon as we have everything discussed.

I hope this information is helpful.

Regards,

Marcel

Re: Are their Risks to allowing Websockets through McAfee Web Gateway (MWG)?

First, thanks to all who have replied so far and this has started a conversation that will get down to the meat of the question.

I think we all understand what the stock ruleset does for us at a very high level... I think it has been said and resaid differently about 3 times.

  • First rule enables websockets... period
  • second and third rule make it to where it doesn't get blocked in the 4th rule
  • 4th rule blocks it if it is attempting to use the websocket connect in the header...

We get that.  What I need to know and will test tomorrow (8/24/2017) is if this traffic in the websocket tunnel is scannable at all.  I need to know if the proxy, after enabling websockets, can scan the websocket tunnel for content, both  for DLP and for maliciousness (I hope that is a word).  If the proxy (MWG) cannot, then why on earth would we EVER enable it because it creates a private tunnel right into the network that is un-scannable.  Now, If the proxy can scan the content inside of a websocket, then why not turn it on for all websites and ignore rule 2, 3, and 4 in the stock ruleset.

Tomorrow I will test sending data through a websocket with a special character sequence and then see if the MWG can detect it by checking for that specific content and having it email me an alert.  If anyone has any ideas to test this empirically please let me know. 

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator