|Deep Packet Inspection of Secure Socket Layer (DPI-SSL) extends SonicWALL's Deep Packet Inspection technology to allow for the inspection of encrypted HTTPS traffic and other SSL-based traffic.Deep Packet Inspection of Secure Socket Layer (DPI-SSL) extends SonicWALL's Deep Packet Inspection technology to allow for the inspection of encrypted HTTPS traffic and other SSL-based traffic.|
The SSL traffic is decrypted transparently, scanned for threats and then re-encrypted and sent along to its destination if no threats or vulnerabilities are found. DPI-SSL provides additional security, application control, and data leakage prevention for analyzing encrypted HTTPS and other SSL-based traffic.
The DPI-SSL feature is available in SonicOS Enhanced 5.6. The following table shows which platforms support DPI-SSL and the maximum number of concurrent connections on which the appliance can perform DPI-SSL inspection.
Max Concurrent DPI-SSL inspected connections
The Client DPI-SSL deployment scenario typically is used to inspect HTTPS traffic when clients on the LAN browse content located on the WAN. In the Client DPI-SSL scenario, the SonicWALL UTM appliance typically does not own the certificates and private keys for the content it is inspecting. After the appliance performs DPI-SSL inspection, it re-writes the certificate sent by the remote server and signs this newly generated certificate with the certificate specified in the Client DPI-SSL configuration. By default, this is the SonicWALL certificate authority (CA) certificate, or a different certificate can be specified. Users should be instructed to add the certificate to their browser's trusted list to avoid certificate trust errors.
The Server DPI-SSL deployment scenario is typically used to inspect HTTPS traffic when remote clients connect over the WAN to access content located on the SonicWALL security appliance's LAN. Server DPI-SSL allows the user to configure pairings of an address object and certificate. When the appliance detects SSL connections to the address object, it presents the paired certificate and negotiates SSL with the connecting client.
Afterward, if the pairing defines the server to be 'cleartext' then a standard TCP connection is made to the server on the original (post NAT remapping) port. If the pairing is not defined to be cleartext, then an SSL connection to the server is negotiated. This allows for end-to-end encryption of the connection.
In this deployment scenario the owner of the SonicWALL UTM owns the certificates and private keys of the origin content servers. Administrator would have to import server's original certificate onto the UTM appliance and create appropriate server IP address to server certificate mappings in the Server DPI-SSL UI.