Thanks Amos for the quick reply, I 'm making lot of mistake around ssl with squid, i 'm following your advice and try to setup with with last squid 3.5 version using tproxy will let you know . Have a good day Nicolas -----Message d'origine----- De : squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] De la part de Amos Jeffries Envoyé : mardi 1 décembre 2015 13:18 À : squid-users@xxxxxxxxxxxxxxxxxxxxx Objet : Re: squid 3.4.8 ssl-bump resolve ip in access.log On 2/12/2015 12:40 a.m., LANGLOIS Nicolas wrote: > Hi, i'm trying to set up squid 3.4.8 on debian , i want a full transparent proxy, no conf on client side . That is not what "fully transparent" means. The best form of transparent proxy is when clients are auto-configured with explicit-proxy settings. Also be aware that the Debian versions which are shipping Squid-3.4.8 have some mystery issue in their kernels that nobody has yet been able to track down that prevents the TPROXY feature from operating properly. You will have to stick with NAT or upgrade to one of the Debian versions shipping Squid-3.5, their kernels seem to work better. > it's working actually but i 'm ask to report websites access but for https actually i just get this kind of line in my access.log : > < TCP_MISS/200 288 CONNECT 64.233.184.106:443 - > ORIGINAL_DST/64.233.184.106 < > > Is there a way to have dns resolution and log the website visited for https ? What for? all it does is reduce accuracy of the log. You can end up with situations where the log says: "CONNECT 64.233.184.106:443 - ORIGINAL_DST/example.com" But when log analysis runs example.com has moved its IP, or just DNS has cycled on to another one of the set. So analysis then reports the client requested URL "64.233.184.106:443" when connecting to a server whose IP is now 192.0.2.1. Which is plain wrong. > > Here is a part of my squid.conf : > > http_port 192.168.1.1:3128 ssl-bump generate-host-certificates=on > dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/squid.pem > http_port 192.168.1.1:3129 intercept > https_port 192.168.1.1:3130 intercept ssl-bump > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > cert=/etc/squid3/ssl_cert/squid.pem > > ssl_bump none all > sslproxy_cert_error allow all > sslproxy_flags DONT_VERIFY_PEER > always_direct allow all So basically; Intercept TLS (supposed to be secure). Ignore all possible errors, malicious attacks, diversions or hijacking that might be done by anyone else on the way to the real server. BUT tell the client everything is safe to send or fetch that sensitive data they needed TLS for? You are SO lucky you started that "ssl_bump none all" actually means dont perform SSL-bump interception. It is preventing a world of FAIL from landing on your head. The other three lines should be erased immediately. > > or is there a magical solution for transparent proxy with no client-side (certs or proxy conf) config working actually with https ? Firstly, Be aware that SSL-Bump is involved in an arms race. If you are doing bumping always use the latest Squid. The 3.4 series is outdated by a year. Things have already moved on well past its capabilities. Secondly, after upgrade to Squid-3.5 use "splice all" where you have placed "none all" right now and what you request will 'just work'. You can then peek/stare at unencrypted the SNI and cert details to log where clients are going and/or block certain servers being contacted. The assumption with SSL-Bump is that you are doing so in order to actually bump at least some of the traffic. There is very little point in diverting port 443 to Squid only to do nothing at all with it. All that does is slow the already heavyweight HTTPS protocol down. It is the bumping action that requires the client setup. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
