Re: [squid-users] Squid accel only after logon

On 27/11/2013 8:58 p.m., P K wrote:
> Hi,
>
> I want to use Squid as a reverse proxy (accel) to my main website but
> only if they've authenticated - something like a captive portal (not
> sure if that's the right phrase). By "authenticated", I don't mean
> basic or digest etc. I want to provide my own logon page (say php) - I
> can host another authentication website to host that.
>
> How do I go about achieving that? Splash page functionality is
> something that looks promising in squid but I can't get my head around
> how to force squid to reverse proxy my site only after users have
> authenticated on my php splash page. Also I need to terminate their
> session after 3 hours.
>

Okay. I think you misunderstand what a reverse proxy does and how it
operates in relation to the main web server.

A reverse proxy is simply a gateway to the main server which is used to
offload serving of static files, do server-side caching, routing between
different backends, certain types of access control and reduce impact
from DoS attacks.

It is better to simply pass all trafic through the proxy on its way to
the main web server.

The type of authentication you are describing is called
application-layer authentication and exists outside of HTTP and thus
outside of the normal capabilities of an HTTP reverse proxy. It can be
done but with great complexity and difficulty.

Once again it is better to leave the authentication non-authenticatino
decisions to the main web server and have it send back appropriate HTTP
headers to inform the proxy how to handle the different responses.

> http://wiki.squid-cache.org/ConfigExamples/Portal/Splash
>

No your requirements do not match with the limits or capabilities of a
captive portal. Captive portal uses an *implicit* session. Your system
uses an *explicit* session.

Please also note that captive portal *doe not* do authentication in any
reiable way. The splash page can have application-layer authentication
built in, BUT what the HTTP layer is doing is assuming / guessing that
any request with a similar fingerprint as the authenticated one is
authorized to access the resource.
 Being an assumption this authorization has a relatively high rate of
failure and vulnerability to a large number of attacks.

For example; the captive portal works mostly okay in situations where
the portal device is itself allocating the IP address or has access to
the clients MAC address information.
 Doing it on a reverse proxy will immediately have trouble from NAT,
relay routers, and ISP-based proxies - all of which obfuscate the IP
address details.

> I can do something like this:
>
> #Show auth.php
> external_acl_type splash_page ttl=60 concurrency=100 %SRC
> /usr/local/sbin/squid/ext_session_acl -t 7200 -b
> /var/lib/squid/session.db
>
> acl existing_users external splash_page
>
> http_access deny !existing_users
>
> # Deny page to display
> deny_info 511:https://myauthserver/auth.php?url=%s existing_users
> #end authphp
>
> #reverse proxy
>
> https_port 443 cert=/path/to/x_domain_com.pem
> key=/path/to/x_domain_com.pem accel
>
> cache_peer 1.1.1.1 parent 443 0 no-query originserver ssl
> sslflags=DONT_VERIFY_PEER name=x_domain_com
> acl sites_server_x_domain_com dstdomain x.domain.com
> cache_peer_access x_domain_com allow sites_server_x_domain_com
> http_access allow sites_server_x_domain_com
> # end reverse proxy
>
>
> But how is this going to work? I can present a username/password on my
> auth.php and present a submit button to validate. But how do I tell
> squid that it is OK to serve x.domain.com?

The external_acl_type helper is recording past visits and needs to
determine its response based on whatever database records your login
page did to record the login.

>
> Also is there a better way of achieving my purpose?

Yes. Setup the proxy as a basic reverse proxy and leave the
application-layer authentication decisions to the main web server.

Application layer auth is usually done with session Cookies on the main
server. You can check for Cookie header in the proxy and bounce with
that same deny_info redirect if you like, to help reduce the main server
load. It wont be perfect due to other uses of Cookie, but it will catch
the definitely non-authenticated traffic.

BUT you are operating over HTTPS. Why the avoidance of HTTP level
authentication?

Amos
Received on Wed Nov 27 2013 - 11:19:34 MST