Policy Evaluation

The Network Phase of the policy is done on the SYN packet. In this phase:

■

The policy engine inputs are source and destination IP addresses, source and destination ports, and VLAN identifiers.

■

The no-decrypt rules are evaluated before the decrypt rules, which are ordered by the following match conditions: source IP, destination IP, source port, destination port and VLAN.

■

If traffic is not to be decrypted, packets are processed as non-proxy traffic. The bypass VLAN is used. Refer to Direct Forward in 1.

Note:  The no-decrypt verdict is always final for the lifetime of the given TCP connection.

■

Traffic that is to be decrypted continues to the next phase. The decrypt verdict from the Network Phase can be overridden by more specific rules in the next phase.

Following conditions are considered for traffic that is to be decrypted:

■

If the Client Hello packet contains SNI, policy is evaluated in the SNI phase and then in the Certificate phase.

■

If the Client Hello packet does not contain SNI, policy is evaluated only in the Certificate phase.

■

For HTTPS proxy connections, policy rules are evaluated based on the hostname from the HTTPS proxy CONNECT request in addition to the SNI.

The SNI Phase of the policy is done on the Server Name Indication (SNI) from the Client Hello. In this phase:

■

The policy engine input is the hostname from SNI.

■

Rules are evaluated in the following order:

o

no-decrypt list/no-decrypt domain

o

decrypt list/decrypt domain

o

no-decrypt category

o

decrypt category

Note:  On the no-decrypt list/decrypt list wildcard entries, you can specify explicit wildcard domain rules like *.domain.com instead of domain.com. For example, *.gigamon.com evaluates all the sub-domains, and gigamon.com only evaluates single domain (i.e. gigamon.com).

■

If traffic is not to be decrypted, packets are processed as TCP proxy. Refer to TCP Proxy in 1.

■

For traffic that is to be decrypted, the plaintext version is sent through the tools based on the decrypt tool-bypass configuration.

If URL category-based rules are configured and a URL cache miss occurs, the policy verdict is based on the settings of the URL cache miss action. A cache miss action of decrypt or no-decrypt will cause the traffic to be decrypted or not decrypted immediately. The defer action will cause delays.

For compliance reasons, the cache miss action of no-decrypt is recommended.

In the case of a decrypt decision from the SNI phase or if the Client Hello does not contain SNI, GigaSMART will verify the server certificate using the configured trust store. Additional checks will be performed for certificate expiry, hostname mismatch, and self-signed certificate. If configured, revocation check will also be done on otherwise valid server certificates.

For valid server certificates, GigaSMART will issue the corresponding server certificate using the primary MitM CA. If the validation fails, the connection will be dropped unless a security exception is configured. The secondary MitM CA, if configured, will be used to issue server certificates in that case.

Starting in software version 5.2, the primary MitM CA is not mandatory for an inbound deployment.

The certificate phase of policy evaluation is done for all connections after the certificate validation is completed. In this phase:

■

The policy engine inputs are the certificate issuer and the certificate subject name.

■

The Common Name (CN) attribute is extracted from the server certificate subject name. Policy evaluation in this phase is performed on the value of the CN attribute. This is similar to the SNI phase. If no matching rules are found, the certificate issuer-based rules are evaluated. For issuer-based rules, the CN attribute and the Domain Name (DN) attribute of the issuer are considered.

■

If traffic is not to be decrypted, packets are processed as TCP proxy. Refer to TCP Proxy in 1. The server SSL session is reset and the Client Hello is resent to the server.

■

GigaSMART supports certificate based policy evaluation for HTTPS proxied connections. It applies policy rules based on the hostname from HTTPS proxy CONNECT request for HTTPS proxy connections. Also, if required it applies no-decrypt in the certificate phase for HTTPS proxy connections.

■

Certificate phase policies are also evaluated for HTTPS proxy connections.