[squid-users] Bridge/Tproxy: https dns

Amos Jeffries squid3 at treenet.co.nz
Tue Aug 18 17:38:05 UTC 2015

On 19/08/2015 4:54 a.m., Pedro Correia Sardinha wrote:
> Thank you Amos for the review.
> Following your advice... trying to use the pure transparent proxy (Tproxy)
> but getting different behaviours with google domains in google chrome and
> after adding peek there aren't still no names in https addresses.

Like I said. peek allows you to do ACL stuff with a server name. But it
wont show up in the log because the log is showing  the TCP SYN
equivalent CONNECT request. *TCP* uses just IP:port details.

> First create ssl certs directory, just to check later.
> /usr/lib64/squid/ssl_crtd -c -s /var/log/squid/lib/ssl_db
> remove from squid.conf:
> #tcp_outgoing_address
> #always_direct allow ssl-bump_port
> #ssl_bump none all
> add to squid.conf:
> ssl_bump splice localnet

"splice" is the same as just doing a tunnel. This should just do the
same thing as your earlier "none" configuration for all traffic arriving
from "localnet" machines. Which should be about 100% of your traffic yes?

So it does not even reach the peek...

> ssl_bump peek all
> ssl_bump splice all
> I removed IPv6 restriction in kernel and in new squid compile without
> --disable-ipv6 option. And I added some similiar IPv6 rules to Tproxy boot
> script.
> I continue to not generate-host-certificates(=off), I can check it in

I dont quite undertand that sentence. Missing words?

> ssl_db directory. But, just for testing, if I change
> generate-host-certificates to on then there are certificates changes with
> my self CA Autority notice in Google Chrome related to google sites, some
> other sites tested get the certificate in right way. In IE and Firefox
> there are no certificates issues.
> A workaround for this issue in Google Chrome with websites in google
> domains was create a specific acl for IP from google domains and splice
> first like did with localnet:
> acl google dst "/etc/squid/google.txt"

No. Use an ACL type of "ssl::server_name".

 acl google ssl::server_name "/etc/squid/google.txt"
 acl step1 at_step SslBump1

 ssl_bump peek step1
 ssl_bump splice google
 ssl_bump bump all

That will use the SNI details from the peek to match against the google
domain names the browser is requesting. You can splice based on that
before any decryption or cert generation happens.

Then bump everything else.

> ...
> ssl_bump splice google
> ...

Yes Google Chrome was created by Google (surprise). They embed their
legitimate CA certificate for their web servers directly into the
browser itself in a feature they call "cert pinning".

Whatever your Squid generates cannot match that certificate because you
dont have Googles private credential key.

> After those changes and setup ssl-bump with peek for most of sites (e.g.
> facebook) but still no names in logs, just the IP in https navigation.
> access.log:
> 1439907457.958     49 TCP_MISS/200 910 POST
> http://ocsp.digicert.com/ - ORIGINAL_DST/
> application/ocsp-response
> 1439907466.798  59053 TCP_TUNNEL/200 3944 CONNECT
> 1439907472.813  58798 TCP_TUNNEL/200 8320 CONNECT
> 1439907472.817  59014 TCP_TUNNEL/200 5234 CONNECT
> 1439907490.935  65674 TCP_TUNNEL/200 4207 CONNECT
> 1439907527.998 115712 TCP_TUNNEL/200 5485 CONNECT
> 1439907545.804 122741 TCP_TUNNEL/200 5817 CONNECT

Still TUNNEL'ing. Probably that first "splice" this time. Two ways to
reach the same result.

> cache.log:

> 2015/08/18 15:17:38.152 kid1| TcpAcceptor.cc(222) doAccept: New connection
> on FD 15
> 2015/08/18 15:17:38.152 kid1| TcpAcceptor.cc(297) acceptNext: connection on
> local=[::]:3130 remote=[::] FD 15 flags=25
> 2015/08/18 15:17:38.153 kid1| client_side.cc(3890)
> httpsSslBumpAccessCheckDone: sslBump not needed for local=
> remote= FD 40 flags=17

"not needed" still because of splice implying TUNNEL.


More information about the squid-users mailing list