SSL Inspector Reports
The Reports tab provides a view of all reports and events for all traffic handled by HTTPS Inspector.
Reports
This applications reports can be accessed via the Reports tab at the top or the Reports tab within the settings. All pre-defined reports will be listed along with any custom reports that have been created.
Reports can be searched and further defined using the time selectors and the Conditions window at the bottom of the page. The data used in the report can be obtained on the Current Data window on the right.
Pre-defined report queries: {{#section:All_Reports|'SSL Inspector'}}
The tables queried to render these reports:
Status
The status of the session that generated the event.
- INSPECTED means the session was fully processed by the inspector, and all traffic was passed through all the other applications and services.
- IGNORED means the session was not or could not be inspected, so the traffic was completely ignored and not analyzed by any applications or services.
- BLOCKED means the traffic was blocked because it did not contain a valid HTTPS request, and the Block Invalid Traffic option was enabled.
- UNTRUSTED means the traffic was blocked because the server certificate could not be authenticated.
- ABANDONED means the connection failed because an an underlying SSL connection problem. Usually that the client abandoned the connection because the certificate was not trusted.
Detail
Extra details about the session, with the exact content dependent on the event status.
For INSPECTED and UNTRUSTED sessions, this field will include the SNI hostname extracted from the initial message sent from the client to the server. If the SNI information is not available, the server IP address will be used instead.
For BLOCKED or IGNORED sessions, this field will contain the description of the rule that matched and was applied to the session.
For ABANDONED sessions, detail will usually record information about the error that caused inspection to fail. For SSL exceptions, this will include Client or Server to indicate the session endpoint for which traffic was being processed. It will also include Encrypt or Decrypt to indicate the state of traffic inspection when the exception occurred. If available, the SSL error message will also be included. The following table lists the most common error messages and detailed information about each one.
| unexpected_message | An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations. |
| bad_record_mac | This alert is returned if a record is received with an incorrect MAC. This alert also MUST be returned if an alert is sent because a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values, when checked, weren't correct. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). |
| decryption_failed | This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode [CBCATT]. It MUST NOT be sent by compliant implementations. |
| record_overflow | A TLSCiphertext record was received that had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). |
| decompression_failure | The decompression function received improper input (e.g., data that would expand to excessive length). This message is always fatal and should never be observed in communication between proper implementations. |
| handshake_failure | Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error. |
| no_certificate | This alert was used in SSLv3 but not any version of TLS. It MUST NOT be sent by compliant implementations. |
| bad_certificate | A certificate was corrupt, contained signatures that did not verify correctly, etc. |
| unsupported_certificate | A certificate was of an unsupported type. |
| certificate_revoked | A certificate was revoked by its signer. |
| certificate_expired | A certificate has expired or is not currently valid. |
| certificate_unknown | Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable. |
| illegal_parameter | A field in the handshake was out of range or inconsistent with other fields. This message is always fatal. |
| unknown_ca | A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn't be matched with a known, trusted CA. This message is always fatal. |
| access_denied | A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This message is always fatal. |
| decode_error | A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). |
| decrypt_error | A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal. |
| export_restriction | This alert was used in some earlier versions of TLS. It MUST NOT be sent by compliant implementations. |
| protocol_version | The protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons.) This message is always fatal. |
| insufficient_security | Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client. This message is always fatal. |
| internal_error | An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue. This message is always fatal. |
| user_canceled | This handshake is being canceled for some reason unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning. |
| no_renegotiation | Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert. At that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate is where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, etc.) at startup, and it might be difficult to communicate changes to these parameters after that point. This message is always a warning. |
| unsupported_extension | sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello. This message is always fatal. |
Related Topics
