This chapter describes how to plan, design, implement, and maintain the SSL Control feature.
This chapter contains the following sections:
This section provides an overview of SSL Control. It contains the following subsections:
SonicOS Enhanced firmware versions 4.0 and higher include SSL Control, a system for
providing visibility into the handshake of SSL sessions, and a method for constructing policies to control the establishment of SSL connections. SSL (Secure Sockets Layer) is the dominant standard for the encryption 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.
|
|
|
|
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.
|
|
Untrusted Certificate
Authority Control
|
Like the use of self-signed certificates, encountering a certificate
issued by an untrusted CA is not an absolute indication of disreputable obscuration, but it does suggest questionable trust.
SSL Control can compare the issuer of the certificate in SSL
exchanges against the certificates in the SonicWALL’s certificate store. The certificate store contains approximately 100 well-known CA certificates, exactly like today’s Web-browsers. If SSL Control encounters a certificate that was issued by a CA not in its certificate store, it can disallow the SSL connection.
For organizations running their own private certificate authorities,
the private CA certificate can easily be imported into the SonicWALL’s certificate store to recognize the private CA as trusted. The store can hold up to 256 certificates.
|
|
SSL version, Cipher
Strength, and Certificate Validity Control
|
SSL Control provides additional management of SSL sessions
based on characteristics of the negotiation, including the ability to disallow the potentially exploitable SSLv2, the ability to disallow weak encryption (ciphers less than 64 bits), and the ability to disallow SSL negotiations where a certificate’s date ranges are invalid. This enables the administrator to create a rigidly secure environment for network users, eliminating exposure to risk through unseen cryptographic weaknesses, or through disregard for or misunderstanding of security warnings.
|
|
Zone-Based Application
|
SSL Control is applied at the zone level, allowing the administrator
to enforce SSL policy on the network. When SSL Control is enabled on the zone, the SonicWALL looks for Client Hellos sent from clients on that zone through the SonicWALL will trigger inspection. The SonicWALL then looks for the Server Hello and Certificate that is sent in response for evaluation against the configured policy. Enabling SSL Control on the LAN zone, for example, will inspect all SSL traffic initiated by clients on the LAN to any destination zone.
|
|
Configurable Actions
and Event Notifications
|
When SSL Control detects a policy violation, it can log the event
and block the connection, or it can simply log the event while allowing the connection to proceed.
|
|
|
•
|
SSL
- Secure Sockets Layer (SSL) is a network security mechanism introduced by Netscape in 1995. SSL was designed “to provide privacy between two communicating applications (a client and a server) and also to authenticate the server, and optionally the client.” SSL’s most popular application is HTTPS, designated by a URL beginning with https:// rather than simply http://, and it is recognized as the standard method of encrypting Web traffic on the Internet. An SSL HTTP transfer typically uses TCP port 443, whereas a regular HTTP transfer uses TCP port 80. Although HTTPS is what SSL is best known for, SSL is not limited to securing HTTP, but can also be used to secure other TCP protocols such as SMTP, POP3, IMAP, and LDAP. For more information, see http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html
.
SSL session establishment occurs as follows:
|
|
|
•
|
SSLv2
– The earliest version of SSL still in common use. SSLv2 was found to have a number of weaknesses, limitations, and theoretical deficiencies (comparatively noted in the SSLv3 entry), and is looked upon with scorn, disdain, and righteous indignation by security purists.
|
|
|
•
|
SSLv3
– SSLv3 was designed to maintain backward compatibility with SSLv2, while adding the following enhancements:
|
|
|
–
|
TLS
– Transport Layer Security (version 1.0), also known as SSLv3.1, is very similar to SSLv3, but improves upon SSLv3 in the following ways:
|
|
|
•
|
MAC
– A MAC (Message Authentication Code) is calculated by applying an algorithm (such as MD5 or SHA1) to data. The MAC is a message digest, or a one-way hash code that is fairly easy to compute, but which is virtually irreversible. In other words, with the MAC alone, it would be theoretically impossible to determine the message upon which the digest was based. It is equally difficult to find two different messages that would result in the same MAC. If the receiver’s MAC calculation matches the sender’s MAC calculation on a given piece of data, the receiver is assured that the data has not been altered in transit.
|
|
|
•
|
Client Hello
– The first message sent by the client to the server following TCP session establishment. This message starts the SSL session, and consists of the following components:
|
|
|
–
|
Version
– The version of SSL that the client wishes to use in communications. This is usually the most recent version of SSL supported by the client.
|
|
|
–
|
Random
– A 32-bit timestamp coupled with a 28 byte random structure.
|
|
|
–
|
Session
ID
– This can either be empty if no Session ID data exists (essentially requesting a new session) or can reference a previously issued Session ID.
|
|
|
–
|
Cipher
Suites
– A list of the cryptographic algorithms, in preferential order, supported by the clients.
|
|
|
–
|
Compression
Methods
– A list of the compression methods supported by the client (typically null).
|
|
|
•
|
Server
Hello
– The SSL server’s response to the Client Hello. It is this portion of the SSL exchange that SSL Control inspects. The Server Hello contains the version of SSL negotiated in the session, along with cipher, session ID and certificate information. The actual X.509 server certificate itself, although a separate step of the SSL exchange, usually begins (and often ends) in the same packet as the Server Hello.
|
|
|
•
|
Certificates
- X.509 certificates are unalterable digital stamps of approval for electronic security. There are four main characteristics of certificates:
|
|
|
•
|
Subject
– The guarantee of a certificate identified by a common name (CN). When a client browses to an SSL site, such as https://www.mysonicwall.com
, the server sends its certificate which is then evaluated by the client. The client checks that the certificate’s dates are valid, that is was issued by a trusted CA, and that the subject CN matches the requested host name (i.e. they are both “www.mysonicwall.com”). Although a subject CN mismatch elicits a browser alert, it is not always a sure sign of deception. For example, if a client browses to https://mysonicwall.com, which resolves to the same IP address as www.mysonicwall.com, the server will present its certificate bearing the subject CN of www.mysonicwall.com. An alert will be presented to the client, despite the total legitimacy of the connection.
|
|
|
•
|
Certificate Authority (CA
) - A Certificate Authority (CA) is a trusted entity that has the ability to sign certificates intended, primarily, to validate the identity of the certificate’s subject. Well-known certificate authorities include VeriSign, Thawte, Equifax, and Digital Signature Trust. In general, for a CA to be trusted within the SSL framework, its certificate must be stored within a trusted store, such as that employed by most Web-browsers, operating systems and run-time environments. The SonicOS trusted store is accessible from the System > Certificates
page. The CA model is built on associative trust, where the client trusts a CA (by having the CA's certificate in its trusted store), the CA trusts a subject (by having issued the subject a certificate), and therefore the client can trust the subject.
|
|
|
•
|
Untrusted CA
– An untrusted CA is a CA that is not contained in the trusted store of the client. In the case of SSL Control, an untrusted CA is any CA whose certificate is not present in System > Certificates
.
|
|
|
•
|
Self-Signed Certificates
– Any certificate where the issuer’s common-name and the subject’s common-name are the same, indicating that the certificate was self-signed.
|
|
|
•
|
Virtual Hosting
– A method employed by Web servers to host more than one website on a single server. A common implementation of virtual hosting is name-based (Host-header) virtual hosting, which allows for a single IP address to host multiple websites. With Host-header virtual hosting, the server determines the requested site by evaluating the “Host:” header sent by the client. For example, both www.website1.com and www.website2.com might resolve to 64.41.140.173. If the client sends a “GET /” along with “Host: www.website1.com”, the server can return content corresponding to that site.
|
Host-header virtual hosting is generally not employed in HTTPS because the host header
cannot be read until the SSL connection is established, but the SSL connection cannot be established until the server sends its Certificate. Since the server cannot determine which site the client will request (all that is known during the SSL handshake is the IP address) it cannot determine the appropriate certificate to send. While sending any certificate might allow the SSL handshake to commence, a certificate name (subject) mismatch will trigger a browser alert.
|
|
•
|
Weak Ciphers
– Relatively weak symmetric cryptography ciphers. Ciphers are classified as weak when they are less than 64 bits. For the most part, export ciphers are weak ciphers. The following is a list of common weak ciphers:
|
|
1.
|
Self-signed and Untrusted CA enforcement
– If enforcing either of these two options, it is strongly advised that you add the common names of any SSL secured network appliances within your organization to the whitelist to ensure that connectivity to these devices is not interrupted. For example, the default subject name of SonicWALL UTM appliances is “192.168.168.168”, and the default common name of SonicWALL SSL VPN appliances is “192.168.200.1”.
|
|
4.
|
Server Hello fragmentation
– In some rare instances, an SSL server will fragment the Server Hello. If this occurs, the current implementation of SSL Control will not decode the Server Hello. SSL Control policies will not be applied to the SSL session, and the SSL session will be allowed.
|
|
5.
|
Session termination handling
– When SSL Control detects a policy violation and terminates an SSL session, it will simply terminate the session at the TCP layer. Because the SSL session is in an embryonic state at this point, it is not currently possible to redirect the client, or to provide any kind of informational notification of termination to the client.
|
|
6.
|
Whitelist precedence
– The whitelist takes precedence over all other SSL Control elements. Any SSL server certificate which matches an entry in the whitelist will allow the SSL session to proceed, even if other elements of the SSL session are in violation of the configured policy. This is by design.
|
SSL Control is located on
Firewall
panel, under the SSL Control
Folder. SSL Control has a global setting, as well as a per-zone setting. By default, SSL Control is not enabled at the global or zone level. The individual page controls are as follows (refer the Key Concepts for SSL Control section for more information on terms used below).
|
|
•
|
Enable SSL Control
– The global setting for SSL Control. This must be enabled for SSL Control applied to zones to be effective.
|
|
|
•
|
Log the event
– If an SSL policy violation, as defined within the Configuration section below, is detected, the event will be logged, but the SSL connection will be allowed to continue.
|
|
|
•
|
Enable Blacklist
– Controls detection of the entries in the blacklist, as configured in the Configure Lists section below.
|
|
|
•
|
Enable Whitelist
– Controls detection of the entries in the whitelist, as configured in the Configure Lists section below. Whitelisted entries will take precedence over all other SSL control settings.
|
|
|
•
|
Detect Expired Certificates
– Controls detection of certificates whose start date is before the current system time, or whose end date is beyond the current system time. Date validation depends on the SonicWALL’s System Time. Make sure your System Time is set correctly, preferably synchronized with NTP, on the System > Time
page.
|
|
|
•
|
Detect SSLv2
– Controls detection of SSLv2 exchanges. SSLv2 is known to be susceptible to cipher downgrade attacks because it does not perform integrity checking on the handshake. Best practices recommend using SSLv3 or TLS in its place.
|
|
|
•
|
Detect Weak Ciphers (<64 bits)
– Controls the detection of SSL sessions negotiated with symmetric ciphers less than 64 bits, commonly indicating export cipher usage.
|
|
|
•
|
Detect MD5 Digest
– Controls the detection of certificates that were created using an MD5 Hash.
|
|
|
•
|
Configure Blacklist and Whitelist
– Allows the administrator to define strings for matching common names in SSL certificates. Entries are case-insensitive, and will be used in pattern-matching fashion, for example:
|