Re: [squid-users] Infinite loop when sending request to HTTPS reverse proxy

 On Thu, 1 Dec 2011 00:02:09 +0100, michael173_at_gmx.net wrote:
> We would like to set up squid as a reverse accelerator proxy, to talk
> HTTPS on both ends. The client shall contact the proxy via HTTPS, and
> the proxy shall talk to the application server via HTTPS.
>
> We got it all set up, but for some reason, our squid goes into an
> infinite loop as soon the client browser sends it first request after
> accepting the Proxy's SSL-certificate. The client session just hangs.
> The cache.log fills with the repeating sequence pasted below. Maybe
> the solution is obvious, but it seems too obvious for us. So - any
> hint or help would be greatly appreciated. What can we do to further
> dig into the root cause? Should we just compile squid from scratch?
>
> Out OS is RHEL6, Squid is 3.1.10. We installed the regular
> squid.x86_64 packet, and used ldd to make sure it's got the SSL libs
> linked in.
>
> Our squid.conf is this:
> ----------------------------------------------
> cache_replacement_policy heap GDSF
> memory_replacement_policy heap GDSF
> cache_dir aufs /var/cache/squid 4096 256 256
> cache_mem 2048 MB
> cache_store_log none
> cache_peer (our-app-server) parent 9443 0 no-query originserver
> name=httpsAccel login=PROXYPASS ssl sslflags=DONT_VERIFY_PEER

 The value in "(our-app-server)" is important. If it is a domain name
 whose IP points at Squid ... oops. IP address if you can , or a FQDN
 host name which resolves only to the origin IPs for Squid to use.

 "PROXYPASS" does strange things with WWW-Auth headers. In your case
 they are coming in correctly as www-auth headers and you should use
 login=PASS or nothing at all.

> cache_peer_access httpsAccel allow all
> coredump_dir /var/log/squid
> http_access allow all
> #http_port <proxy.port> accel vhost
> https_port 9445 cert=/etc/squid/server.pem key=/etc/squid/privkey.pem
> accel vhost

 To avoid problems upgrading in future you should put "accel" first
 among the options (right after port) nowdays.

 Note that with no IP address this is a wildcard port accepting all 3+
 IP addresses the box has. It needs a wildcard certificate to cope with
 the multiple addresses.

 The use of ports 9445 on http_port and 9443 on cache_peer is important.
 No problems when they are the same, but when different you require one
 of two things:
  1) the backend needs to be capable of accepting port 9445 URLs through
 its port 9443.
 or
  2) squid http_port needs to contain vport=9443 to re-write the port
 number for the backend to get its expected URL.

> refresh_pattern . 0 20% 4320
> cachemgr_passwd disable all
> maximum_object_size 1024 MB
> maximum_object_size_in_memory 16 MB
> buffered_logs on
> visible_hostname (our-proxy-hostname)
> ----------------------------------------------
>
> The cache.log is repeating itself with this sequence. I am asking
> myself, what the heck is it doing here?

 Reading a cache digest HTTP reply from a cache_peer.

 You should be able to avoid it by adding "no-digest" to the cache_peer
 line.

 It does seem to be a bug though.

 Amos

> ----------------------------------------------
> 2011/11/30 15:40:00.000| entering
> storeClientCopyEvent(0x7f6aa5b2ede8*?)
> 2011/11/30 15:40:00.000| AsyncCall.cc(32) make: make call
> storeClientCopyEvent [call663369801]
> 2011/11/30 15:40:00.000| storeClientCopyEvent: Running
> 2011/11/30 15:40:00.000| storeClientCopy2:
> 34A108D8256927160090E868D0CADAED
> 2011/11/30 15:40:00.000| store_client::doCopy: co: 134, hi: 134
> 2011/11/30 15:40:00.000| store_client.cc(349) doCopy: There is no
> more to send!
> 2011/11/30 15:40:00.000| peerDigestHandleReply: peer
> (our-app-server), offset: 134 size: 7.
> 2011/11/30 15:40:00.000| peerDigestSwapInCBlock: peer
> (our-app-server), offset: 134 size: 7.
> 2011/11/30 15:40:00.000| store_client::copy:
> 34A108D8256927160090E868D0CADAED, from 134, for length 4089, cb 1,
> cbdata 0x7f6aa5b2da28
> 2011/11/30 15:40:00.000| storeClientCopy2: Queueing
> storeClientCopyEvent()
> 2011/11/30 15:40:00.000| event.cc(343) schedule: schedule: Adding
> 'storeClientCopyEvent', in 0.00 seconds
> 2011/11/30 15:40:00.000| leaving
> storeClientCopyEvent(0x7f6aa5b2ede8*?)
> 2011/11/30 15:40:00.000| event.cc(251) checkEvents: checkEvents
> 2011/11/30 15:40:00.000| The AsyncCall storeClientCopyEvent
> constructed, this=0x7f6aa5b2ff50 [call663369802]
> 2011/11/30 15:40:00.000| event.cc(260) will call
> storeClientCopyEvent(0x7f6aa5b2ede8*?) [call663369802]
> ----------------------------------------------
>
> Thanks for your help!
> Kind regards,
> Michael
Received on Thu Dec 01 2011 - 01:12:22 MST