Search squid archive

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux