How to Implement Deep Packet Inspection (DPI) Without the Headaches!

We get it. Rolling out DPI can be a real pain. You need to distribute certificates to everything going through your firewall, or users will be hit with scary HTTPS errors. But even once you’ve done that, various apps break, users can’t log in to certain services, random websites won’t load properly, and it’s not obvious what to exclude on the firewall to make them work again.

We’ve been through this many times with customers over the years, and we’ve come up with some tips and tricks that will hopefully make this process a little easier for you.

The real reason you need DPI

Do you want devices on your network infected with malware or ransomware? No? Then you need DPI. It’s as simple as that.

Every website is now HTTPS (can you remember the last time you visited a HTTP website?), and without DPI, any malware or virus hosted on a HTTPS website will sail straight through your firewall.

Okay, that’s not 100% true— most firewalls have some sort of ‘threat feed’ with an extensive list of known ‘bad IPs’ or ‘bad domains’. If the HTTPS domain or IP you're visiting is on that list, then it will be blocked.

So, as long as malware authors stick to uploading their malware to known ‘bad IPs’ and known ‘bad domains’, then there’s nothing to worry about, right? ;)

Zero-day attacks happen, and anyone taking security seriously will realise that relying on this approach will eventually end in disaster, sooner or later.

Encryption is not security

But wait—HTTPS is all about ‘securing’ my traffic, so if I implement DPI, isn’t that defeating the purpose? No. HTTPS is about ‘encrypting’ your traffic between your client (browser/machine) and the server (the website). You can still stumble upon a nasty HTTPS website, and the malware will simply be sent to you encrypted, tunnelling it through your expensive security solution.

Just because an HTTPS website doesn't mean it’s safe.

But privacy?!

Implementing DPI will give your firewall the power to investigate packets within your HTTPS connection, in the same way it could with an HTTP connection.

But does that mean your system administrator is now reading your Facebook messages and stealing your credit card information? Nope. Doing this would be a bigger pain in the backside than implementing DPI in the first place. Let me explain.

What do firewalls log?

When interacting with a website, any ‘sensitive’ data, such as sending a Facebook message or clicking ‘buy now’ on Amazon, is usually sent via a POST request in your browser.

No firewall (at least the ones that Fastvue supports) logs the POST body or the returned response. They log certain information about these web requests, such as the URL, the bytes sent, bytes received, content type, and referrer URLs. It would have to be a very badly designed website to include sensitive information in these fields.

However, firewalls will log the full URL, including the query string when DPI is enabled, not just the domain. Many websites do use the query string in the URL to include what you have searched for or filtered by. This is often so you can ‘share’ the URL so the recipient can view the same information.

For example, your firewall will log your Google search as part of the URL when DPI is enabled (https://www.google.com/search?q=your+search+will+be+here). It will also log the video ID of the YouTube video you were watching (https://www.youtube.com/watch?v=12345678).

Applications like Fastvue Reporter will extract these searches and video IDs to help detect students in schools searching for ‘how to kill myself’ (which unfortunately happens every other day!), or watching inappropriate videos.

But it’s important to note that messages sent via chat apps, or form details saved while purchasing products, are not included in URL query strings and therefore not logged by firewalls with DPI enabled.

What about packet captures?

Yes, most firewalls can also perform a ‘packet capture’, which can be analyzed with tools like Wireshark, where sensitive data in POST requests could potentially be extracted.

But there are performance implications of running packet captures on your firewall; the data is extremely noisy and horrible to analyze, and it’s often broken up over many disparate packets.

Collecting and finding sensitive data within packet captures that may violate online privacy is far from intuitive or easy, to the point that it is just not feasible, as everyone has much better things to do with their time.

The long and the short of it? The security advantages of DPI far outweigh any privacy implications. You should probably be more concerned about the actual data you're sending to third-party services than the potential for your organization's firewall to have that data temporarily in memory while it handles your web request, or buried in a packet capture.

What about certificate pinning?

But what about apps like WhatsApp and Signal, which promote end-to-end privacy? Well, the good news is these apps are still private, because they just won’t work if DPI is enabled!

This is because they implement a technique called ‘certificate pinning’ where the app itself knows what ‘certificate’ the server it expects to be communicating with has. If your firewall gets in the way with DPI, the app will see your firewall’s certificate instead and refuse the connection to the server altogether.

However, this is where one of the headaches for implementing DPI comes in, as some of these apps need to work in your organization.

Implement DPI without the headaches

Okay, so hopefully by now you understand why DPI is crucial for your organization’s security, and hopefully I’ve addressed some of the privacy concerns you may have thought about when faced with the general ‘idea’ of DPI.

So, how do you do it?

Start small

First, create a policy on your firewall that only applies to your IP address. Download, install, and trust your firewall’s DPI certificate, then turn on DPI for that policy.

Open your browser, go to an HTTPS website (e.g, google.com), and check the certificate in your browser. It should show your firewall’s certificate, not the default WR2 certificate issued by google.com.

Block QUIC

If you’re seeing flaky results with the certificate showing up in your browser, sometimes, but not always, then try blocking QUIC.

QUIC is a protocol that makes web communications more efficient by using UDP over port 443; however, many firewalls have trouble inspecting it consistently.

Although some firewall providers now state they support inspecting QUIC, we’ve found that in reality, it still causes DPI flakiness. The solution? Block QUIC using your firewall’s application control feature, or simply add a policy to block UDP on port 443.

The traffic will then fall back to HTTPS and be inspected by your firewall more reliably.

Excluding approved applications

As mentioned above, certain applications have issues working through DPI-enabled firewalls due to certificate pinning.

Browser-based applications are ‘usually’ okay, but mobile apps, and background apps running on your desktop OS that require internet access, such as Loom, Dropbox, and Google Drive, may stop working as they can’t verify that they’re talking to their ‘approved’ server due to the certificate mismatch.

To make matters worse, you can’t see the URL or domain that they’re trying to communicate with, like you can in a browser, so it’s difficult to know what to exclude. For example, it’s very tempting to just add *.dropbox.com to the list of DPI exclusions, but the app may actually be trying to communicate with *.getdropbox.com or something more obscure.

Check the SSL logs!

Fortunately, most firewalls now include an SSL log where you can view certificate mismatch errors and other SSL-related issues. These should include the Server Name Indicator (SNI) in the certificate that the app is expecting, which indicates the domain to exclude.

Google it!

If your firewall does not provide a useful SSL log with relevant error information, try searching the web for domains and IPs to allow for your app.

Most app publishers already know about these issues and have published articles on the domains, ports, and IPs to allow for their app to function correctly.

For example, Google publishes a list of hostnames used by ChromeOS and Android devices that you can exclude from DPI here:

Google’s ChromeOS & Android Device List

Here’s the list for Loom:

Loom Domain Requirements

Be specific!

Avoid using wildcard exclusions for entire domains, such as *.google.com for apps like Google Drive. Instead, look at the full SNI in the firewall’s SSL log, or in the vendor’s support articles, and include the subdomain such as accounts.google.com.

This way, if someone accidentally uploads malware to Google Drive (and it gets through Google’s filters), then googleusercontent.google.com will still be inspected.

This also means that traffic to www.google.com, images.google.com, etc, will be inspected, and your firewall will log the full URL, giving you visibility into appropriate Google searches, images, either directly in the logs or through a tool such as Fastvue Reporter.

Expand to more devices

Once all the approved apps on your device are functioning correctly through DPI, try expanding your firewall policy to other devices. Again, download and trust the certificate and check that you’re seeing the firewall’s certificate in your browser.

Repeat the above steps to get any other approved applications and missed apps working. Just be aware that you may need to answer some hard philosophical questions along the way, such as ‘Do we need to allow Snapchat for staff?’.

Once you’ve done this on a few devices that represent most of your typical users, you’re ready to start creating DPI policies for larger network segments.

But you surely don’t want to manually log in to each device one by one and install the DPI certificate, unless you:

Have a lot of time on your hands; or
Are a complete weirdo.

Distributing Certificates

DPI requires that all devices going through your firewall ‘trust’ the firewall’s certificate to re-sign HTTPS traffic. This means you need to distribute the certificate your firewall is using for DPI to all the devices going through your firewall.

If all your devices are ‘fully managed’, you can relatively easily distribute certificates via your domain’s Group Policy (for those using on-prem Active Directory), Intune for those using Entra ID, Google Workspace’s business features, JAMF, or via your MDM solution of choice.

BYOD devices, however, are often where the migraines start to set in for system administrators. How do you get a certificate on a device that you don’t manage?

There are a few ways we’ve seen customers achieve this:

Send out an email with instructions on how to install the certificate. This is a low-fi approach, but it can work in certain situations. Especially if your ‘users’ are adults with a brain, and you have a way to reliably send this email to new users when needed. This method isn’t the best for Wi-Fi guest networks, for example. How do they read the email if they can’t get online in the first place?
Host an internal web page (excluded from DPI) with the downloadable certificate, instructions on how to install it on the user’s OS, and direct new network logins to this page. Again, this is a relatively low-fi approach, but if new users don’t follow the instructions, then they’ll have a bad experience going to any other HTTPS website.
Onboarding solutions like Secure W2. These solutions will integrate with your network, and usually involve a temporary Wi-Fi SSID where new devices are ‘onboarded’. This involves downloading an installer for the user’s operating system that takes care of installing and trusting the DPI certificate, along with other security checks. Once the device is onboarded, these solutions then let the user log in to the ‘real’ Wi-Fi SSID where DPI is in play.

I don’t want to oversimplify this step or sound like I’m an expert here. MDM solutions are an entire industry in themselves, so please reach out to your favorite tech partner to help you through choosing the right solution. It is worth doing, and worth doing properly.

Send it!

Now that you have the certificate on end-user devices, and you're excluding the approved applications as best you can on the devices you’ve tested with so far, you’re ready to create some DPI-enabled policies on larger network segments.

Start with your least favourite people, and then watch the SSL logs, or listen for the screams, and exclude domains as needed, ensuring you’re including those sub-domains and being as specific as you can.

Keep doing this until you eventually have all devices on your network going through a DPI-enabled policy.

Ongoing maintenance

Once you’ve gone through this process of finding a good way to distribute DPI certificates and excluded the main approved applications, most organizations report that it’s relatively smooth sailing from here.

There may be the odd request that comes along to exclude another application or domain, but as long as you remember to keep those exclusions as specific as possible, and you think about the risk of malware living on those domains before excluding them, then you’re in a pretty good place.

Final thoughts

DPI is one of the most critical but under-implemented security features, largely due to the deployment headaches that come with it. However, once you conquer the distribution of certificates and spend a couple of days playing whack-a-mole with specific app domain exclusions, your organization will be in a much better security position by minimizing the attack vector through HTTPS websites and SSL connections.

I know you’re busy, but please don’t put off this work and leave it too late!