----- Original Message ----- > From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > To: squid-users@xxxxxxxxxxxxxxx > Cc: > Sent: Thursday, 7 March 2013 11:19 AM > Subject: Re: 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 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. >> 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_. The wireshark output I gave is not client->squid. Wireshark was run on ppp1 interface i.e. squid->internet. # command run was # tshark -plnippp1 port 443. > >> 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 Agree. > * IPv6 is on the Squid->Internet connection side of things But as shown above squid->internet is also IPv4 > * IPv4 is happening on the client->Squid connection > * REDIRECT is happening on the client->173.194.36.48 packets Agree. > > 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 > >> 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 I know about ip6tables. :) But I suppose above explains that ip6tables is not needed. Thanks again and regards, Amm.
