On 18.10.2012 01:03, Marcus Kool wrote:
On 10/17/2012 02:18 AM, Amos Jeffries wrote:
On 17/10/2012 4:08 p.m., Cameron Charles wrote:
Hi all,
I am currently trying to setup basic "url/domain level" filtering
on
HTTPS traffic using an external acl, i can see clearly in the
access
log that the information i require is there and the external acl
finds
and filters it as desired, returning the correct response for
deny/allow and i can successfully browse https sites that are
allowed,
however sites that deny_info should redirect to the error page fail
and only a browser based error is returned, the error is as
follows...
Two datums you need to be aware of ... (re-ordered your listed facts
so the explanation makes sense)
For the failed denies the access.log shows the following (here
trying
https version of facebook)
1350442727 17/Oct/2012-13:58:47-EST 770 10.0.1.103 TCP_DENIED
307 408 CONNECT www.facebook.com:443 student1-2008 - text/html
A sucessful https browse to an allowed site looks like the
following
1350442986 17/Oct/2012-14:03:06-EST 9058 10.0.1.103 TCP_MISS 200
24489 CONNECT play.google.com:443 student1-2008 play.google.com
... 1) these are CONNECT requests. They are not HTTPS nor are the
resulting tunnels necessarily containing HTTPS requests even if they
are going to port 443.
They simply tell Squid to open a TCP connection to the named server
and port. Just a TCP connection.
This being Chrome you are using it is more likely that they are
going to send SPDY protocol than HTTPS - but either one or somethine
else entirely might result from that tunnel. It depends on things
outside Squids control and knowledge what the client and server
negotiate between themselves with the packets going through it *after*
CONNECT setup.
in firefox this is all that is displayed:
Unable to connect - Firefox can't establish a connection to the
server at www.facebook.com.
Google is a little more descriptive giving this error:
Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED): Unknown error.
... 2) this is Chromes way of reporting to the user that something
(anything!) other than complete end-to-end success happened. Friendly
no?
Squid successfully performed the checks and deny_info redirection
(TCP_DENIED/307 got logged), but Chrome is not handling the 307 status
in any useful way.
This is not just Chrome. All modern versions of MSIE/Chrome/Firefox
give an error like "cannot connect" or "proxy refusing connection".
It does not matter what HTTP error code Squid sends to the browser
since the browsers ignore the returned HTTP-based error messages
when sending a CONNECT and simply complain with "cannot connect".
FYI: old versions (4.x) of firefox did accept an HTTP error message
but the latest ones do not.
Marcus
This is NOT about 4xx/5xx error though. The reasonable arguments
against displaying 4xx/5xx (including auth login pages) are all about
how they are to display the information that the address bar and the
displayed page are not related. When they do it is trivial to break
security and foll the users who see an attacked sites login https:// URL
in the address bar and a fake login page from some intermediary posting
the credentials back to attackers server.
This is specifically Chrome ("Error 111
(net::ERR_TUNNEL_CONNECTION_FAILED): Unknown error.") responding to a
307 redirection.
What they are supposed to do is present a popup asking teh user if they
are allowed to repeat with the new location.
RFC 2616:
"If the 307 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued."
Instead they just bark some obscure code syntax at the user instead.
Cameron, I'm reminded of another method. Have you tried 303 code
instead? That one specifically tells the browser to change to GET and
fetch as a regular page. Useful for portal login pages and error display
pages for non-GET reuqests.
Amos
