Hi,
From what I saw with using IP as part of then authentication, it checks which IP the user is connecting to the server from. What I want to check is which public IP of the server the user is connecting to.
If someone connects to the server's IP address x.x.x.x, I want the outgoing traffic to go through the same IP address x.x.x.x. That's why I put an acl rule for each public IP of the server and specified the tcp_outgoing_address for each of them.
So, for example, if the server has say 50 public IP address, I want to create an user who will be able to connect to 25 of them and another to another 25.
I hope this clarifies my original question.
With regards,
Sonya Roy.
On Mon, Jun 19, 2017 at 5:30 PM, <squid-users-request@xxxxxxxxxxxxxxxxxxxxx> wrote:
Send squid-users mailing list submissions to
squid-users@lists.squid-cache.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.squid-cache.org/listinfo/squid-users
or, via email, send a message with subject or body 'help' to
squid-users-request@lists.squid-cache.org
You can reach the person managing the list at
squid-users-owner@lists.squid-cache.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of squid-users digest..."
Today's Topics:
1. Re: Squid authentication problem (Amos Jeffries)
2. Re: squid 4.0.20 does not recognize ssl-bump option.
(Alex Rousskov)
3. Re: squid 4.0.20 does not recognize ssl-bump option.
(Amos Jeffries)
------------------------------------------------------------ ----------
Message: 1
Date: Mon, 19 Jun 2017 00:56:31 +1200
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@lists.squid-cache.org
Subject: Re: Squid authentication problem
Message-ID: <343154ec-dbd6-aa55-f867-216d3c261423@xxxxxxxxxxxxx >
Content-Type: text/plain; charset=utf-8; format=flowed
On 18/06/17 17:50, Sonya Roy wrote:
> Hi,
>
> I am running squid on a server with multiple public IPs and I want
> some users to be able to access the proxy through some of the IPs and
> other users through other IPs.
>
> At the moment I have acl rules of the form:-
> acl abcd myip x.x.x.x
>
What you need is an ACL that compares the username to the IP.
<http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_ >file_userip_acl.html
<http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_ >edirectory_userip_acl.html
<http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_ >sql_session_acl.html
or the new 'extras' feature for authenticators in Squid-3.5 that lets
them use the IP as part of the auth approval. Though with this the thing
to be aware of is that the IP becomes like a scope for the user login -
the wrong IP being used to login from results in re-auth challenge just
as would be seen if the password was wrong. So use carefully.
<http://www.squid-cache.org/Doc/config/auth_param/ >
<http://www.squid-cache.org/Versions/v3/3.5/RELEASENOTES. >html#ss2.2
> and for these acl rules I have these tcp_outgoing_address:-
> tcp_outgoing_address x.x.x.x abcd
>
Why limit the outgoing? in HTTP that is independent to the incoming
connection and restricting it will lower performance.
> And earlier I had proxy_auth acl rules separately, but that allowed
> any authenticated users to be able to access the proxy through any of
> those IPs. Since I wanted some users to be able to use the server
> through some IPs and others through different IPs, I tried this in
> those acl rules:-
>
> acl abcd myip x.x.x.x proxy_auth user1
FTR: that will match the IP address x.x.x.x and the IP address(es) of
the servers with hostnames "proxy_auth" and "user1" in your local DNS.
Also, the myip ACL is deprecated because it matched different things
based on the traffic type. myportname or localip ACLs are better if you
need to do this at all. Your "squid -k parse" config checks should warn
you about that.
Amos
------------------------------
Message: 2
Date: Sun, 18 Jun 2017 16:53:15 -0600
From: Alex Rousskov <rousskov@measurement-factory.com >
To: meym <meym@xxxxxxxxxxxxxx>, Squid Users
<squid-users@lists.squid-cache.org >
Subject: Re: squid 4.0.20 does not recognize ssl-bump
option.
Message-ID:
<9e834f7b-b20b-2cb5-e439-3fa0eaf1223e@measurement- >factory.com
Content-Type: text/plain; charset=koi8-r
On 06/18/2017 09:49 AM, meym wrote:
>> On 06/17/2017 10:09 AM, meym wrote:
>>> Squid Cache: Version 4.0.20
>>> "FATAL: Unknown http_port option 'ssl-bump'."
>>
>> Your Squid thinks it was built without OpenSSL support. OpenSSL support
>> is required for SslBump. Examine your ./configure options and output.
> With libressl actually.
I do not know what you mean by that remark exactly, but what I said
applies to any library providing OpenSSL API, including LibreSSL. Moreover:
* Squid does not know anything about LibreSSL. Somebody added the
letters "LibreSSL" to squid.conf.documented, but that was a mistake IMO.
* Primary SslBump developers do not normally use or test with LibreSSL.
* LibreSSL provides OpenSSL API so you can tell Squid to use LibreSSL as
if it was OpenSSL, and things should work as well as with OpenSSL itself
if (and only if) LibreSSL does a good job providing that OpenSSL API.
* LibreSSL does not do a good job providing OpenSSL API and/or Squid
does not do a good job detecting OpenSSL API variations in a
LibreSSL-compatible way (depending on your point of view). See bug #4662
for more details.
There have been recent improvements in LibreSSL-compatibility area, but
I am not sure those improvements (or the problems) are in your Squid
version and, at any rate, are taking significant additional risks by
using LibreSSL with SslBump. Whether those risks are worth using
something other than OpenSSL is your call, of course.
Alex.
------------------------------
Message: 3
Date: Mon, 19 Jun 2017 21:12:57 +1200
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@lists.squid-cache.org
Subject: Re: squid 4.0.20 does not recognize ssl-bump
option.
Message-ID: <999533d5-0efa-8310-d32d-0ac0a10f34cd@xxxxxxxxxxxxx >
Content-Type: text/plain; charset=utf-8; format=flowed
On 19/06/17 10:53, Alex Rousskov wrote:
> On 06/18/2017 09:49 AM, meym wrote:
>>> On 06/17/2017 10:09 AM, meym wrote:
>>>> Squid Cache: Version 4.0.20
>>>> "FATAL: Unknown http_port option 'ssl-bump'."
>>>
>>> Your Squid thinks it was built without OpenSSL support. OpenSSL support
>>> is required for SslBump. Examine your ./configure options and output.
>
>> With libressl actually.
>
> I do not know what you mean by that remark exactly, but what I said
> applies to any library providing OpenSSL API, including LibreSSL.
To clarify that. This Squid is missing the --with-openssl build option,
which is required both by OpenSSL and any library derived from it.
see "squid -v" for the details of a specific squid binary. This will now
distinguish between the OpenSSL vs LibreSSL vs other situation.
> Moreover:
>
> * Squid does not know anything about LibreSSL. Somebody added the
> letters "LibreSSL" to squid.conf.documented, but that was a mistake IMO.
The mentions of LibreSSL in the current file are for things which were
tested before the recent round of LibreSSL issues. Specifically loading
CA certs from a file. AFAIK that should still be working.
ssl-bump is correctly not one of those options mentioning it. Also, note
that the fatal error message does not mention any particular library. It
is about lack of support from *any* library in the current build.
>
> * Primary SslBump developers do not normally use or test with LibreSSL.
>
> * LibreSSL provides OpenSSL API so you can tell Squid to use LibreSSL as
> if it was OpenSSL, and things should work as well as with OpenSSL itself
> if (and only if) LibreSSL does a good job providing that OpenSSL API.
>
> * LibreSSL does not do a good job providing OpenSSL API and/or Squid
> does not do a good job detecting OpenSSL API variations in a
> LibreSSL-compatible way (depending on your point of view). See bug #4662
> for more details.
>
> There have been recent improvements in LibreSSL-compatibility area, but
> I am not sure those improvements (or the problems) are in your Squid
> version and,
They are. Though the release notes still say "This release does not
support LibreSSL" at present since we have had no positive feedback on
anything actually working yet.
> at any rate, are taking significant additional risks by
> using LibreSSL with SslBump. Whether those risks are worth using
> something other than OpenSSL is your call, of course.
>
Since the risk here is due to lack of testing... More testing is very
welcome of course. Especially with feedback about what works and what
does not.
Amos
------------------------------
Subject: Digest Footer
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
------------------------------
End of squid-users Digest, Vol 34, Issue 46
*******************************************
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
