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

[Amos Jeffries]

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