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

Hi Amos,

thanks for the quick response - it was of great help! When I avoid reading a cache digest HTTP reply by adding "no-digest" to the cache_peer line, everything works fine.

To quickly repeat our setup: we have squid as a reverse accelerator proxy, talks HTTPS on both ends. The client contacts the proxy via HTTPS, and the proxy shall talk to the application server via HTTPS.
 
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 working squid.conf now 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-fqdn) parent 9443 0 no-query originserver no-digest name=httpsAccel login=PROXY ssl sslflags=DONT_VERIFY_PEER
cache_peer_access httpsAccel allow all
coredump_dir /var/log/squid
http_access allow all
#http_port <proxy.port> accel vhost
https_port (our-proxy-srv-fqdn):9443 accel cert=/etc/squid/server.pem key=/etc/squid/privkey.pem vhost
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-srv-fqdn)
----------------------------------------------

Still I wonder if you are right and there is a bug, too. We don't need the cache digest currently, but as soon as I omit "no-digest" in the config, squid loops forever. I just tested it again...

Anyway, thanks for your help!

Michael

Am 01.12.2011 um 02:11 schrieb Amos Jeffries:

> 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 - 15:25:04 MST