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

Thu Oct 19 14:09:03 UTC 2017

Hi Amos,

> 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.
>

On my first splash.php I was trying to redirect the url with  
splash.php?url=%u - that was one of the the problems with the loop  
between splash.php and accept.php - because the browser could not  
fullfill the request - because of a loop.

--- splash.php - NOT WORKING ---

<?php
session_start();
$_SESSION["goto"] = htmlspecialchars($_GET["url"]);
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"  
"http://www.w3.org/TR/html4/strict.dtd">
... and so on ...

--- splash.php - NOT WORKING ---

--- accept.php - NOT WORKING ---

<?php
session_start();
header("Location: " . $_SESSION["goto"] ); /* Browser umleiten */
session_unset();
session_destroy();
exit;
?>
<body>
</body>
</html>

--- accept.php - NOT WORKING ---

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

I will delete the problematic lines from my configuration example. BUT  
fist I will read the documentation again, to understand what I'm doing.

By the way, I don't use it in my small family production environment,  
I was doing that only for testing an learning, how MITM could be done.

I respect the privacy of my family, so I wouldn't use it productively.

>  "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

Thank you so much for your help and reading my DokuWiki to make it better!
Klaus.

-- 

------------------------------------------
e-Mail  : klaus at tachtler.net
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 3120 bytes
Desc: Öffentlicher PGP-Schlüssel
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20171019/be92f122/attachment.key>