Decryption Services Enhancements in SonicOS 6.5.2 - Overview

05/11/2020 6 People found this article helpful 475,732 Views

Description

Overview of the following enhancements in SonicOS 6.5.2 for Decryption Services:

DPI-SSL Granular Control
Access Rules-Based DPI-SSL Control
TLS Certificate Status Request Extension
Support for Local CRL
Enhanced DPI-SSL Certificate Verification
Support for ECDSA-Related Ciphers
DPI-SSL and CFS HTTPS Content Filtering now Work Independently
Blocking of SSH X11 Forwarding
Retaining Original Port Numbers in Decrypted Packets

Resolution

DPI-SSL granular control:

It allows you to enable DPI-SSL on a per-zone basis rather than globally. You can enable both DPI-SSL Client and DPI-SSL Server per zone.
You can navigate to Manage | Network | Zones and click on the configure button on the zone and go to the General tab.
Access Rules-Based DPI-SSL Control:

DPI-SSL for both client and server can now be controlled by Access Rules.
You can navigate to Manage | Rules | Access Rules and click on the configure button on the appropriate access rule and go to the Advanced tab.
TLS Certificate Status Request Extension:

DPI-SSL now supports the new TLS Certificate Status Request extension (formally known as OCSP stapling). By supporting this extension, the certificate status information is delivered to the DPI-SSL client through an already established channel, thereby reducing overhead and improving performance.
Support for Local CRL:

A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. A problem with contacting the CA for this list is that the browser cannot confirm whether it has reached the CA’s servers or if an attacker has intercepted the connection to bypass the revocation check. Local CRL is relative to typical CRL (or online CRL). For typical CRL, the client needs to download the CLR from a CRL distribution point. If the client is unable to download the CRL, then by default, the client trusts the certificate. Contrary to typical CRL, Local CRL maintains a list of revoked certificates locally in import memory for DPI-SSL to verify whether the certificate has been revoked.
Enhanced DPI-SSL Certificate Verification:

There are two types of certificate authorities (CAs): root CAs and intermediate CAs. For an SSL certificate to be trusted, that certificate must have been issued by a CA that is included in the trusted store of the device that is connecting. The list of SSL certificates, from the root certificate to the end-user certificate, represents the SSL certificate chain. This feature allows DPI-SSL to verify the certificate chain if the intermediate certificate is not in the trusted root CAs stored by DPI-SSL. Verifying a certificate chain is the process of ensuring that a specific certificate chain is well-formed, valid, correctly signed, and trustworthy.
Support for ECDSA-Related Ciphers:

Previously, DPI-SSL Client supported only RSA-related ciphers, such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. DPI-SSL Client now supports ECDSA (Elliptic Curve Digital Signature Algorithm) ciphers:

TLS_ECDHE_ECDSA_WIATH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
DPI-SSL and CFS HTTPS Content Filtering now Work Independently:

Previously, DPI-SSL and CFS HTTPS content filtering were mutually exclusive and could not be enabled together. Now, both features can be enabled at the same time and function as follows:

If DPI-SSL Client Inspection is disabled, Content Filter Service filters HTTPS connections.
If DPI-SSL Client Inspection is enabled, but the Content Filter option is not selected, Content Filter Service filters HTTPS connections.
If DPI-SSL Client Inspection is enabled and the Content Filter option is selected, CFS does not filter HTTPS connections If DPI-SSL Client Inspection is enabled and the Content Filter option is selected, CFS does not filter HTTPS connections
Blocking of SSH X11 Forwarding:

X is a popular window system for Unix workstations. Using X, a user can run remote X applications that open their windows on the user’s local display (and vice versa, running local applications on remote displays). If the remote server is outside after a firewall and the administrator has blocked remote connections, the user can still use SSH tunneling to get the X display on a local machine. A user can thus circumvent the application-based security policies on the firewall, thereby creating security risks.
As X protocol sessions between applications and X servers are not encrypted while being transmitted over a network, an X11 protocol connection can be routed through an SSH connection to provide security and stronger authentication. This feature is called X11 forwarding.
An SSH client requests X forwarding when it connects to an SSH server (assuming X forwarding is enabled in the client). If the server allows X forwarding for this connection, login proceeds normally, but the server takes some special steps behind the scenes. In addition to handling the terminal session, the server sets itself up as a proxy X server running on the remote machine and sets the DISPLAY environment variable in the remote shell to point to the proxy X display. If an X client program is run, it connects to the proxy. The proxy behaves just like a real X server, and in turn instructs the SSH client to behave like a proxy X client, connecting to the X server on the local machine. The SSH client and server then cooperate to pass X protocol information back and forth over the SSH pipe between the two X sessions, and the X client program appears on your screen just as if it had connected directly to your display.

a) DPI-SSH X11 forwarding supports the following clients:
SSH client for Cygwin
Putty
secureCRT
SSH on Ubuntu
SSH on centos

b) DPI-SSH X11 Forwarding supports the SSH servers on:
Fedora
Ubuntu

c) SSH X11 Forwarding supports both route mode and wire mode. For:
Wire mode, SSH X11 Forwarding is only supported in the secure (active DPI of inline traffic) mode.
Route mode, there is no limitation.

The maximum number of connections supported for SSH X11 Forwarding is same as for DPI-SSH: 1000. DPI-SSH X11 Forwarding requires a valid SonicWall DPI-SSH license.

You can enable it from Manage | Decryption Services > DPI-SSH and enabling X11 forwarding.
Retaining Original Port Numbers in Decrypted Packets:

For encrypted connections DPI-SSL / DPI-SSH connections the decrypted packet shows the destination port as 80 (in the case of HTTPS). When the decrypted packets are observed in packet capture/ Wireshark, they now retain the original port numbers. The port number change applies only to the packet capture and not to the actual packet or connection cache.

You can use the KB How Can I Upgrade SonicOS Firmware? to upgrade the firmware to 6.5.2.x or above.