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.
