On 24/11/2015 1:16 a.m., Dave Lewthwaite wrote:
> Hi,
>
> I’ve finally found time to join the dev mailing list, I work with squid on a
> daily basis and we’re always needing the latest features which often causes
> to use beta’s and nightlies rather than final releases. At the moment I’m
> having an issue with SSL peek and splice with external ACLs.
>
> I'm using Squid 4.0.2 compiled for CentOS 7 and i'm having issues with the
> SSL peek and splice configuration that previously worked in 3.5.11 with no
> problems. (The reason to update is to get eliptic curve cipher support).
>
> Relavent config
>
> external_acl_type extallowedSslUsers children-startup=1 children-max=40 ttl=0
> negative_ttl=0 %MYPORT %SRC %{X-Proxy-Port}>h %{User-Agent}>h %DST %ssl::>sni
> /etc/squid/acl/aclSSLInterceptUsers.php
> acl allowedSslUsers external extallowedSslUsers
>
> acl DiscoverSNIHost at_step SslBump1
>
> ssl_bump stare DiscoverSNIHost all
> ssl_bump bump allowedSslUsers
> ssl_bump splice all
>
> In this configuration when using a normal proxy port or transparent port, the
> external ACL is never evaluated - it logs
>
> WARNING: allowedSslUsers ACL is used in context without an ALE state.
> Assuming mismatch.
>
> Changing DiscoverSNIHost to be SslBump2 causes the external acl to be
> evaluated for normal proxy port (but SNI is not populated) but still not for
> transparent proxy.
>
> The aim is to retrieve the SNI sent by the client to use in both logging and
> the external ACL.
>
> Swapping stare for peek gives the same behaviour. As far as I can tell, if
> the system hits this point (without an ALE state) it will skip the ACL check
> and return false – obviously that’s a problem – I’ve also tried stripping out
> parameters from the external acl to no avail.
>
> Is this a bug or a mis-configuration?
It is one of the effects of the external_acl_type format changes.
Is that message occuring on bumped CONNECT messages on an http_port, or
on an https_port?
And are you able to get an ALL,9 cache.log trace from a test request please?
Amos
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
