1 2 Previous Next 14 Replies Latest reply on Oct 5, 2017 1:59 AM by mkutrieba

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

    themagnificentscreachowl

      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

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

          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

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

            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?

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

              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=e n_US&showDraft=false&platinum_status=false&locale=en_US&bk=n

               

              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

               

               

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

                I had already shared that link with my team.

                 

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

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

                  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.

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

                    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.

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

                      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

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

                        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. 

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

                          Ok, so currently here is the test that I have run....

                          • I enabled Websockets for all users and all sites on my Dev/Test proxy.

                          • I created a rule that would then email me if anything in the body (I could have used body or header) matched a DLP Dictionary

                          • The DLP dictionary includes random strings and a formated number string for testing

                          • I then tested in a normal webpage and of course received notifications, easy to test by performing searches on bing, google, yahoo...
                          • I then opened a wss (secure websocket) on http://websocket.org/echo.html
                          • The rule was never able to identify it. Infact there are no new rules or requests processed on the MWG after the connect of the websocket was made.

                          Currently it is my conclusion that websockets should be turned off in our rulesets until we can properly interrogate the traffic that traverses these TLS tunnels.

                          unless McAfee has some other methods for checking that content.  Or maybe McAfee can confirm if this info can be sent via ICAP over to NDLP?  Or How to enable that feature.

                          1 2 Previous Next