Hi Nick Thank you for this explanation. I think, you're right. Could this eventually be a security-problem, to allow unauthenticated https-traffic with "http_access allow CONNECT SSL_ports"? Might be yes, might be no. Is this behaviour part of a fact with SSL/HTTPS or could this be eventually solved with a future release of squid? Do you allow the CONNECT-method in your setup?
Regards, Tom 2010/8/28 Nick Cairncross <[email protected]>: > Tom, > > Just to say what I think (since you have almost the same setup as me I > think): you will always get that 407 at the moment. Squid requires an > authenticated user before allowing the page but you can't authenticate every > method (at least that is what I have found) in my setup. > > Regardless of whether it is ntlm or Kerberos etc. Your rule about connect I > think needs an allow connect ssl_ports ABOVE your allow INTERNET_ACCESS > because you're just disallowing the CONNECT method (not the same as the GET > method) using non-ssl ports otherwise. There's nothing talking about allowing > it. >> > > > I think that's right.... > Nick > > > > On 27 Aug 2010, at 10:09, "Tom Tux" <[email protected]> wrote: > >> Hi Amos >> >> Thanks a lot for this informations. >> >> Is it usual/normal, that all https-requests have this error? >> 1282899033.246 0 xx.xx.xx.xx TCP_DENIED/407 3720 CONNECT >> mail.google.com:443 - NONE/- text/html >> >> As I already mentioned: The sites, which are denied in the access.log, >> are normal accessible and appears correctly (this is, what I don't >> understand....mmmh....). >> I think, that I don't have rules, which explicitly require another >> authentication instead of kerberos. Here is an extract of my >> squid.conf: >> >> The ACL "INTERNET_ACCESS" is an external_acl with squid_kerb_ldap: >> http_access deny !Safe_ports >> http_access deny CONNECT !SSL_ports >> >> # Block invalid Users >> http_access deny !INTERNET_ACCESS >> http_access allow INTERNET_ACCESS >> http_access deny all >> >> When I trace the http/https-traffic with httpfox (firefox-addon), then >> I got also no errors or denies back. >> >> Thanks a lot for all helps. >> Tom >> >> >> 2010/8/27 Amos Jeffries <[email protected]>: >>> Tom Tux wrote: >>>> >>>> Hi >>>> >>>> For every HTTPS-Site I have the following tcp_denied/407-entry in the >>>> access.log: >>>> 282895826.492 1 xx.xx.xx.xx TCP_DENIED/407 3720 CONNECT >>>> mail.google.com:443 - NONE/- text/html >>>> 1282896033.320 1 xx.xx.xx.xx TCP_DENIED/407 3744 CONNECT >>>> secure-www.novell.com:443 - NONE/- text/html >>>> >>>> The sites, which are denied in the access.log, are though accessible, >>>> but I have this errors. For me it seems, that squid needs a user >>>> authentication. But this should be given with kerberos-authentication, >>>> which works fine. >>>> >>>> I have the following directives configured (as default): >>>> acl SSL_ports port 443 >>>> acl CONNECT method CONNECT >>>> http_access deny CONNECT !SSL_ports >>>> >>>> >>>> Can someone explain me this behaviour? >>> >>> CONNECT requests to SSL ports (aka HTTPS) will get past that security >>> barrier and move on to checkig your other rules. One of those other rules >>> involves proxy authentication. >>> >>> All requests which require authentication but do not provide it get a 407 or >>> 401 response challenging the browser to provided some credentials. This is >>> true for all authentication types. >>> >>> Working browsers with access to the required credentials will send them on a >>> followup request and get past that challenge. >>> >>> Amos >>> -- >>> Please be using >>> Current Stable Squid 2.7.STABLE9 or 3.1.7 >>> Beta testers wanted for 3.2.0.1 >>> > > > The information contained in this e-mail is of a confidential nature and is > intended only for the addressee. If you are not the intended addressee, any > disclosure, copying or distribution by you is prohibited and may be unlawful. > Disclosure to any party other than the addressee, whether inadvertent or > otherwise, is not intended to waive privilege or confidentiality. Internet > communications are not secure and therefore Conde Nast does not accept legal > responsibility for the contents of this message. Any views or opinions > expressed are those of the author. > > The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover Square, > London W1S 1JU >
