Bypass ssl-bump on squid3-dev
-
I found out, that as example I cannot bypass *.windowsupdate.com or *.google.com.
Please note the wildcard is just for understanding, in the acl it should look like this .google.com
can anyone please test if he is able to bypass this url https://login.salesforce.com ?
This is one of the urls which can be bypassed without any problems.I think it comes to errors when you try to bypass a hostname which has more ip-adresses.
-
It is working with destionation ip's:
as example: acl broken_ip dst 199.83.131.101Maybe related to transparent proxy. As squid does not know the dns/fqdn before interception.
-
yes and no.
He has to generate a certificate for the required domain when bumping server-side first, it is a wildcard generated for the correct domain and not the ip.
I forgot to mention thatyou have to enable resolv dns4 first.
-
Hello everyone !
I'm looking for weeks about this issue too… and still have no answer. Here is my configuration : pfsense 2.2, squid3 v3.4.10_2 (pkg 0.2.6).
If configure squid like that : proxy my whole LAN, resolv dns v4 first, transparent http proxy on all interface except WAN, bypass proxy for private addresses. About SSL Interception : enabled on all interface except on WAN with a self-signed certificat (which is included in trusted authority on all computer), adapt certificate "Not before" and I do not check the remote certificate (for test).Under 'Custom ACLS, before_auth, I try to avoid ssl_bumping for .microsoft.com (for testing purpose).
The Squid service start normaly but when I access to https://www.microsoft.com, it's still be singned with my own CA, so the exception is not working.Could anyone help me to make this exception working ?
PS: Microsoft KB about ssl exclusion for Windows update, which is my main problem actually : https://support.microsoft.com/kb/885819
-
You could try to make an exception list based on ip's.
-
First of all you should not proxy these at all.
-
He does not want to proxy them, but the problem is the bypass with fqdn's. (acl dstdomain isn't working as it should).
-
You need to tell the client that they should not be proxied… Via proxy.pac plus GPO or whatever. Too late to mess with that once the traffic already hit the transparent proxy!
-
Maybe his standardgateway is also the proxy and he does not have the option to use another gateway ?
-
Thank you for taking time to solve my issue !
You're right, my pfsense is not only the proxy, but the router between vlans and my Gateway to internet, so I cannot tell the client to bypass squid.
I try to exclude the destination IP address using :acl ssl_bypass dst 104.66.167.176 ssl_bump none ssl_bypassAnd… that works !!! accessing https://www.microsoft.com stil signed by verisign :-) I'll check tomorrow to exclude all Windows update IPs. Thanks for your help. I'll come back tomorrow 8)
-
You're right, my pfsense is not only the proxy, but the router between vlans and my Gateway to internet, so I cannot tell the client to bypass squid.
Eeeeh? How many proxies are you running and where?
P.S. This MS stuff is a huge CDN, whitelisting individual IPs is just a total no go.
-
Microsoft Windows Update is using only one ip? Cannot believe that.
-
For the moment it is the best solution. Of course it would be better, but the acl dstdomain isn't working as it should.
-
What solution? Cannot see any solution here - acl ssl_bypass dst with a single IP is nonsense and not a solution.
-
Then brinng up a solution depending in that Problem. ACL dstdomain wont work with SSL bump with hosts with multiple IP adresses.
-
Already brought up a solution. Traffic to these domains should not hit a proxy at all. No other input until this gets answered.
-
Thats not a solution.
-
-
Try it yourself. Maybe you should understand SSL bumping first.
-
Why on earth should I try something known to NOT work by design? Stop directing your Windows Update traffic to the transparent SSL proxy. If you want to serve updates locally, use WSUS server or some of the other enterprise solutions intended for that purpose.
