Re: [squid-users] https pages

> I am using 2.6.STABLE20 for Windows. I am not using the transparent
> option, nor am I using accelerator mode. Based on what I have read, Squid
> should by default allow a client to access HTTPS pages.
>
> This is not working with my setup, and I'm trying to figure out why. HTTP
> pages work fine when I use the proxy from a client machine, or when I try
> from the proxy server itself. HTTPS pages work fine from the proxy server,
> but from a client machine I am getting "page cannot be displayed."
>
>
> I am including a section from cache.log, as well as pieces from my
> squid.conf that may or may not be relevant (using defaults for options
> I've not included here).
>
> Thanks in advance for any help.
>

Lets run through whats happening here...

> 2008/06/03 15:57:02| aclCheck: checking 'http_access allow
> company_network'
> 2008/06/03 15:57:02| aclMatchAcl: checking 'acl company_network src
> 192.168.0.0/255.255.0.0'
> 2008/06/03 15:57:02| aclMatchIp: 'CLIENT.EXTERNAL.IP' NOT found
> 2008/06/03 15:57:02| aclMatchAclList: no match, returning 0

> 2008/06/03 15:57:02| aclCheck: checking 'http_access allow server10'
> 2008/06/03 15:57:02| aclMatchAcl: checking 'acl server10 src
> SERVER10.EXTERNAL.IP/255.255.255.255 192.168.10.35/255.255.255.255'

> 2008/06/03 15:57:02| aclCheck: checking 'http_access allow allowed_hosts'
> 2008/06/03 15:57:02| aclMatchAcl: checking 'acl allowed_hosts src
> CLIENT.EXTERNAL.IP/255.255.255.255 192.168.2.79/255.255.255.255
> SQUIDSERVER.EXTERNAL.IP/255.255.255.255'
> 2008/06/03 15:57:02| aclMatchIp: 'CLIENT.EXTERNAL.IP' found
> 2008/06/03 15:57:02| aclMatchAclList: returning 1
> 2008/06/03 15:57:02| aclCheck: match found, returning 1
> 2008/06/03 15:57:02| cbdataUnlock: 00C2B688
> 2008/06/03 15:57:02| aclCheckCallback: answer=1
> 2008/06/03 15:57:02| cbdataValid: 01511C80
> 2008/06/03 15:57:02| The request CONNECT www.google.com:443 is ALLOWED,
> because it matched 'allowed_hosts'

The request is being permitted by the allowed_hosts ACL.
A short time later the tunnel gets setup to www.google.com:443

> 2008/06/03 15:57:02| sslStart: 'CONNECT www.google.com:443'
> 2008/06/03 15:57:02| comm_open: FD 18 is a new socket
> 2008/06/03 15:57:02| fd_open FD 18 www.google.com:443
<blah,blah,blah opening bits and DNS lookup>
> 2008/06/03 15:57:02| ipcacheCycleAddr: www.google.com now at 72.14.205.104
> 2008/06/03 15:57:02| connect FD 18: (10035) WSAEWOULDBLOCK, Resource
> temporarily unavailable.
> 2008/06/03 15:57:02| comm_connect_addr: FD 18 connection pending

<blah, blah> temporary problem...

> 2008/06/03 15:57:02| comm_connect_addr: FD 18 connected to
> 72.14.205.103:443

  ... retry and it works!

> 2008/06/03 15:57:02| comm_remove_close_handler: FD 18, handler=00429BA1,
> data=0154A690
>

Send 39 bytes of something to google.

> 2008/06/03 15:57:02| sslWriteClient: FD 17, 39 bytes to write
> 2008/06/03 15:57:02| sslWriteClient: FD 17, 39 bytes written

 ... waiting for the response.

> 2008/06/03 15:57:02| sslReadClient: FD 17, reading 16384 bytes at offset 0
> 2008/06/03 15:57:02| sslReadClient: FD 17, read -1 bytes
> 2008/06/03 15:57:02| cbdataLock: 016153E8
> 2008/06/03 15:57:02| sslReadClient: FD 17: read failure: (10054)
> WSAECONNRESET, Connection reset by peer.

OOPS! www.google.com:443 sent a TCP_RESET to you.

> 2008/06/03 15:57:02| sslAbort: FD 17/18

  ... shutting down the connection.

As you can see its not your config causing problems. It's google denying
you a connection access. Possibly because of the way Squid is setting up
the tunnel. Probably because of what is being sent over it.

Amos
Received on Mon Jun 09 2008 - 02:40:11 MDT