[squid-users] Client to proxy encryption for Internet Explorer

[Panagiotis Bariamis]

 >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)
 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.
The LB going to be used is HAProxy at layer 7 with url load balancing for
http requests
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 at treenet.co.nz> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180422/29daa49d/attachment.html>