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.
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".
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><trace_info url="https://docs.google.com"/><node string="Request" duration="0.011" enterTime="1414437686.021" node_type="cycle">...</node>
<!-- cycle --><node string="Request" duration="0.041" enterTime="1414437686.189" node_type="cycle">...</node>
<!-- cycle -->
<node name="958983948409473" type="String" value="https://docs.google.com" node_type="variable"/>
<node name="958983948399099" type="String" value="1414437686106010818817319411596" node_type="variable"/><node string="Logging" duration="0.148" enterTime="1414437686.414" node_type="cycle">...</node>
<!-- 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><trace_info url="https://duckduckgo.com"/><node string="Request" duration="0.011" enterTime="1414454668.323" node_type="cycle">...</node>
<!-- cycle --><node string="Request" duration="0.04" enterTime="1414454668.35" node_type="cycle">...</node>
<!-- cycle -->
Above trace shows CONNECT and CERTVERIFY.
<trace><trace_info url="https://duckduckgo.com/"/><node string="Request" duration="0.006" enterTime="1414454668.558" node_type="cycle">...</node>
<!-- cycle --><node string="Response" duration="0.029" enterTime="1414454668.568" node_type="cycle">...</node>
<!-- cycle --><node string="Logging" duration="0.025" enterTime="1414454668.598" node_type="cycle">...</node>
<!-- 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.