• SonicOSX 7
• Advanced
  • Changing Between SonicOS and SonicOSX
    • Changing From Policy to Classic Mode
    • Changing From Classic to Policy Mode
  • Detection Prevention
  • Dynamic Ports
  • Source Routed Packets
  • Access Rule Options
  • IP and UDP Checksum Enforcement
  • Jumbo Frame
  • Connections
  • Control Plane Flood Protection
  • IPv6 Advanced Configuration
• SSL Control
  • Key Features of SSL Control
  • Key Concepts to SSL Control
  • Caveats and Advisories
  • Configuring SSL Control
  • Custom List
  • Enabling SSL Control on Zones
• Cipher Control
  • TLS Ciphers
    • Blocking/Unblocking Ciphers
    • Filtering Ciphers
      • Selecting Display Options
      • Displaying Ciphers by Strength
      • Displaying Ciphers by Block/Unblock
      • Displaying Ciphers by CBC Mode
      • Displaying Ciphers by TLS Protocol Version
  • SSH Ciphers
• Real-Time Black List (RBL) Filter
  • Configuring the RBL Filter
    • Enabling RBL Blocking
    • Adding RBL Services
    • Configuring User-Defined SMTP Server Lists
      • Configuring a White List
      • Configuring a Black List
    • Testing SMTP IP Addresses

Key Concepts to SSL Control

Key concepts to understanding SSL control includel

• 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. SSL session establishment occurs as shown below.

  Establishing an SSL session

  

• 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:

  • Alternate key exchange methods, including Diffie-Hellman.
  • Hardware token support for both key exchange and bulk encryption.
  • SHA, DSS, and Fortezza support.
  • Out-of-Band data transfer.

  • TLS – Transport Layer Security, also known as SSLv3.1, is very similar to SSLv3, but improves upon SSLv3 in the ways shown below.

    Differences between SSL and TLS

    SSL	TLS
    Uses a preliminary HMAC algorithm	Uses HMAC as described in RFC 2104
    Does not apply MAC to version info	Applies MAC to version info
    Does not specify a padding value	Initializes padding to a specific value
    Limited set of alerts and warning	Detailed Alert and Warning messages

  SonicOSX 7 supports TLS 1.1 and 1.2.

• 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:

  • Identify the subject of a certificate by a common name or distinguished name (CN or DN).
  • Contain the public key that can be used to encrypt and decrypt messages between parties.
  • Provide a digital signature from the trusted organization (Certificate Authority) that issued the certificate.
  • Indicate the valid date range of the certificate.
• 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 (that is, 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 presents 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 SonicOSX trusted store is accessible from the Device > Settings > Certificates page. The CA model is built on associative trust, where the client trusts a CA (by having the CAs 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 Device > Settings > 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 table below lists common weak ciphers:

  Common weak ciphers

  Cipher	Encryption	Occurs in
  EXP1024-DHE-DSS-DES-CBC-SHA EXP1024-DHE-CBC-SHA	DES(56) DES(56)	SSLv3, TLS (export) SSLv3, TLS (export)
  EXP1024-RC2-CBC-MD5	RC2(56)	SSLv3, TLS (export)
  EDH-RSA-DES-CBC-SHA	DES(56)	SSLv3, TLS
  EDH-DSS-DES-CBC-SHA	DES(56)	SSLv3, TLS
  DES-CBC-SHA	DES(56)	SSLv2, SSLv3, TLS
  EXP1024-DHE-DSS-RC4-SHA	RC4(56)	SSLv3, TLS (export)
  EXP1024-RC4-SHA	RC4(56)	SSLv3, TLS (export)
  EXP1024-RC4-MD5 EXP-EDH-RSA-DES-CBC-SHA EXP-EDH-DSS-DES-CBC-SHA EXP-DES-CBC-SHA	RC4(56) DES(40) DES(40) DES(40)	SSLv3, TLS (export) SSLv3, TLS (export) SSLv3, TLS (export) SSLv3, TLS (export)
  EXP-RC2-CBC-MD5	RC2(40)	SSLv2, SSLv3, TLS (export)
  EXP-RC4-MD5	RC4(40)	SSLv2, SSLv3, TLS (export)