[squid-users] ssl-bump doesn't decrypt https traffic - please help

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/10/2014 9:13 p.m., apfelstrudel wrote:
> Hello. I am trying to get ssl-bump to decrypt https traffic
> transparently so that I could filter out adult videos from youtube
> and to globally enforce google safesearch on my network with
> diladele web safety. I also want to run dansguardian to filter
> http. I managed to pass https traffic transparently to squid but
> ssl-bump doesn't decrypt it. In logs I can see the https websites
> but in an encrypted form of website's.ip.address:port
> (45.231.21.56:443 for example) instead of https url (like
> https://youtube.com). That means that traffic is still encrypted
> and because of that, diladele can't filter https. The squid is
> installed on an eee pc netbook with fedora 20 installed. This
> machine is also my router and a network gateway. 172.16.34.254 is
> the ip on which the netbook "sees" the internal network, which
> consists of: 1 tp-link router directly connected to the eee. Thas
> router is connected wirelessly (Wi-Fi antenna) to the second
> TP-Link router (bridge) in my house. The bridge router is then
> connected by an ethernet cable to another router to which my
> devices finally (phone, tablet, pc, printer) connect. So in
> summary:  My device (PC, tablet, phone) ----> Router (Netgear)
> ----> TP-Link Bridge Router ------> Router (TP-Link) ----> Network
> gateway/router (eee pc running fedora 20) with squid installed.
> With the current configuration dansguardian works (http), diladele
> web safety works (only http) and the https traffic is passed
> transparently through squid, but not decrypted:
> 
> 172.16.34.253 TCP_MISS/301 848 GET http://pl-pl.facebook.com/ -
> HIER_DIRECT/31.13.93.97 text/html 172.16.34.254 TCP_MISS/200 50622
> CONNECT 2.22.52.26:443 - HIER_DIRECT/2.22.52.26 -  <----- this
> should be https://pl-pl.facebook.com but ssl-bump doesn't decrypt
> traffic.
> 

Nope, the log line is correct. It simply states that a tunnel
CONNECT-ion was requested by the client to some server on port 443,
Squid permitted it.

Please read http://tools.ietf.org/html/rfc7230#section-5.3.3 for
details of the URL syntax. The surrounding section 5.3.* contain
details of other URL types you may also spot in your logs.

What it demonstrates is that your test client software is explicitly
configured to use Squid as a proxy on port 3125 with no interception
happening (and thus none of the ssl-bump ports being used).

Or, that the client software is configured to use some other proxy
elsewhere which has its explicit proxy port on 80.



> The IP addresses on the beginning of each line are different
> because http requests go from dansguardian internally. The https
> requests go directly from my internal network.
> 
> Here's my squid.conf: acl localnet src 10.0.0.0/8 # RFC1918
> possible internal network acl localnet src 172.16.0.0/12 # RFC1918
> possible internal network acl localnet src 192.168.0.0/16 # RFC1918
> possible internal network acl localnet src fc00::/7 # RFC 4193
> local private network range acl localnet src fe80::/10 # RFC 4291
> link-local (directly plugged) machines acl to_localhost dst
> 127.0.0.1/8

 NP: to_localhost is pre-defined to be the specific IP addresses which
is dangerous to receive general traffic on. That includes the 127.*
ranges.

> acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports
> port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port
> 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port
> 1025-65535 # unregistered ports acl Safe_ports port 280 #
> http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port
> 591 # filemaker acl Safe_ports port 777 # multiling http acl
> CONNECT method CONNECT # Deny requests to certain unsafe ports 
> http_access deny !Safe_ports # Deny CONNECT to other than secure
> SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr
> access from localhost http_access allow localhost manager 
> http_access deny manager http_access allow localnet http_access
> allow localhost

Since DG is operating on the same machine you would do well to:
 a) ensure DG is configured to pass proxy traffic to Squid via 127.0.0.1
 b) configure DG to send X-Forwarded-For header
 c) add the following to squid.conf:

  follow_x_forwarded_for allow localhost
  follow_x_forwarded_for deny all

that will let Squid log the details of clients connecting to DG.


> # And finally deny all other access to this proxy http_access allow
> all

... pretty funny way to configure "deny all".

BTW: the clients IP is part of "localnet" definition. So legitimate
traffic should not be getting to that "allow all". Only remote
(attackers?) will be benefit from that rule.

ALso, all http_access lines after this one are useless garbage. They
will never match.

> http_access allow CONNECT http_access allow to_localhost include
> "/opt/qlproxy/etc/squid/squid.acl" # Squid normally listens to port
> 3128 # Dansguardian's port: http_port 3125

Just use 3128 for DansGuardian.

The existence of ssl-bump options does not matter for DG output HTTP
traffic going through there.

Whereas, if CONNECT tunnels are being passed to DG (or created by DG
to relay HTTPS traffic) then you need them to be bumped.


> # HTTPS ports, required by diladele web safety: http_port 3126
> intercept

... this 3126 is not an HTTPS port as documented. It is fine as
configured. Just saying your comment above it is misleading.

> https_port 3127 transparent ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/opt/qlproxy/etc/myca.pem 
> http_port 3128 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB cert=/opt/qlproxy/etc/myca.pem 
> always_direct allow all ssl_bump client-first all

client-first bumping does not work much anymore. Use server-first instead.

If you are not using the test squid versions for bumping, you need to
upgrade. ssl-bump functionality is part of an arms race between
browsers and websites trying to increase security & privacy and admin
like you trying to break it. Like any arms race the technology changes
fast.

<snip remainder of the config>

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUP5vxAAoJELJo5wb/XPRjbdgH/Rw/THpi0hMDt9zzyLQCOty/
fm9Ija0r83V8sfTpBzlRj35S4ZpQT2hf4+94OJNIZIueW75nAvMUYfRnvn1r6C6w
j+hXumdo2PxhQ+TQhuqgbSUNpXEm2x93CQETKKf3dlWlDAXxtNBSoKClNpHOHWcZ
FZxPb/fyEBd6s26wt3Q49qbJ1Sg7o0D7aVRh7rPlnC4MS4jmkDamDIgQ7ouW62I6
5eI1sLgYkLpdcM0P/nhNy+JSH3NgayHledrFPYHdBgjn+Co4G72M7XGS4dUfwM4t
mQKg6QtTUPma9mR7iNkXTFIw0lJLrbQz98d9Mt78PwqEmJrcAywhqB9qbU1rQLE=
=UaVG
-----END PGP SIGNATURE-----