[squid-dev] [PATCH] auth_schemes directive

[Amos Jeffries]

On 19/11/2016 12:56 p.m., Eduard Bagdasaryan wrote:
> Hello,
> 
> This patch introduces a new 'auth_schemes' squid.conf directive.
> 
> This directive may be used to customize authentication
> schemes presence and order in Squid's HTTP 401 (Unauthorized) and 407
> (Proxy Authentication Required) responses. The defaults remain the same.
> 
> Also refactored configuration code for options with custom
> ACL-controlled actions:
> 
> * Reduced parsing code duplication by adding ParseAclWithAction().
> 
> * Used functors for generic action-to-string conversions. It is possible
>   now to perform such conversions providing lambda expressions.
> 
> * Used vectors of strings instead of C-style arrays for storing
>   conversion tables and check against bounds with vector::at().
> 

-1. This patch is conflating two major feature additions.


Firstly;


The logic changes adding support for access controls 'kind' other than
allow/deny should be proposed as a separate feature addition.

Secondly;

IMO the access control for schemes is implemented wrong.

For the past 10 years admin who have been requesting control over what
schemes get advertised to clients have been driven by two main use cases:

 1) segmented networks where auth is done differently on each segment
(ie WAN vs LAN) but all segments share the one proxy.
 - either access controls to prevent some scheme being advertised to one
segment,
 - or being able to use one scheme name in several different ways
(different helper or realm etc.) .

 2) to administratively perform security downgrade attacks on clients.
Though this is usually spoken of as 'fixing' clients who repeatedly
request access with one particular (secure) credential type.


To resolve (1) fully we will need to have multiple Config objects with
the same scheme name and different config details.

To add auth scheme access controls in a way that does not actively
prevent (1) from being implemented later IMO we need to add access
controls as a member of the Config object, *not* as a global access list.

The config would look like:
 auth_param foo access allow blah blah
 auth_param foo access deny bar

 auth_param foo2 access deny blah
 auth_param foo2 access allow all

Amos