Well, for me it is not so much of a problem since I upstream to an ISP with content/malware protection etc, but it would be nice to be able report on all users of every method. Perhaps someone could enlighten this mail? My relevant squid.conf is as follows (I have the ACLs defined obviously...) ## GLOBAL DENY RULES http_access deny !Safe_ports http_access deny MSNMessenger CNP_172SUBNETS !IP_MSNMESSENGER http_access deny StopDirectIP !IP_CONNECTALLOW http_access deny CONNECT !SSL_Ports !CNP_172SUBNETS http_access deny POST !SSL_Ports !RTMP_ports !CNP_172SUBNETS # POST/CONNECT Method ALLOW # http_access allow CONNECT CNP_172SUBNETS http_access allow POST CNP_172SUBNETS ## USERS AUTHENTICATION ACL## http_access allow AuthenticatedUsers On 30/08/2010 11:39, "Tom Tux" <tomtux80@xxxxxxxxx> wrote: >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 <Nick.Cairncross@xxxxxxxxxxxxxxx>: >> 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" <tomtux80@xxxxxxxxx> 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 <squid3@xxxxxxxxxxxxx>: >>>> 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 >> 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
