ThreatPulse reports indicate connections with an appropriate category, yet ruled as No Verdict.
You want to know why your report displays a site category for a connection, but rules No Verdict instead of Blocked or Allowed.
For an https:// request, the proxy must process a couple of transactions before reaching the desired verdict;
1. Initial request is a tcp:// request.
2. The Client Worker then hands-off the request to the proxy as ssl://.
- 2a. After this occurs, the proxy proceeds to access information, such as the certificate's common name.
3. Based on the configuration, the request is either intercepted to see the underlying protocol (https://) or the request is processed as an un-intercepted transaction.
4. To evaluate policy at the https:// stage, the proxy must allow ssl:// to pass through successfully so that a better determination can be made.
- 4a. If you see No Verdict on reports for ssl:// requests, it is because the proxy is allowing the transaction to pass-through to the next stage (intercepted https://) to make a better determination.
Another reason why No Verdict might occur in reports:
1. The Verdict field in reports is based on the x-exception-id access log field.
2. When x-exception-id is non-empty, the value of the field is used as the verdict in reports.
3. In cases where x-exception-id is empty and the HTTP status result is not set for the log line, reports reflect No Verdict as the verdict.
4. In this case, No Verdict is usually related to an attempted TCP/SSL session that failed or was aborted.
- 4a. For example, the client or OCS reset the connection during the handshake.
In cases where No Verdict is reflected for SSL requests, verify SSL Interception is enabled in portal and that the root certificate is installed correctly on user devices. If SSL Interception is enabled and the certificate is installed, verify the requested sites are not in the SSL Interception Exemptions List.