>Which is not supported by MSIE, so you are stuck with nothing at all for
>that traffic. :-(
The way things turn out , it seems like I am going to dedicate 1 or 2 proxy servers (without authentication)>that traffic. :-(
and no tls client to proxy just for the domains that MS,Symantec and other vendors needs for the updates ,
and populate that proxies depending on domain in the pac file.
> If the LB are really digging into the traffic sufficiently to see URLs
>(from inside the encryption?) then they are HTTP(S) proxies in their own
>right and need to be accounted for in your TLS-to-proxy plans.
My concern is the traffic client<->LB which needs to be encypted.
Traffic LB<->squid is safe.
and least connections for https requests .
The LB is going to do tls termination (for the client to tls proxy encryption part) for the squids as well .
Problem with kerberos is the ticketing mechanism
as far as i know it cannot be shared between the squid proxies ,
so if at first a user authenticates at lets say at cachebox01 then every time
he changes a cachebox during load balacning it is going to need to authenticate again .
Unfortunately src ip tagging cannot be performed as all clients are behind NAT.
On Sun, Apr 22, 2018 at 3:32 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 22/04/18 22:52, Panagiotis Bariamis wrote:
>>LDAP is a database type, it is not specifically tied to the type of
>>credentials used either. For example; have you looked into using
>>Kerberos authentication? this over clear-text is similar or sometimes
>>more secure than TLS.
>
> Unfortunately administrators of LDAP can only provide basic
> authentication scheme, so I am stuck with TLS proxy
Which is not supported by MSIE, so you are stuck with nothing at all for
that traffic. :-(
, plus there are 16
> squid boxes that a layer 7 load balancer routes the traffic depending on
> the hash of the url , so I think even if the administrators of openldap
> could provide me with kerberos or ntlm authentication I could not load
> balance the traffic based on url .
>
If the LB are operating only at the TCP/IP level (most routing LB do)
they will not have any effect on the TLS, HTTP, or HTTP auth layers.
Negotiate and HTTPS will work fine (NTLM is just broken, do not go there
unless forced to).
OR,
If the LB are really digging into the traffic sufficiently to see URLs
(from inside the encryption?) then they are HTTP(S) proxies in their own
right and need to be accounted for in your TLS-to-proxy plans.
It may be that the LB is the entity(s) which need to be sending TLS to
your Squid. With the browsers who can doing TLS to the LB proxy. That
would get a portion LB<->Squid encrypted for MSIE even if the first bit
cannot.
Amos
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
