[squid-users] [SOLVED] Re: Question about: ext_session_acl Splash/Portal solution.

[Amos Jeffries]

On 20/10/17 00:47, Klaus Tachtler wrote:
> Hi Amos,
> hi list,
> 
> I found my problem and the solution for it. The problem was inside the 
> apache host, who is holding my accept.php page. The splash.php and 
> accept.php page had some problems too, but now it's working.
> 
> For my solution, see following link (sorry the description are only in 
> German language available):
> - 
> https://www.dokuwiki.tachtler.net/doku.php?id=tachtler:squid_centos_7#portal_splash_pages 
> 

I'm not quite following from the Google-translate of that page what you 
mean. Was it a PHP specific issue, or something(s) that you think we 
should warn others about in our wiki Splash config example?
  If the latter, please propose some text to add to the wiki about it.



The config files I see in that page contains some configuration lines I 
am trying to get people to stop doing:

  "always_direct allow all" - was an old hack that is no longer needed 
for SSL-Bump. Mentioning it adds confusion for people who dont 
understand the directive already - and those who know about its meaning 
should know whether they need it or not.


  "sslproxy_cert_error allow all" - PLEASE don't even mention doing 
"allow all" on this directive. It prevents debugging problems and even 
worse adds many major security vulnerabilities in production proxies. So 
just dont.
  If you need to mention the directive at all, please do so in terms of 
specific errors which are relatively harmless to ignore. (if there is no 
safely ignored error for the use-case, then this directive is not safe 
to use obviously).


  "sslproxy_flags DONT_VERIFY_PEER" - just no. This disables TLS 
security checks. Period. like the above it prevents debugging problems 
and even worse adds many major security vulnerabilities in production 
proxies. So just dont. And please pass that advice to others you find 
doing this as well - this setting really cannot die fast enough.

The system trusted CA should work for most servers. Main cause of errors 
is admin not updating their system CA certs list regularly enough. Next 
most common is really broken servers - for those you can add entries to 
the files loaded by:

  * Squid-3.4 and older add any missing CA with 
<http://www.squid-cache.org/Doc/config/sslproxy_cafile/> as necessary.

  * Squid-3.5 add intermediate CA (most common cert error situation) to 
<http://www.squid-cache.org/Doc/config/sslproxy_foreign_intermediate_certs/> 
and root CA (if any) to 
<http://www.squid-cache.org/Doc/config/sslproxy_cafile/> as necessary.

* Squid-4 should auto-fetch the missing intermediates. So you should 
only need to add trust for some occasional root CA to 
<http://www.squid-cache.org/Doc/config/sslproxy_foreign_intermediate_certs/>.

It should be obvious, but to be very clear all of the above CA loading 
options should *only* be done for CA certs which you actually trust. 
Letting the client hit CA cert errors for dangerous CA is a *good* thing 
- that is precisely the point of having CA certs in TLS.



> 
> Thank you Amos, for your patience and help!
> Klaus.
> 

You are very welcome. :-)

Amos