The rule isn't working though, and the reason I can see from the Rule Tracing logs is that, upon the CONNECT action when opening an HTTPS site, the User-Agent field is always blank. Regardless of the browser (I tried with all of them and from different operating systems). Also, VERY IMPORTANT TO NOTE, I don't think this is a client-side issue because when checking the traffic from Fiddler, I can see the User-Agent being sent successfully during the CONNECT phase.
Does anyone have a solution for this? My MWG version is 184.108.40.206.0 (24164) so it's pretty up to date. Also it's working in WCCP mode with a Cisco ASA.
This image is copied from the comments section of the above support doc, but it shows my situation exactly:
But in Fiddler:
This is expected behavior in transparent environments. The browser doesnt know its taking to a proxy so there isnt a real CONNECT, instead MWG makes a pseudo CONNECT which makes it easier to pass through the rule engine for filtering. This pseudo CONNECT is just the beginning of an SSL handshake.
To visualize the difference see below, it shows a transparent connection and an explicit connection. You'll notice that the transparent connection is just binary (ssl traffic) -- MWG converts this information into the pseudo CONNECT, where as the explicit has some plain text (the real CONNECT).
As far as a solution to this goes, whats your goal here? Maybe theres another way to tackle the problem. Usually the goal is to change how you authenticate the user, or perhaps you're looking to identify the device type, then change policy based on that.
Edit, I got ahead of myself and neglected to read the first sentence -- sorry... Bypassing SSL scanner based on user-agent wont work in this situation because its chicken and egg situation. The User-Agent lives inside the SSL tunnel, so the only way to get the User-Agent is to break the SSL tunnel with the SSL scanner
It might be worth it to fingerprint the device somehow, by keeping track of the user-agents observed in HTTP, then store it for bypassing purposes. Or if you have a wifi controller or other device that knows what kind of device it is, that device could be queried for further device information and subsequently bypasses could be made based on information from the network controller.
In general, the user agent isnt something that I like to rely on, I will use it if it's there, but not depend on it (as its absent a lot).
Thanks for the reply Jon. Basically my goal is to be able to use one browser e.g. Chrome with SSL Scanning, and use another browser e.g. IE without SSL Scanning, simply for troubleshooting and testing purposes. I know the easiest thing to do would be to bypass based on client IP, in other words to have a "testing" PC with a different IP which bypasses SSL scanning, but I don't have an extra PC to be able to do that, and I'm in a situation where I can't create a VM and bridge the adapters to get two different client IPs on my machine either. So I thought I would bypass SSL scanning based on which browser I'm using.
Anyway, I understood the technical reasons why this isn't possible using the User-Agent. Thanks!