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

On 7/03/2013 7:22 p.m., Amm wrote:
>
> ----- Original Message -----
>> From: Amos Jeffries
>>
>> 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
>
> Please trust me. I am a network engineer since about 15 years now. (Not trying to brag).
>
> I also appreciate your efforts a lot for always replying.
>
> But I do not have IPv6. The squid is running on my standalone laptop.(there is no LAN network)
>
> # ping6 mail.google.com
> connect: Network is unreachable
>
> # mtr -n6 mail.google.com
> gives EMPTY screen i.e shows nothing except headers.
>
> # list IPv6 addresses
> # ip -f inet6 addr list
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
>
>
> Hence, no interface has IPv6 except lo (loopback)
>
>
> # list IPv4 addresses
> # ip -f inet addr list
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> inet 127.0.0.1/8 scope host lo
> 7: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc htb state UNKNOWN qlen 3
> inet 1.2.3.4 peer 1.2.3.4/32 scope global ppp1
>
> PPP interface is ADSL connection and just has IPv4 address. ADSL router is in bridge mode.
>

Okay.

<snip>
>
>> 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.
> I enabled debug.
>
> For testing, URL was accessed with curl (curl -k https://www.google.com/)
>
> Here is debug output: (Google IP has changed but in same subnet, 1.2.3.4 is my public IP replaced)
>
> 2013/03/07 11:40:46.326 kid1| client_side.cc(2325) parseHttpRequest: HTTP Client local=173.194.36.18:443 remote=1.2.3.4:50145 FD 21 flags=33
> 2013/03/07 11:40:46.326 kid1| client_side.cc(2326) parseHttpRequest: HTTP Client REQUEST:
> ---------
> GET / HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.5.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: www.google.com
> Accept: */*
>
>
> ----------
> 2013/03/07 11:40:46.326 kid1| http.cc(2177) sendRequest: HTTP Server local=1.2.3.4:50146 remote=173.194.36.18:443 FD 23 flags=1
> 2013/03/07 11:40:46.326 kid1| http.cc(2178) sendRequest: HTTP Server REQUEST:
> ---------
> GET / HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.5.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: www.google.com
> Accept: */*
> Via: 1.1 a.b.c (squid/3.3.2)
> X-Forwarded-For: 1.2.3.4
> Cache-Control: max-age=259200
> Connection: keep-alive
>
>
> HTTP server REQUEST shows 173.194.36.18, but access.logs show IPv6 address:
> 1362636646.416 90 1.2.3.4 TCP_MISS/302 1138 GET https://www.google.com/ - PINNED/2404:6800:4009:802::1011 text/html

This is a really *really* strange outcome. It is indeed looking like a
code bug somewhere.

The cache.log showed the TCP level details being apparently correct. So
I think we can ignore everyting up to the point of logging.
Just to cofirm that can you add the server response trace from that
server request? It will be a short while later with identical local=
remote= and FD values.
If there is anything else on that FD 23 it would be useful to know as well.

If we assume there is someting terribly broken with where the access.log
data is being generate from.
Can you create a custom log format please which outputs:

  logformat test %>A/%>a:%>p -> %>la:%>lp (%la:%lp) %<la:%<lp ->
%<A/%<a:%<p [%h{Host}]

and use it for a secondary access_log line. Lets see what gets logged by
that.

If it is still logging the IPv6. I have an experimental patch here:
http://master.squid-cache.org/~amosjeffries/patches/pinning_hier_note.patch

If you could apply that and see what the above log changes to it would
be great.

Cheers
Amos
Received on Thu Mar 07 2013 - 07:41:27 MST