Em 20/03/2013 12:00, Alex Rousskov escreveu:
> On 03/20/2013 04:54 AM, Delton wrote:
>
>> When accessing any site over HTTP everything works.
>> For HTTPS, when the site is not blocked it is displayed with
>> problems. Some objects need to be recharged for display.
> It is unlikely that we will be able to troubleshoot that without more
> specifics. Can you easily reproduce these problems or are they totally
> random?
I can easily reproduce these problems.
>
>
>> For HTTPS, when the site is blocked as often is the message from
>> Squid and sometimes displays the fault message in the browser
>> connection.
> Again, need more details about the failure. What does Squid receive and
> what does Squid respond with when the browser displays the "fault
> message". What "fault message" does the browser display.
>
> You may want to focus on one of the above two cases and resolve that
> before moving to the next problem.
>
>
>> The first time when accessing(direct, no F5):
>>
>> 1363776566.837 0 192.168.0.52 TCP_DENIED/200 0 CONNECT
>> www.facebook.com:443 - HIER_NONE/- -
>> 1363776566.912 0 192.168.0.52 NONE/403 3575 GET
>> https://www.facebook.com/ - HIER_NONE/- text/html
>>
>> I see the error message from Squid.
> The above looks correct to me: Squid knew that the connection should be
> denied, responded with 200 OK to the CONNECT request, bumped the
> connection, received the first bumped GET request, and sent the error
> message.
>
> Does browser show any signs that it is expecting more of the Squid error
> message (e.g., spinning browser logo or some such)? Or does it look like
> the browser is 100% happy? Is there an established TCP connection from
> browser to Squid after the above Squid error message is displayed for a
> few seconds?
I used tcpdump and Wireshark to see the connections.
In the first time, the browser connect to the server over TLSv1 sending
Client Hello. Then the conection continues until the server sends FIN,
ACK. This looks correct for me.
In the second time, the browser try connect over SSL. When the browser
sends Client Hello, the server sends back RST, ACK.
I try disable SSL in the browser, but the problem persists. Also I tryed
put in squid.conf 'version=4' and 'options=NO-SSLv2':
http_port 3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB version=4 options=NO_SSLv2
cert=/etc/squid3/ssl_cert/bnpapel.pem
But in the second time I can see the SSL protocol.
>
>
>> The second time when accessing(pressing F5):
>>
>> No log, error message of the browser.
> That sounds a little odd. Did Squid receive anything from the browser?
> You can use tcpdump or similar tool to check. I wonder if by pressing F5
> the first time you simply disconnect the browser from Squid (i.e., the
> browser closes the persistent connection but does not request anything new).
>
> What error message does the browser show?
>
>
>> The third time when accessing(pressing F5):
>>
>> 1363776753.173 0 192.168.0.52 TCP_DENIED/200 0 CONNECT
>> www.facebook.com:443 - HIER_NONE/- -
>> 1363776753.186 0 192.168.0.52 NONE/403 3575 GET
>> https://www.facebook.com/ - HIER_NONE/- text/html
>>
>> I see the error message from Squid.
> OK, this looks correct, just like in the initial transaction.
>
>
> Cheers,
>
> Alex.
>
>
>
>
>> My squid.conf:
>>
>> #
>> # Recommended minimum configuration:
>> #
>>
>> # Example rule allowing access from your local networks.
>> # Adapt to list your (internal) IP networks from where browsing
>> # should be allowed
>> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
>> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
>> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
>> acl localnet src fc00::/7 # RFC 4193 local private network range
>> acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged)
>> machines
>>
>> acl SSL_ports port 443
>> acl Safe_ports port 80 # http
>> acl Safe_ports port 21 # ftp
>> acl Safe_ports port 443 # https
>> acl Safe_ports port 70 # gopher
>> acl Safe_ports port 210 # wais
>> acl Safe_ports port 1025-65535 # unregistered ports
>> acl Safe_ports port 280 # http-mgmt
>> acl Safe_ports port 488 # gss-http
>> acl Safe_ports port 591 # filemaker
>> acl Safe_ports port 777 # multiling http
>> acl CONNECT method CONNECT
>>
>> #
>> # Recommended minimum Access Permission configuration:
>> #
>> # Only allow cachemgr access from localhost
>> http_access allow localhost manager
>> http_access deny manager
>>
>> # Deny requests to certain unsafe ports
>> http_access deny !Safe_ports
>>
>> # Deny CONNECT to other than secure SSL ports
>> http_access deny CONNECT !SSL_ports
>>
>> # We strongly recommend the following be uncommented to protect innocent
>> # web applications running on the proxy server who think the only
>> # one who can access services on "localhost" is a local user
>> #http_access deny to_localhost
>>
>> #
>> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
>> #
>>
>> acl block url_regex .facebook.com
>> http_access deny block
>> # And finally deny all other access to this proxy
>> http_access deny all
>>
>> # Squid normally listens to port 3128
>> http_port 3128 ssl-bump generate-host-certificates=on
>> dynamic_cert_mem_cache_size=4MB cert=/etc/squid3/ssl_cert/bnpapel.pem
>>
>> sslcrtd_program /usr/src/squid-3.3.3/src/ssl/ssl_crtd -s
>> /etc/squid3/ssl_cert/ssl_db -M 4MB
>> sslcrtd_children 5
>>
>> # SSL Settings #
>>
>> ssl_bump server-first all
>> sslproxy_cert_error deny all
>>
>> # Uncomment and adjust the following to add a disk cache directory.
>> #cache_dir ufs /var/cache/squid 100 16 256
>>
>> # Leave coredumps in the first cache dir
>> coredump_dir /var/cache/squid
>>
>> # Add any of your own refresh_pattern entries above these.
>> refresh_pattern ^ftp: 1440 20% 10080
>> refresh_pattern ^gopher: 1440 0% 1440
>> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
>> refresh_pattern . 0 20% 4320
>> # Example rule allowing access from your local networks.
>> # Adapt localnet in the ACL section to list your (internal) IP networks
>> # from where browsing should be allowed
>> http_access allow localnet
>> http_access allow localhost
>
Received on Wed Mar 20 2013 - 17:04:15 MDT
This archive was generated by hypermail 2.2.0 : Wed Mar 20 2013 - 12:00:06 MDT