-
Products
-
Gen 7 Firewalls
SonicWall's Gen 7 platform-ready firewalls offer performance with stability and superior threat protection — all at an industry-leading TCO.
Read More
-
-
Solutions
-
Federal
Protect Federal Agencies and Networks with scalable, purpose-built cybersecurity solutions
Learn MoreFederalProtect Federal Agencies and Networks with scalable, purpose-built cybersecurity solutions
Learn More - Industries
- Use Cases
-
-
Partners
-
Partner Portal
Access to deal registration, MDF, sales and marketing tools, training and more
Learn MorePartner PortalAccess to deal registration, MDF, sales and marketing tools, training and more
Learn More - SonicWall Partners
- Partner Resources
-
-
Support
-
Support Portal
Find answers to your questions by searching across our knowledge base, community, technical documentation and video tutorials
Learn MoreSupport PortalFind answers to your questions by searching across our knowledge base, community, technical documentation and video tutorials
Learn More - Support
- Resources
- Capture Labs
-
- Company
- Contact Us
DPI-SSL and Google
03/26/2020 
156 People found this article helpful
476,183 Views
Description
DPI-SSL is a sanctioned Man-in-the-middle attack. At its core, DPI-SSL Provides downstream machines with a certificate they have chosen to trust, and that certificate in turn is provided by the firewall in response to any attempt to create an HTTPS connection so the SonicWall can terminate the tunnel, scan the traffic for threats, re-encrypt the traffic with its own client tunnel to the remote site, and send the traffic along. This works in both directions.
DPI-SSL intercepts user HTTPS requests. It uses their request to create a secure connection between the SonicWall and the services, while providing its own separate secure connection between itself and the user using the DPI-SSL Certificate. This "sanctioned man-in-the-middle attack" allows the SonicWall to scan the communication in the Deep-Packet-Inspection engine to determine if the traffic is legitimate, or if it poses a threat.
Google (and other companies) uses a method known as "certificate pinning" for software that is installed on a laptop, phone, etc... This means that as you launch the Google app, the software checks to see whether or not you are creating an encrypted tunnel using a certificate with a particular serial number.
If the serial number of the certificate used to create the HTTPS connection back to Google does not match the "pinned" certificate serial number, the connection is rejected. This is why your connection is not being allowed. This is by design, specifically to prevent man-in-the-middle attacks.
How to set up networks with SSL content filters".
To be clear: certificate pinning only occurs on software that is installed on a phone, laptop, etc. The certificate is typically hardcoded, or bundled into the software. Currently Google DOES NOT apply certificate pinning to their websites. For example, going to drive.google.com does not involve certificate pinning and DPI-SSL can be used. However, if Google Drive is installed on a laptop, the certificate has been hardcoded/bundled into the software thereby expecting a specific certificate (and if given another, such as the DPI-SSL certificate, the connection is rejected). This is built-in security that the Google Drive application is providing and can not be circumvented.
Related Articles
- How to access a more specific network over VPN tunnel while having another Route All VPN policy
- How to limit bandwidth usage when playing YouTube videos using App Rules
- SonicWall TZ80 In-Product settings migration
Categories
- Firewalls > TZ Series
- Firewalls > SonicWall SuperMassive E10000 Series
- Firewalls > SonicWall SuperMassive 9000 Series
- Firewalls > SonicWall NSA Series
YES
NO