Search squid archive

Re: Infinite loop when sending request to HTTPS reverse proxy

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

 



On Thu, 1 Dec 2011 00:02:09 +0100, michael173@xxxxxxx 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



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

  Powered by Linux