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_pagesI'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@xxxxxxxxxxxx Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Attachment:
biniFnc0nCgiG.bin
Description: =?utf-8?b?w5ZmZmVudGxpY2hlciBQR1AtU2NobMO8c3NlbA==?=
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
