Re: [squid-users] HTTP 407 responses

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 14 Feb 2012 11:25:37 +1300

On 14.02.2012 04:15, Mr J Potter wrote:
> Hi team,
>
> I'm trying to set up an authenticating squid proxy with a nice login
> box
> rather than the one the browser pops up with a HTTP 407 request...
> Does
> anyone know how to do this? The main reasons for this are (1) to make
> it
> look nice (2) so that I don't have to tell people to put in
> DOMAIN\user
> into the box, (3) put some instructions as to what is going on and
> (4) to
> add a limited guest login option.

(1) is not supported by any of the web specifications at this point.
Someone in the IETF had a nice proposal to allow headers to be set from
<form> tag fields in HTML. I'm not sure where that went, at the time I
saw it was still looking for support to get to the Draft stage.

(2) is a feature of the AD or Samba PDC backend. They can be set to
require the DOMAIN part or add a default value if missing.

(3) permitting the server to determine what gets displayed on the login
area opens it to phishing vulnerabilities. For most of the auth schemes
the realm parameter is used by browsers after some heavy input
validation as part of the title or descriptive text of the login popup.
If you set it to a sane value the popup is self-explanatory to all
users.

>
> This is where I am so far...
>
> - I've got NTLM authentication working
> - I've got a nice login page in ERR_CACHE_ACCESS_DENIED
> and ERR_ACCESS_DENIED
> - I've still got to write the bit to authenticate people, but I'm not
> too
> worried about that.
>
> Highlights from my squid.conf file looks like this:
>
> auth_param ntlm program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 45
>
>
> acl authdUsers proxy_auth REQUIRED
>
>
> http_access deny !authdUsers ### Kicks up a 407 request
> http_access deny all
>
> The second last line is the tricky one - I can see why the line
>
> http_access allow authdUsers
>
>
> would trigger a 407 request, but I'd hoped the deny ! option would
> get
> around this.

Nope. Both lines REQUIRE auth challenge before they can be tested. The
deny line ending in an auth ACL also produces auth challenge when it
matches. The browser takes it from there.

The modern browsers all protect themselves against attackers by
discarding the response body (your page) on 407/403 status and using a
safe popup they own and can trust for secure user interaction.

What you can do instead of altering the form and popup is present a
session with splash page (your instructions) ahead of the login popup
like so:

  external_acl_type session ...
  acl doneSplash external session

  # URI to display splash page with your instructions (no login form
allowed though)
  acl splash url_regex ^http://example.com/Splash

  # link ACL to splash page
  deny_info 307:http://example.com/Splash?r=%s doneSplash

  # let splash page go through no limits.
  http_access allow splash

  # bounce to splash page if not logged in yet AND this is a new session
  http_access deny !authedUsers !doneSplash

  # do login
  http_access allow authedUsers

The page Splash gets passed the original URI in r=%s, which it can use
to present a "continue"/ "accept" link after reading.

Amos
Received on Mon Feb 13 2012 - 22:25:41 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 15 2012 - 12:00:03 MST