Question about: ext_session_acl Splash/Portal solution.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about: ext_session_acl Splash/Portal solution.

Klaus Tachtler
Hi,

i have a running squid and I would like to show a splash screen and  
did following configuration:


--- code snipped ---
external_acl_type session concurrency=100 ttl=12000 negative_ttl=0  
children=1 %LOGIN /usr/lib64/squid/ext_session_acl -a -T 12000 -b  
/var/lib/squid/sessions/

acl session_login external session LOGIN

external_acl_type session_active_def concurrency=100 ttl=12000  
negative_ttl=0 children-max=1 %LOGIN /usr/lib64/squid/ext_session_acl  
-a -T 12000 -b /var/lib/squid/sessions/

acl session_is_active external session_active_def

acl clicked_login_url url_regex -i http://my.page.net/accept.php

http_access allow clicked_login_url session_login

http_access deny !session_is_active

deny_info <a href="http://my.page.net/splash.php?url=%u">http://my.page.net/splash.php?url=%u session_is_active
--- code snipped ---


After user authentication against ldap and enter the URL google.de the  
<a href="http://my.page.net/splash.php?url=%u">http://my.page.net/splash.php?url=%u will be shown, no problem to this  
point.

BUT, after reaching the http://my.page.net/accept.php (by pressing a  
button on the splash page) the splash page comes over and over again.

The /var/log/squid/access.log will show me that:

--- log ---

1507908437.361      1 192.168.0.10 TCP_DENIED/302 448 GET  
http://google.de/ username HIER_NONE/- text/html

--- log ---

Why I'm on a loop between splash page and accept page?

Thank you for any help!
Klaus.


--

------------------------------------------
e-Mail  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Amos Jeffries
Administrator
On 14/10/17 04:40, Klaus Tachtler wrote:>
> Why I'm on a loop between splash page and accept page?


You have two *separate* active (-a) session contexts going on
simultaneously. They are both fighting over the session database.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Klaus Tachtler
Hi Amos,

> On 14/10/17 04:40, Klaus Tachtler wrote:>
>> Why I'm on a loop between splash page and accept page?
>
>
> You have two *separate* active (-a) session contexts going on  
> simultaneously. They are both fighting over the session database.

Oh my god, to delete "-a" on the "session_active_def" was the solution.
I was searching hours and hours for that!

Thank you so much for the simple line you wrote to me!

> Amos
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

Thank you!
Klaus.


--

------------------------------------------
e-Mail  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Amos Jeffries
Administrator
On 15/10/17 10:02, Klaus Tachtler wrote:

> Hi Amos,
>
>> On 14/10/17 04:40, Klaus Tachtler wrote:>
>>> Why I'm on a loop between splash page and accept page?
>>
>>
>> You have two *separate* active (-a) session contexts going on
>> simultaneously. They are both fighting over the session database.
>
> Oh my god, to delete "-a" on the "session_active_def" was the solution.
> I was searching hours and hours for that!
>
> Thank you so much for the simple line you wrote to me!

If that is the only change you made it is still not solved either, your
sessions will never end.

You need *one* session. You get to pick active or passive:

* Active has specific ACLs for LOGIN/LOGOUT/test.
  - for when the clicked URL just *has* to be the specific one.

* Passive has only one ACL for atomic test+login.
  - for when either click OR refresh OR any other page fetch is enough
to continue.
  - every test of the ACL updates the session timestamp not to expire.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Klaus Tachtler
Hi Amos,

after a little bit more testing, of course I must agree with you, it  
doesn't work as expected.

Please can you give me another advice? Where is my fault?

I tried to use the *ACTIVE* example from the squid documentation and  
modified it a little bit on 3 parts of the code, BUT a LOOP are still  
there!

https://wiki.squid-cache.org/ConfigExamples/Portal/Splash#Squid_Configuration_File_-_Active_Mode

--- code ---

# Set up the session helper in active mode. Mind the wrap - this is  
one line: - *MODIFIED* - (all in one line)
external_acl_type session concurrency=100 ttl=3 negative_ttl=0  
children-max=1 %LOGIN /usr/lib64/squid/ext_session_acl -a -T 60 -b  
/var/lib/squid/sessions/

# Pass the LOGIN command to the session helper with this ACL
acl session_login external session LOGIN

# Normal session ACL as per simple example
acl session_is_active external session

# ACL to match URL - *MODIFIED* -
acl clicked_login_url url_regex -i http://my.pages.net/html/accept.php

# First check for the login URL. If present, login session
http_access allow clicked_login_url session_login

# If we get here, URL not present, so renew session or deny request.
http_access deny !session_is_active

# Deny page to display - *MODIFIED* - NOT using a template with HTML-Code 511!
deny_info <a href="http://my.pages.net/html/splash.php?url=%u">http://my.pages.net/html/splash.php?url=%u session_is_active

--- code ---

If you want, I can share the code from the pages
- http://my.pages.net/html/accept.php
- <a href="http://my.pages.net/html/splash.php?url=%u">http://my.pages.net/html/splash.php?url=%u
too?

The idea behind the two PHP pages are, to store the original URL with  
the splash.php inside a PHP session and make a redirect inside the  
accept.php to the original URL.


Thank you for your time and your patience with me!
Klaus.

> On 15/10/17 10:02, Klaus Tachtler wrote:
>> Hi Amos,
>>
>>> On 14/10/17 04:40, Klaus Tachtler wrote:>
>>>> Why I'm on a loop between splash page and accept page?
>>>
>>>
>>> You have two *separate* active (-a) session contexts going on  
>>> simultaneously. They are both fighting over the session database.
>>
>> Oh my god, to delete "-a" on the "session_active_def" was the solution.
>> I was searching hours and hours for that!
>>
>> Thank you so much for the simple line you wrote to me!
>
> If that is the only change you made it is still not solved either,  
> your sessions will never end.
>
> You need *one* session. You get to pick active or passive:
>
> * Active has specific ACLs for LOGIN/LOGOUT/test.
>  - for when the clicked URL just *has* to be the specific one.
>
> * Passive has only one ACL for atomic test+login.
>  - for when either click OR refresh OR any other page fetch is  
> enough to continue.
>  - every test of the ACL updates the session timestamp not to expire.
>
> Amos
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

----- Ende der Nachricht von Amos Jeffries <[hidden email]> -----




--

------------------------------------------
e-Mail  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Amos Jeffries
Administrator
On 16/10/17 07:17, Klaus Tachtler wrote:

> Hi Amos,
>
> after a little bit more testing, of course I must agree with you, it
> doesn't work as expected.
>
> Please can you give me another advice? Where is my fault?
>
> I tried to use the *ACTIVE* example from the squid documentation and
> modified it a little bit on 3 parts of the code, BUT a LOOP are still
> there!
>
> https://wiki.squid-cache.org/ConfigExamples/Portal/Splash#Squid_Configuration_File_-_Active_Mode 
>
>
> --- code ---
>
> # Set up the session helper in active mode. Mind the wrap - this is one
> line: - *MODIFIED* - (all in one line)
> external_acl_type session concurrency=100 ttl=3 negative_ttl=0
> children-max=1 %LOGIN /usr/lib64/squid/ext_session_acl -a -T 60 -b
> /var/lib/squid/sessions/
>
> # Pass the LOGIN command to the session helper with this ACL
> acl session_login external session LOGIN
>
> # Normal session ACL as per simple example
> acl session_is_active external session
>
> # ACL to match URL - *MODIFIED* -
> acl clicked_login_url url_regex -i http://my.pages.net/html/accept.php
>
> # First check for the login URL. If present, login session
> http_access allow clicked_login_url session_login
>
> # If we get here, URL not present, so renew session or deny request.
> http_access deny !session_is_active
>
> # Deny page to display - *MODIFIED* - NOT using a template with
> HTML-Code 511!
> deny_info <a href="http://my.pages.net/html/splash.php?url=%u">http://my.pages.net/html/splash.php?url=%u session_is_active


Please double-check the cacheing related headers on both your custom
URLs are set to make them non-cacheable. 302 is a weak substitute for
511 semantics, and requires caching headers to clearly and explicitly
prevent caching *and* to be followed by the client or the system can
breaks badly (which is why 511 was created).


Which exact version of Squid are you using? some of the early v4 had
issues with the format parameter changes which broke the active session
mode for a while.


Also, be aware that since the helper API is *only* using %LOGIN if any
visitor happens to send a request for the clicked_login_url without
credentials attached they will make a logged-in session for anonymous
access and the proxy becomes an 'open proxy' for any subsequent client
requests from *anywhere* for 63 seconds. Things like that are why %SRC
is usually used to make a session depend on things not as easily under
client control - such as src-IP.


If those don't work I'm stuck as well. The wiki config examples are ones
I used myself for many years before I moved to the sql_session helper.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Klaus Tachtler
Hi Amos,

first of all, thank you for help and advise, BUT I have still a  
problem - see my latest try:

--- code ---

# Set up the session helper in active mode. Mind the wrap - this is  
one line: - MODIFIED -
external_acl_type session concurrency=100 ttl=3 negative_ttl=0  
children-max=1 %SRC /usr/lib64/squid/ext_session_acl -a -T 60 -b  
/var/lib/squid/sessions/

# Pass the LOGIN command to the session helper with this ACL
acl session_login external session LOGIN

# Normal session ACL as per simple example
acl session_is_active external session

# ACL to match URL - MODIFIED -
acl clicked_login_url url_regex -i http://my.page.net/html/accept.php

# First check for the login URL. If present, login session
http_access allow clicked_login_url session_login

# If we get here, URL not present, so renew session or deny request.
http_access deny !session_is_active

# Deny page to display - MODIFIED -
deny_info 511:splash.php session_is_active

--- code ---

1.) I changed in the external_acl_type from: %LOGIN to: %SRC - after  
that NO authentication request against LDAP was done! - If I go back  
to %LOGIN a authentication request against LDAP comes as popup back!

2.) Disabled redirect insie the page -  
http://my.page.net/html/accept.php - so loading the page are done with  
200 and NO redirect inside - only the  
http://my.page.net/html/accept.php was displayed.

3.) deny_info uses now 511 and a "symbolic link" inside  
"/usr/share/squid/errors/templates" goes to the real location.

---> How it works <---

The splash.php page was shown. If I click on the submit button the  
http://my.page.net/html/accept.php was loaded and shown too, but after  
that it's NOT POSSIBLE to go to Google for example, the splash page  
was shwon over and over again! - I'm a little bit frustrated.

I use the CentOS 7.4 squid version 3.5.20 which comes with the base  
repository.

Thank you so much for your patience and help!
Klaus.


--

------------------------------------------
e-Mail  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Klaus Tachtler
Hi Amos,
hi list,

is there a problem with the Splash-Screen example from squid homepage
  - https://wiki.squid-cache.org/ConfigExamples/Portal/Splash
if the squid is BEHIND a e2Guardian(Fork of DansGuardian)?


Thank you!
Klaus.


--

------------------------------------------
e-Mail  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Klaus Tachtler
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


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




--

------------------------------------------
e-Mail  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

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

Klaus Tachtler
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  : [hidden email]
Homepage: http://www.tachtler.net
DokuWiki: http://www.dokuwiki.tachtler.net
------------------------------------------

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

attachment0 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Amos Jeffries
Administrator
On 20/10/17 03:09, Klaus Tachtler wrote:

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

Ah, thats part of what I was worried about. These settings make Squid
actively hide problems from both you as admin and the user / clients.
Having almost all the useful error messages hidden does not help you
learning / debugging what is going on.


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

These settings do not affect privacy. They make Squid stay silent even
if your network and clients are under heavy active attacks by outside
services. They also as a side-effect provide invisibility *to the
attackers* (not to your clients! ouch).
  Effectively they do the opposite of what a sane admin wants in todays
environment.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Question about: ext_session_acl Splash/Portal solution.

Amos Jeffries
Administrator
In reply to this post by Klaus Tachtler
On 19/10/17 19:11, Klaus Tachtler wrote:
> Hi Amos,
> hi list,
>
> is there a problem with the Splash-Screen example from squid homepage
>   - https://wiki.squid-cache.org/ConfigExamples/Portal/Splash
> if the squid is BEHIND a e2Guardian(Fork of DansGuardian)?
>

No, http_access and the related session things are all done first using
the URLs sent by the client.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users