Joe wrote:
Chris--
Thanks so much for helping. My knowledge of squid is
limited to what it took to get it up and running, so
experienced help is invaluable. (btw, The two configs
were the same, but I cut those deny lines out just out
of curiousity b/c it looks to me like Squid-b is
denying my requests without even passing them on, so I
tried loosening the acl rules.)
With the new information given below, I think the problem may not be
caused by Squid.
Here's what squid-A is allowing through (as
requested):
ticketmaster test:
1192289991.372 831 24.1.8.252 TCP_MISS/200 40211
GET https://www.ticketmaster.ca/checkout/order? -
DIRECT/209.104.58.144 text/html
Fascinating. It's an actual fully recognizable GET. Usually, (when a
browser hits a secure site) you only get the host name in the logs
(example:
1192312024.368 2958 209.165.134.47 TCP_MISS/200 28087 CONNECT
login.yahoo.com:443 - DIRECT/209.73.168.74 -)
1192289983.189 1549 24.1.8.252 TCP_MISS/200 9970
POST
https://www.ticketmaster.ca/checkout/reserve/fMZQyGUS6wKOSfQ5vMbYq_1NrvDR_mW4ySFWjti-a09EeTMHBt01oJHgkTaYmSKO1DEVuSa6CmlF_Gq4PlCIig
- DIRECT/209.104.58.144 text/html
wellsfargo.com test
1192297304.994 1162 67.163.91.153 TCP_MISS/200 17212
GET https://www.wellsfargo.com/ -
DIRECT/151.151.88.133 text/html
(Squid-A is on CentOS 4.2, Squid-b RH release 9)
Hmm... A difference. RH 9 is getting up there in years (it's only four
years old, but quite a bit changed in that time). I wonder if the
different network stacks (heck, RH9 uses a 2.4 kernel!) would have
something to do with it.
Any thoughts? My knowledge of SSL protocols is also
"enough to get by". Why do you think squid-A
shouldn't be okay with GET/POST over https?
It's not so much that squid would be okay with a GET over HTTPs, more
that the website being accessed wouldn't care for a GET over a secure
channel. Try the following:
telnet www.ticketmaster.ca 80
GET / HTTP/1.0
[hit enter again]
You should see a bunch of HTML source.
Now try:
telnet www.ticketmaster.ca 443
GET / HTTP/1.0
[hit enter again]
The response is a 400 error explaining the problem of using plain HTTP
on an SSL-enabled server port.
Thanks!
-Joe
You might try using ssldump (www.rtfm.com/ssldump/) to watch the
connection from each Squid to the respective websites. Beyond that, I
can't really say. I truly don't understand how/why the connections
through Squid-A work!
Chris
