Filter
Top Products
Firewall > SSL Control
494
SonicOS Enhanced 4.0 Administrator Guide
of TCP based network communications, with its most common and well-known application
being HTTPS (HTTP over SSL). SSL provides digital certificate-based endpoint identification,
and cryptographic and digest-based confidentiality to network communications.
An effect of the security provided by SSL is the obscuration of all payload, including the URL
(Uniform Resource Locator, for example, https://www.mysonicwall.com) being requested by a
client when establishing an HTTPS session. This is due to the fact that HTTP is transported
within the encrypted SSL tunnel when using HTTPS. It is not until the SSL session is
established (step 14, figure 1) that the actual target resource (www.mysonicwall.com) is
requested by the client, but since the SSL session is already established, no inspection of the
session data by the firewall or any other intermediate device is possible. As a result, URL based
content filtering systems cannot consider the request to determine permissibility in any way
other than by IP address.
While IP address based filtering does not work well for unencrypted HTTP because of the
efficiency and popularity of Host-header based virtual hosting (defined in Key Concepts below),
IP filtering can work effectively for HTTPS due to the rarity of Host-header based HTTPS sites.
But this trust relies on the integrity of the HTTPS server operator, and assumes that SSL is not
being used for deceptive purposes.
For the most part, SSL is employed legitimately, being used to secure sensitive
communications, such as online shopping or banking, or any session where there is an
exchange of personal or valuable information. The ever decreasing cost and complexity of SSL,
however, has also spurred the growth of more dubious applications of SSL, designed primarily
for the purposes of obfuscation or concealment rather than security.
An increasingly common camouflage is the use of SSL encrypted web-based proxy servers for
the purpose of hiding browsing details, and bypassing content filters. While it is simple to block
well known HTTPS proxy services of this sort by their IP address, it is virtually impossible to
block the thousands of privately-hosted proxy servers that are readily available through a
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.