Search squid archive

Re: 2 way SSL on a non standard SSL Port

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




In the cache.log I have found the following:

CONNECT tv1var.merchantlink-lab.com:8184 HTTP/1.1^M

User-Agent: Java/1.8.0_05^M

Host: tv1var.merchantlink-lab.com:8184^M

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M

Proxy-Connection: keep-alive^M

^M


----------

2015/11/30 17:18:47.517 kid1| 85,2| client_side_request.cc(741) clientAccessCheckDone: The request CONNECT tv1var.merchantlink-lab.com:8184 is ALLOWED; last ACL checked: localnet

2015/11/30 17:18:47.517 kid1| 85,2| client_side_request.cc(717) clientAccessCheck2: No adapted_http_access configuration. default: ALLOW

2015/11/30 17:18:47.517 kid1| 85,2| client_side_request.cc(741) clientAccessCheckDone: The request CONNECT tv1var.merchantlink-lab.com:8184 is ALLOWED; last ACL checked: localnet

2015/11/30 17:18:47.517 kid1| 44,2| peer_select.cc(258) peerSelectDnsPaths: Find IP destination for: tv1var.merchantlink-lab.com:8184' via tv1var.merchantlink-lab.com

2015/11/30 17:18:47.533 kid1| 44,2| peer_select.cc(280) peerSelectDnsPaths: Found sources for 'tv1var.merchantlink-lab.com:8184'

2015/11/30 17:18:47.533 kid1| 44,2| peer_select.cc(281) peerSelectDnsPaths:   always_direct = DENIED

2015/11/30 17:18:47.533 kid1| 44,2| peer_select.cc(282) peerSelectDnsPaths:    never_direct = DENIED

2015/11/30 17:18:47.533 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=104.153.8.184:8184 flags=1

2015/11/30 17:18:47.533 kid1| 44,2| peer_select.cc(295) peerSelectDnsPaths:        timedout = 0

2015/11/30 17:18:47.534 kid1| 4,2| errorpage.cc(1262) BuildContent: No existing error page language negotiated for ERR_CONNECT_FAIL. Using default error file.

2015/11/30 17:18:47.534 kid1| 33,2| client_side.cc(815) swanSong: local=10.1.0.57:3128 remote=192.168.55.103:56395 flags=1

2015/11/30 17:18:47.689 kid1| 5,2| TcpAcceptor.cc(220) doAccept: New connection on FD 11

2015/11/30 17:18:47.689 kid1| 5,2| TcpAcceptor.cc(295) acceptNext: connection on local=[::]:3128 remote=[::] FD 11 flags=9

2015/11/30 17:18:47.695 kid1| 11,2| client_side.cc(2345) parseHttpRequest: HTTP Client local=10.1.0.57:3128 remote=192.168.55.103:56396 FD 10 flags=1

2015/11/30 17:18:47.695 kid1| 11,2| client_side.cc(2346) parseHttpRequest: HTTP Client REQUEST:


versus

a successful call to google:

User-Agent: Java/1.8.0_05^M

Host: www.google.com^M

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M

Proxy-Connection: keep-alive^M

^M


----------

2015/11/30 17:18:47.849 kid1| 85,2| client_side_request.cc(741) clientAccessCheckDone: The request CONNECT www.google.com:443 is ALLOWED; last ACL checked: localnet

2015/11/30 17:18:47.849 kid1| 85,2| client_side_request.cc(717) clientAccessCheck2: No adapted_http_access configuration. default: ALLOW

2015/11/30 17:18:47.849 kid1| 85,2| client_side_request.cc(741) clientAccessCheckDone: The request CONNECT www.google.com:443 is ALLOWED; last ACL checked: localnet

2015/11/30 17:18:47.849 kid1| 44,2| peer_select.cc(258) peerSelectDnsPaths: Find IP destination for: www.google.com:443' via www.google.com

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(280) peerSelectDnsPaths: Found sources for 'www.google.com:443'

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(281) peerSelectDnsPaths:   always_direct = DENIED

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(282) peerSelectDnsPaths:    never_direct = DENIED

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=[::] remote=[2607:f8b0:400d:c06::63]:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=74.125.22.99:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=74.125.22.105:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=74.125.22.106:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=74.125.22.103:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=74.125.22.104:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(286) peerSelectDnsPaths:          DIRECT = local=0.0.0.0 remote=74.125.22.147:443 flags=1

2015/11/30 17:18:47.853 kid1| 44,2| peer_select.cc(295) peerSelectDnsPaths:        timedout = 0

2015/11/30 17:18:48.008 kid1| 33,2| client_side.cc(815) swanSong: local=10.1.0.57:3128 remote=192.168.55.103:56396 flags=1

2015/11/30 17:18:48.196 kid1| 5,2| TcpAcceptor.cc(220) doAccept: New connection on FD 11

2015/11/30 17:18:48.196 kid1| 5,2| TcpAcceptor.cc(295) acceptNext: connection on local=[::]:3128 remote=[::] FD 11 flags=9

2015/11/30 17:18:48.196 kid1| 11,2| client_side.cc(2345) parseHttpRequest: HTTP Client local=10.1.0.57:3128 remote=10.1.0.43:42281 FD 10 flags=1

2015/11/30 17:18:48.196 kid1| 11,2| client_side.cc(2346) parseHttpRequest: HTTP Client REQUEST:





On Mon, Nov 30, 2015 at 4:37 PM, Bart Spedden <bart.spedden@xxxxxxxxxxxxxx> wrote:
Good idea Anthony. 

Here's what I found.

On the squid server when I use the following command to monitor a call to https://www.google.com 

tcpdump -i eth0 -vv 'port 443'


I get the following:

17:32:56.373772 IP (tos 0x0, ttl 64, id 33502, offset 0, flags [DF], proto TCP (6), length 60)

    d6uxpci.lq.com.46591 > qh-in-f104.1e100.net.https: Flags [S], cksum 0x62f0 (correct), seq 3198653455, win 14600, options [mss 1460,sackOK,TS val 530978513 ecr 0,nop,wscale 7], length 0

17:32:56.390214 IP (tos 0x0, ttl 42, id 42485, offset 0, flags [none], proto TCP (6), length 60)

    qh-in-f104.1e100.net.https > d6uxpci.lq.com.46591: Flags [S.], cksum 0x40d0 (correct), seq 558417168, ack 3198653456, win 42540, options [mss 1380,nop,nop,TS val 953915655 ecr 530978513,nop,wscale 7], length 0

17:32:56.390423 IP (tos 0x0, ttl 64, id 33503, offset 0, flags [DF], proto TCP (6), length 52)

    d6uxpci.lq.com.46591 > qh-in-f104.1e100.net.https: Flags [.], cksum 0x11f5 (correct), seq 1, ack 1, win 115, options [nop,nop,TS val 530978529 ecr 953915655], length 0

17:32:56.605977 IP (tos 0x0, ttl 64, id 33504, offset 0, flags [DF], proto TCP (6), length 329)

    d6uxpci.lq.com.46591 > qh-in-f104.1e100.net.https: Flags [P.], cksum 0x6c5a (incorrect -> 0xc57a), seq 1:278, ack 1, win 115, options [nop,nop,TS val 530978745 ecr 953915655], length 277

17:32:56.622191 IP (tos 0x0, ttl 42, id 42578, offset 0, flags [none], proto TCP (6), length 52)

    qh-in-f104.1e100.net.https > d6uxpci.lq.com.46591: Flags [.], cksum 0x0e3e (correct), seq 1, ack 278, win 341, options [nop,nop,TS val 953915887 ecr 530978745], length 0


but when I monitor on the non-stand https port (8184) that I'm trying to connect to I do not see any traffic at all.  So this leads me to believe that squid is not actually trying to make the call on the client's behalf.

So I'm feeling a bit lost. 

I've upgraded to 3.5.11.

The only change I made to the default /etc/squid/squid.conf is to add the two non stand https ports that I need to connect to via:

acl SSL_ports port 443 8184 8185


Is there anyway to get more logging out of squid?  I tried adding debug_option ALL to the squid.conf but didn't see any more logging.

On Mon, Nov 30, 2015 at 10:59 AM, Antony Stone <Antony.Stone@xxxxxxxxxxxxxxxxxxxx> wrote:
On Monday 30 November 2015 at 18:53:54, Bart Spedden wrote:

> I can successfully connect as long as I don't use squid for either 1 way or
> 2 way TLS connections. I've also successfully connect via curl. So, I feel
> like the site's certs are working well. I could be totally off base here
> but my interpretation of the the 503 (service unavailable) is that squid is
> timing out on tls handshake? But what is weird is that when using squid I
> can successfully connect to google using https. So, that is what makes me
> wonder if it has something to do with the non-standard https port?

If it's a timeout, you should be able to see this with a standard wireshark /
tcpdump packet capture (no SSL inspection necessary) on your external-facing
router (or anywhere else which is a common path both when going direct from
the client, and via Squid).

Comparing the two (even though you can't decode the content of the packets)
may well give a clue as to what's going on differently between the two types of
connection.


Antony.

--
Users don't know what they want until they see what they get.

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users



--
Bart Spedden  |  Senior Developer
+1.720.210.7041  |  bart.spedden@xxxxxxxxxxxxxx

3
 | S H A R E
  |  Adobe Digital Marketing Experts  |  
An Adobe®  Business Plus Level Solution Partner
Consulting  |  Training  |  Remote Operations Management





--
Bart Spedden  |  Senior Developer
+1.720.210.7041  |  bart.spedden@xxxxxxxxxxxxxx

3
 | S H A R E
  |  Adobe Digital Marketing Experts  |  
An Adobe®  Business Plus Level Solution Partner
Consulting  |  Training  |  Remote Operations Management


_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux