sni-cn-mismatch block

By default, the FW allows the establishment of the SSL connection.

Usage Scenario

In the SSL no-decrypt scenario, the FW verifies the consistency between SNI and SAN/CN. If SNI and SAN/CN are inconsistent, the FW blocks the establishment of the SSL connection between a client and a server (the FW transparently transmits the traffic instead of functioning as an SSL proxy).

In the client protection scenario, the FW verifies the consistency between SNI and SAN/CN. If SNI and SAN/CN are inconsistent, the FW blocks the establishment of the SSL connection between servers (the FW functions as an SSL proxy).

In order to skip the policy check of the FW, certain user may change the host name of an illegal server to a host name out of the blacklist. In this way, the FW allows the traffic from this host to pass through. The FW verifies the consistency of SNI and SAN/CN during SSL-encrypted traffic detection to avoid such vulnerability. After the host name is changed, SNI carried in the Client Hello packet is changed accordingly, while the CN field in the server certificate remains unchanged. If the host name is changed, SNI in the Client Hello packet is inconsistent with the CN field in the HTTPS Server certificate. The FW considers the traffic as abnormal traffic and blocks the establishment of the SSL connection. However, SNI and CN/SAN inconsistency is not definitely caused by host name modification. In actual applications, SNI and CN/SAN of certain traffic are inconsistent, but the traffic is normal access traffic. Therefore, when SNI and CN/SAN are inconsistent, you can configure the FW to block or allow the establishment of an SSL connection according to actual situations.