3 Replies Latest reply on Oct 27, 2014 7:13 PM by btlyric

    7.4 Rule Tracing + SSL Scanner + Expected Behavior?


      In version 7.4.x (version I am testing is, what should I expect to see in Rule Tracing for SSL connections  if I have the following sequence of rules?


      Rule set with criteria: Always

           Generic Rule 1                             Continue

           Generic Rule 2                             Continue


      Rule set with criteria: Command.Name equals CONNECT

           Set Client Context                        Continue        Enable SSL Context with CA <DefaultCA>

           Enable Certificate Verification        Stop Cycle    Enable SSL Scanner <Default Certificate Verification>


      What I'm seeing is that each connection generates two rule tracing entries.


      The first entry in the graphical rule tracing has Command.Name = CONNECT and shows it reaching Generic Rule 1, however the raw rule tracing file shows that the connection reaches Enable Certificate Verification with event Enable SSL Scanner and an action of Stop Cycle. The Request Cycle is the only cycle listed in the graphical rule tracing or the raw xml rule tracing file.


      The second entry in the graphical rule tracing has Command.Name = GET and shows it making it all the way through the rule cycles, from Request to Response to Logging.


      What I'm trying to determine is if what I'm seeing is the expected behavior.



        • 1. Re: 7.4 Rule Tracing + SSL Scanner + Expected Behavior?
          Jon Scholten

          The first trace you see is the SSL Tunnel being established (CONNECT or CERTVERIFY). There will be no response data associated with this transaction.


          The second trace you see is what's inside the tunnel (GET). There will be response data to process for this transaction.


          Best Regards,


          • 2. Re: 7.4 Rule Tracing + SSL Scanner + Expected Behavior?

            This is a very good observation and something important to be aware of.


            In the "CONNECT" request the tunnel is not yet opened, which means MWG cannot see any of the data within the tunnel, for example the headers or the requested path.


            Now try to setup this:


            - Allow https://www.facebook.com/McAfee

            - Block all other sites in "Social Media" category


            What you will end up with is access to https://www.facebook.com/McAfee gets blocked by the "Block Social Media Category" rule.




            The first request MWG sees if a CONNECT to www.facebook.com. All MWG knows is the Host as in the CONNECT request there is no path information. So now the rule that allows the /McAfee path does not trigger because MWG does not yet see the path - and you are blocked. For such scenarios I tend to skip "CONNECT" and "CERTVERIFY" commands (e.g. Command.Name equals "CONNECT" or "CERTVERIFY" then Stop Rule Set). Do not use "Stop Cycle" here as it will also skip all rules for the following requests, especially the "GET".




            • 3. Re: 7.4 Rule Tracing + SSL Scanner + Expected Behavior?

              I didn't explain my question very well.


              I wasn't asking about the cycles that occur during a SSL connection; rather, I was asking about what I was seeing in the GUI rule engine tracer vs. what I was seeing in the raw XML files and how that compared to XML files generated by version 7.2.x.


              I think I've narrowed down the situations that cause what I was seeing, but it's still inconsistent in the sense that in certain rule configurations I cannot make the issue show up, but in others the issue shows up regularly, but not consistently. I loaded up the default McAfee SSL Scanner rule set and used that to validate that it wasn't directly related to what I was trying to do with the SSL-related rules.  I then eliminated the SSL Scanner aspect completely and reproduced with a non-SSL connection.


              In one of my rules, I was assigning a user-defined value to a combination of URL.Destination.IP and a couple of other values.


              Generate ID    Always     Continue     Set User-Defined.ID = Number.ToString(DateTime.ToNumber) + String.ReplaceAll (String.Concat(IP.ToString(Client.IP), IP.ToString(URL.Destination.IP)), ".", "")


              If this rule exists above the SSL Scanner's Handle CONNECT Call, the GUI display of the rule tracing output frequently shows that the last rule the connection hit was "Generate ID," but the actual XML rule tracing file (usually) shows that the connection had gone through the rest of the rules, but sometimes not the Logging cycle. If the rule is below the Handle CONNECT call, I see the issue less frequently, but it still occurs.


              I added a rule above Generate ID:


              Get URL.Destination.IP     Always     Continue     Set User-Defined.URL.Destination.IP = URL.Destination.IP


              Did not change the Generate ID rule. No longer seeing the incorrect rule engine GUI display entries that indicate that the last rule traversed was the Generate ID rule. Still see some rule tracing entries/XML files that do not include a logging cycle.


              I also tried putting other rules above the Generate ID rule, but none of them had the same immediately visible effect.




              On the topic of Stop Cycle after enabling Certificate Verification, on 7.2.x I've been successfully using a rule set that has an early Set Client Context and subsequent Enable Certificate Verification/Stop Cycle rule set. Rule tracing files show:




              <trace_info url="https://docs.google.com"/>



                   <!-- cycle -->


                   <!-- cycle -->

              <node name="958983948409473" type="String" value="https://docs.google.com" node_type="variable"/>

              <node name="958983948399099" type="String" value="1414437686106010818817319411596" node_type="variable"/>


                   <!-- cycle -->


              The first Request cycle includes the CONNECT command. The second includes the CERTVERIFY command. In this particular case, a Coaching page is presented during Web Content Filtering so there's no additional tracing file since I didn't click through.


              A better 7.2.x example (since it shows the same connection spanning multiple trace files) might be this:




              <trace_info url="https://duckduckgo.com"/>



              <!-- cycle -->


              <!-- cycle -->


              Above trace shows CONNECT and CERTVERIFY.



              <trace_info url="https://duckduckgo.com/"/>



              <!-- cycle -->


              <!-- cycle -->


              <!-- cycle -->



              Above trace shows the GET command, the response from the server and the logging cycle.


              ETA: If I'm doing something egregiously incorrect, I would like to know. In both of the last two rule tracing examples, SSL content inspection occurs successfully.