Does not the browser connect to Squid using HTTP CONNECT method? Your
Squid configuration did not show any signs of interception IIRC so the
browser should use a CONNECT method to send an HTTP request. Why is your
browser connecting to the server (instead of Squid)? If by "server" you
meant Squid, then why does not the browser send a plain CONNECT request
first? Or does it?
The cliente sends a plain CONNECT request in the first time and after I
press F5 (refresh)
192.168.0.85 = Squid
192.168.0.52 = Client
First time:
9 3.879080 192.168.0.52 192.168.0.85 TCP 66 60695 >
ndl-aas [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
10 3.879104 192.168.0.85 192.168.0.52 TCP 66 ndl-aas >
60695 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
11 3.879962 192.168.0.52 192.168.0.85 TCP 60 60695 >
ndl-aas [ACK] Seq=1 Ack=1 Win=65700 Len=0
12 3.880158 192.168.0.52 192.168.0.85 HTTP 263 CONNECT
www.facebook.com:443 HTTP/1.0
13 3.880173 192.168.0.85 192.168.0.52 TCP 54 ndl-aas >
60695 [ACK] Seq=1 Ack=210 Win=15680 Len=0
14 3.880821 192.168.0.85 192.168.0.52 HTTP 93 HTTP/1.1
200 Connection established
15 3.884118 192.168.0.52 192.168.0.85 TLSv1 183 Client Hello
16 3.884448 192.168.0.85 192.168.0.52 TLSv1 718 Server
Hello, Certificate, Server Hello Done
17 3.885331 192.168.0.52 192.168.0.85 TLSv1 252 Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message
18 3.889974 192.168.0.85 192.168.0.52 TLSv1 113 Change
Cipher Spec, Encrypted Handshake Message
19 3.932579 192.168.0.52 192.168.0.85 TLSv1 416
Application Data, Application Data
20 3.933105 192.168.0.85 192.168.0.52 TLSv1 2974
Application Data
21 3.933133 192.168.0.85 192.168.0.52 TLSv1 776
Application Data
22 3.933193 192.168.0.85 192.168.0.52 TLSv1 91 Encrypted
Alert
23 3.933388 192.168.0.85 192.168.0.52 TCP 54 ndl-aas >
60695 [FIN, ACK] Seq=4442 Ack=899 Win=18896 Len=0
24 3.934193 192.168.0.52 192.168.0.85 TCP 60 60695 >
ndl-aas [ACK] Seq=899 Ack=3683 Win=65700 Len=0
Second time:
33 6.860343 192.168.0.52 192.168.0.85 TCP 66 60696 >
ndl-aas [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
34 6.860360 192.168.0.85 192.168.0.52 TCP 66 ndl-aas >
60696 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16
35 6.860580 192.168.0.52 192.168.0.85 TCP 60 60696 >
ndl-aas [ACK] Seq=1 Ack=1 Win=65700 Len=0
36 6.860768 192.168.0.52 192.168.0.85 HTTP 263 CONNECT
www.facebook.com:443 HTTP/1.0
37 6.860782 192.168.0.85 192.168.0.52 TCP 54 ndl-aas >
60696 [ACK] Seq=1 Ack=210 Win=15680 Len=0
38 6.861126 192.168.0.85 192.168.0.52 HTTP 93 HTTP/1.1
200 Connection established
39 6.862290 192.168.0.52 192.168.0.85 SSL 215 Client Hello
40 6.864909 192.168.0.85 192.168.0.52 TCP 54 ndl-aas >
60696 [RST, ACK] Seq=40 Ack=371 Win=16752 Len=0
41 6.872458 192.168.0.52 192.168.0.85 TCP 66 60697 >
ndl-aas [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
When the browser sends Client Hello, the server sends back RST, ACK.
I see the difference with the before-F5 case above, but since I am
confused about what is actually going on, I will wait for your
clarifications before continuing with this analysis.
Suggested terminology: browser or client, Squid or proxy, origin server.
Please do not skip critical steps such as CONNECT.
Ok, I'll use client, squid and server (http server).
I also noticed that your http_access rules are very strange if not broken:
http_access allow localhost manager
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny block
OK, the above makes sense.
http_access deny all
Now you are denying access to all requests that did not match the
earlier http_access rules. Thus, only the above rules matter and you are
only allowing access to localhost cache manager. Do you really want to
block all non-manager traffic going through Squid?
And the following rules have no effect since "all" in "deny all" above
always matches:
This is a little confusing to me. I just added the lines:
acl block url_regex .facebook.com
http_access deny block
The rest are default settings.
http_access allow localnet
http_access allow localhost
HTH,
Alex.
