>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 <squ...@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 >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
