Limitations to URL Identification
The system cannot filter URLs before:
A monitored connection is established between a client and server.
The system identifies the HTTP or HTTPS application in the session.
The system identifies the requested URL (for encrypted sessions, from either the ClientHello message or the server certificate).
This identification should occur within 3 to 5 packets, or after the server certificate exchange in the TLS/SSL handshake if the traffic is encrypted.
If early traffic matches all other rule conditions but identification is incomplete, the system allows the packet to pass
and the connection to be established (or the TLS/SSL handshake to complete). After the system completes its identification, the system applies the appropriate rule action to
the remaining session traffic.
For access control, these passed packets are inspected by the
access control policy’s
intrusion policy—not the
default action intrusion policy nor the almost-matched
rule’s intrusion policy.
If the system does not know the category and reputation of a URL, browsing to that website does not match rules with category
and reputation-based URL conditions. You cannot assign categories and reputations to URLs manually.
When you build a URL rule, you first choose the category you want to match. If you explicitly choose Uncategorized URLs, you cannot further constrain by reputation, because uncategorized URLs do not have reputations.
for Encrypted Web Traffic
When performing URL filtering on encrypted web traffic, the
Disregards the encryption protocol; a rule matches both HTTPS
and HTTP traffic if the rule has a URL condition but not an application
condition that specifies the protocol.
Does not use
URL lists. You must use URL objects and groups instead.
Matches HTTPS traffic based on the subject common name in the
public key certificate used to encrypt the traffic, and disregards subdomains
within the subject common name.
display an HTTP response page for encrypted connections blocked by access
control rules (or any other configuration); see
Limitations to HTTP Response Pages.
The system can extract HTTP/2 URLs from TLS certificates, but not from a payload.
Parameters in URLs
The system does not use search query parameters in the URL to
match URL conditions. For example, consider a scenario where you block all
shopping traffic. In that case, using a web search to search for amazon.com is
not blocked, but browsing to amazon.com is.
Memory Limitations for Selected Device Models
Due to memory limitations, some device models perform most URL filtering with a smaller, less granular, set of categories
and reputations. For example, even if a parent URL's subsites have different URL categories and reputations, some devices
may only store the parent URL's data. For web traffic handled by these devices, the system may perform cloud lookups to determine
category and reputation for sites not in the local database.
Lower-memory devices include:
ASA 5506-X, ASA 5506H-X, ASA 5506W-X, ASA 5508-X, and ASA 5516-X
ASA 5512-X, ASA 5515-X, and ASA 5525-X
If you are using NGIPSv, see the Cisco Firepower NGIPSv for VMware Quick Start Guide for information on allocating the correct amount of memory to perform category and reputation-based URL filtering.
Manual URL Filtering
When manually filtering specific URLs, carefully consider other traffic that might be affected. To determine whether network
traffic matches a URL condition, the system performs a simple substring match. If the requested URL matches any part of the
string, the URLs are considered to match.