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

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

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 acme.com while the user didn't even call that site with his browser but rather to someotherco-hostedsite.com: 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.

Highlighted

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

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
Yavor
Iron

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

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

0 Kudos