<div dir="ltr">
<div><span class="gmail-im"><div>>Which is not supported by MSIE, so you are stuck with nothing at all for<br>
>that traffic. :-(

<br><br></div></span>The way things turn out , it seems like I am going to dedicate 1 or 2 proxy servers (without authentication)<br> and no tls client to proxy just for the domains that MS,Symantec and other vendors needs for the updates ,<br></div><div>and populate that proxies depending on domain in the pac file. <br></div><div><span class="gmail-im"><br><br>> If the LB are really digging into the traffic sufficiently to see URLs<br>
>(from inside the encryption?) then they are HTTP(S) proxies in their own<br>
>right and need to be accounted for in your TLS-to-proxy plans.

<br><br>
</span><div>My concern is the traffic client<->LB which needs to be encypted. <br></div>Traffic LB<->squid is safe. 

<br></div>The LB going to be used is HAProxy at layer 7 with url load balancing for http requests <br>and least connections for https requests . <br>The LB is going to do tls termination (for the client to tls proxy encryption part) for the squids as well .<br> Problem with kerberos is the ticketing mechanism<br> as far as  i know it cannot be shared between the squid proxies , <br>so if at first a user authenticates at lets say at cachebox01 then every time <br>he changes a cachebox during load balacning it is going to need to authenticate again .<br>Unfortunately src ip tagging cannot be performed as all clients are behind NAT. 

<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 22, 2018 at 3:32 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22/04/18 22:52, Panagiotis Bariamis wrote:<br>
>>LDAP is a database type, it is not specifically tied to the type of<br>
>>credentials used either. For example; have you looked into using<br>
>>Kerberos authentication? this over clear-text is similar or sometimes<br>
>>more secure than TLS.<br>
> <br>
> Unfortunately administrators of LDAP can only provide basic<br>
> authentication scheme, so I am stuck with TLS proxy<br>
<br>
</span>Which is not supported by MSIE, so you are stuck with nothing at all for<br>
that traffic. :-(<br>
<span class=""><br>
 , plus there are 16<br>
> squid boxes that a layer 7 load balancer routes the traffic depending on<br>
> the hash of the url , so I think even if the administrators of openldap<br>
> could provide me with kerberos or ntlm authentication I could not load<br>
> balance the traffic based on url .<br>
> <br>
<br>
</span>If the LB are operating only at the TCP/IP level (most routing LB do)<br>
they will not have any effect on the TLS, HTTP, or HTTP auth layers.<br>
Negotiate and HTTPS will work fine (NTLM is just broken, do not go there<br>
unless forced to).<br>
<br>
OR,<br>
 If the LB are really digging into the traffic sufficiently to see URLs<br>
(from inside the encryption?) then they are HTTP(S) proxies in their own<br>
right and need to be accounted for in your TLS-to-proxy plans.<br>
<br>
It may be that the LB is the entity(s) which need to be sending TLS to<br>
your Squid. With the browsers who can doing TLS to the LB proxy. That<br>
would get a portion LB<->Squid encrypted for MSIE even if the first bit<br>
cannot.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
</font></span></blockquote></div><br></div>