Filter
Top Products
Firewall Settings > SSL Control
779
SonicOS 5.8.1 Administrator Guide
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.
Key Features of SSL Control
Feature Benefit
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.