[squid-users] squid 3.4.8 ssl-bump resolve ip in access.log

[LANGLOIS Nicolas]

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 at lists.squid-cache.org] De la part de Amos Jeffries
Envoyé : mardi 1 décembre 2015 13:18
À : squid-users at lists.squid-cache.org
Objet : Re: [squid-users] 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 at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users