SonicWALL 5.8.1 Manuale Utente

simple Web-search. The challenge is not the ever-increasing number of such services, but 
rather their unpredictable nature. Since these services are often hosted on home networks 
using dynamically addressed DSL and cable modem connections, the targets are constantly 
moving. Trying to block an unknown SSL target would require blocking all SSL traffic, which is 
practically infeasible.

SSL Control provides a number of methods to address this challenge by arming the security 
administrator with the ability to dissect and apply policy based controls to SSL session 
establishment. While the current implementation does not decode the SSL application data, it 
does allow for gateway-based identification and disallowance of suspicious SSL traffic.

Common-Name based 
White and Black Lists

The administrator can define lists of explicitly allowed or denied 
certificate subject common names (described in Key Concepts). 
Entries will be matched on substrings, for example, a blacklist 
entry for “prox” will match “www.megaproxy.com”, 
“www.proxify.com” and “proxify.net”. This allows the administrator 
to easily block all SSL exchanges employing certificates issued to 
subjects with potentially objectionable names. Inversely, the 
administrator can easily authorize all certificates within an 
organization by whitelisting a common substring for the 
organization. Each list can contain up to 1,024 entries.

Since the evaluation is performed on the subject common-name 
embedded in the certificate, even if the client attempts to conceal 
access to these sites by using an alternative hostname or even an 
IP address, the subject will always be detected in the certificate, 
and policy will be applied.

Self-Signed Certificate 
Control

It is common practice for legitimate sites secured by SSL to use 
certificates issued by well-known certificate authorities, as this is 
the foundation of trust within SSL. It is almost equally common for 
network appliances secured by SSL (such as SonicWALL security 
appliances) to use self-signed certificates for their default method 
of security. So while self-signed certificates in closed-
environments are not suspicious, the use of self-signed certificates 
by publicly or commercially available sites is. A public site using a 
self-signed certificate is often an indication that SSL is being used 
strictly for encryption rather than for trust and identification. While 
not absolutely incriminating, this sometimes suggests that 
concealment is the goal, as is commonly the case for SSL 
encrypted proxy sites.

The ability to set a policy to block self-signed certificates allows 
security administrators to protect against this potential exposure. 
To prevent discontinuity of communications to known/trusted SSL 
sites using self-signed certificates, the whitelist feature can be 
used for explicit allowance.