Create a Post
Showing results for 
Search instead for 
Did you mean: 

HTTPS Inspection Probe Bypass: To enable or not to enable?

I've heard of mixed results on probe bypass for HTTPS Inspection and I wanted to get feedback.  To me, it seems like this is a better way of deploying HTTPS Inspection to minimize problems with bypassing traffic from inspection, but it is not something that's enabled by default which makes it seem like it should only be used if necessary.

Does anyone know of probe bypass causing more issues than it solves?  Or vice versa?  I know one solution doesn't fit all environments, but I'm wondering if there is a recommendation one way or another.  To me, I think it's something that is better enabled.

Here is the SK:  HTTPS Inspection Enhancements in R77.30 and above 


0 Kudos
32 Replies

Bypassing requests based on hostname/domain etc. is easy and reliable (without a need for probe bypass) on each first connect as soon as the CP sees proxy requests instead of direct requests to the webserver. It does not matter whether the proxy is in a DMZ, the CP itself or an external host. Let me know in case this is an option for you, I find it to be the best solution to a lot of problems with logging as well as control of HTTPS traffic.

Quoting John's very nicely put statement, total perfection is not achievable but this approach will allow you to avoid several issues like:

- accidentally bypassing traffic you'd want to inspect. This can happen when the host to inspect shares its IP with traffic that you bypassed earlier based on hostname/domain based bypass rule: ssl inspection caches IPs which matched a DNS based bypass rule and thus should "typically" not be inspected

- logging traffic for host while the user didn't even call that site with his browser but rather to logging of non-proxied+bypassed sessions is done based on the FIRST CN of a certificate only

- always inspecting a host on first access: On proxied requests the CP learns which hostname the client wants to connect to not from a certificate (which means that it must have decided whether to have replaced it with its own at the time when it passes it on to the client) but from the CONNECT request before any encrypted data is exchanged.

Before reading To do TLS proxying properly, you need to verify the cert on 'trusted' domains. S... | Hacker News  I never understood why the cert as opposed to the SNI was used to match the site against a host/domain name. This was a comment in this thread TLS 1.3 and Proxies | Hacker News  which I found quite interesting as it puts the options for futureproof HTTPS inspection into perspective and makes me believe that using proxied traffic is even more important than before.


Hi John,

Thanks for your post, I'm aiming to read this thread and your document in detail tomorrow.

HTTPS inspection has been causing my organisation issues for far too long. I've experienced all of the issues you've mentioned, Skype being a fairly major one! I'm also looking forward to being able to bypass HTTPS inspection on domain names.

One quick question. You mention disabling probe bypass made things better. I'm assuming you mean "enabling it" made things better? As far as I'm aware the default configuration is for probe bypass to be disabled and enabling it can be achieved by running the following command enhanced_ssl_inspection 1.

I'm planning on enabling it (switching on the bypass) next week, so I'll be sure to read your documents before then. I've tried twice in the past but had to disable it both time for various reasons.

0 Kudos

Has anybody already tried how R80.30 HTTPS inspection works, and how that compares with the Probe Bypass setup?

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events