Re: [squid-users] Bypassing SSL Bump for dstdomain

On 7/03/2013 5:30 p.m., Amm wrote:
> ----- Original Message -----
>> From: Amos Jeffries
>>
>> On 7/03/2013 2:03 a.m., Amm wrote:
>>> I just tried 443 port interception with sslbump and is working perfectly.
>>>
>>> If sslbump none applies for request then it passes requests as is:
>>> Log shows something like this:
>>>
>>> 1362574305.069 90590 192.168.1.1 TCP_MISS/200 3600 CONNECT
>> 23.63.101.48:443 - HIER_DIRECT/23.63.101.48 -
>>>
>>> if sslbump server-first applied for request then log shows:
>>> 1362574001.569 294 192.168.1.1 TCP_MISS/200 515 GET
>> https://mail.google.com/mail/images/c.gif? - PINNED/2404:6800:4009:801::1015
>> image/gif
>>> (Note: URL may not be same in both cases, these are just example)
>>>
>>> I dont have IPv6, why is it showing IPv6 address, in 2nd case?
>> Because you *do* have IPv6, or at least the Squid box does. And Squid is
>> using it successfully to contact the upstream web server.
>>
>> Amos
>>
> Nope I do not have IPv6. I have been begging my ISP to give IPv6.

I hear what you are saying. Yet your logs are showing successful IPv6
traffic.
Maybe they enabled it on the router without informing you. Or maybe
someone else on the network setup a IPv6 gateway router (PC running 6to4
and emitting RAs?). I don't know.

Somehow Squid detected that global IPv6 connectivity was available and
is doing full TCP connection setup and HTTP transactions resulting in
over 28KB of data transferred over IPv6 so far.

Try these three tests:
  ping6 mail.google.com
  netstat -antup
  mtr -n6 mail.google.com

> squid is running on the very same machine.
>
> Rule used is:
> iptables -t nat -A OUTPUT -m owner ! --uid-owner squid -p tcp --dport 443 -j REDIRECT --to-ports 8081
>
> URL accessed is https://www.google.com
>
> nslookup -q=a www.google.com = 173.194.36.48 (one of many IPs in result)
> nslookup -q=aaaa www.google.com = 2404:6800:4009:803::1014 (only 1 IPv6 in result)
>
> access.log:
> 1362629583.956 532 192.168.1.1 TCP_MISS/200 28088 GET https://www.google.com/ - PINNED/2404:6800:4009:803::1014 text/html
>
> I used wireshark to monitor the traffic. Result is:
>
> 0.000000 192.168.1.1 -> 173.194.36.48 TLSv1 775 Application Data
> 0.017809 173.194.36.48 -> 192.168.1.1 TCP 68 443 > 40400 [ACK] Seq=1 Ack=708 Win=1002 Len=0 TSval=1111 TSecr=1111

Your log states the client->Squid connection as being IPv4, this trace
confirms _that_.

> Clearly its using IPv4 and not IPv6.
>
> Note: I have replaced my public IP with 192.168.1.1
>
> I have a feeling that since I am using REDIRECT, squid receives redirect packets on local (loopback) IPv6 address, so it assumes that connection is IPv6 and logs IPv6 address instead. (even though it connects to IPv4 address)

Notice that:
  * the client->Squid connection and the Squid->server connection are
independent TCP connections
  * IPv6 is on the Squid->Internet connection side of things
  * IPv4 is happening on the client->Squid connection
  * REDIRECT is happening on the client->173.194.36.48 packets

NAT happening *into* Squid does not require IPv4 outbound. In cases like
these where the HTTP Host: header can be 100% validated as belonging to
the destination IP address Squid will use DNS to locate the upstream
server. In this case it locates the AAAA and uses it.

You can enable debug_options 11,2 to see the client and server HTTP
transaction IP addressing details.

> So I tried to change iptables rule to:
> iptables -t nat -A OUTPUT -m owner ! --uid-owner squid -p tcp --dport 443 -j DNAT --to 127.0.0.1:8081
>
> still it logs IPv6 address in access.log. So do not know why it assumes IPv6.

The "iptables" tool only changes IPv4 firewall settings on your machine.
It does not affect IPv6 traffic in any way.

There is a different tool "ip6tables" which operates very similar, but
only affects the IPv6 firewall settings on your machine.

> So may be somewhere there is a bug. (either logical or coding)

There is definitely a Logical one - clearly your network is not doing
what you think it is doing.
Coding one(s) still unclear - we need to get you sorted out about what
is happening on the IPv6 side of the network before that can be known.

Amos
Received on Thu Mar 07 2013 - 05:49:58 MST