Client to proxy encryption for Internet Explorer

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Client to proxy encryption for Internet Explorer

Panagiotis Bariamis
Hello ,
I have managed to set up a forward Secure squid proxy (tls) .
Although Mozzila (through a pac file with "RETURN HTTPS x.y.z:443) and chrome (with command line argument "--proxy-server="https://x.y.z" ) work OK with the squid proxy , Internet Explorer seems as if doesn't support that function .
Are there any other configuration in Internet Explorer to work or some auxiliary program for windows to support squid server with directive https_port for forward proxying ?


 

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Amos Jeffries
Administrator
On 21/04/18 05:53, Panagiotis Bariamis wrote:

> Hello ,
> I have managed to set up a forward Secure squid proxy (tls) .
> Although Mozzila (through a pac file with "RETURN HTTPS x.y.z:443) and
> chrome (with command line argument "--proxy-server="https://x.y.z" )
> work OK with the squid proxy , Internet Explorer seems as if doesn't
> support that function .
> Are there any other configuration in Internet Explorer to work or some
> auxiliary program for windows to support squid server with directive
> https_port for forward proxying ?
>

Unfortunately the answer there is "no" in regard to IE support. AFAIK
the MS team working on IE also have no plans to add it. IE is formally
on its way towards deprecation so major new functionality like that is
highly unlikely to happen. Their Edge browser may be a different story.

There are a number of tools for tunneling traffic over a proxy but they
tend to be for non-HTTP(S) protocols to go over a regular HTTTP
forward-proxy.

Which leaves only the SSL-Bump functionality in Squid to MITM the traffic.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Panagiotis Bariamis
>Unfortunately the answer there is "no" in regard to IE support. AFAIK
>the MS team working on IE also have no plans to add it. IE is formally
>on its way towards deprecation so major new functionality like that is
>highly unlikely to happen. Their Edge browser may be a different story.
Well if they add in in Edge it is going to be system wide as in Internet Explorer. Hopefully they will add the functionality at least at Edge.


>Which leaves only the SSL-Bump functionality in Squid to MITM the traffic.
This functionality does not help much as the problem is the credentials sent over clear text to proxies .

Thank you for the clarifications.
 

On Fri, Apr 20, 2018 at 9:25 PM, Amos Jeffries <[hidden email]> wrote:
On 21/04/18 05:53, Panagiotis Bariamis wrote:
> Hello ,
> I have managed to set up a forward Secure squid proxy (tls) .
> Although Mozzila (through a pac file with "RETURN HTTPS x.y.z:443) and
> chrome (with command line argument "--proxy-server="https://x.y.z" )
> work OK with the squid proxy , Internet Explorer seems as if doesn't
> support that function .
> Are there any other configuration in Internet Explorer to work or some
> auxiliary program for windows to support squid server with directive
> https_port for forward proxying ?
>

Unfortunately the answer there is "no" in regard to IE support. AFAIK
the MS team working on IE also have no plans to add it. IE is formally
on its way towards deprecation so major new functionality like that is
highly unlikely to happen. Their Edge browser may be a different story.

There are a number of tools for tunneling traffic over a proxy but they
tend to be for non-HTTP(S) protocols to go over a regular HTTTP
forward-proxy.

Which leaves only the SSL-Bump functionality in Squid to MITM the traffic.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Amos Jeffries
Administrator
On 21/04/18 06:40, Panagiotis Bariamis wrote:

>>Unfortunately the answer there is "no" in regard to IE support. AFAIK
>>the MS team working on IE also have no plans to add it. IE is formally
>>on its way towards deprecation so major new functionality like that is
>>highly unlikely to happen. Their Edge browser may be a different story.
> Well if they add in in Edge it is going to be system wide as in Internet
> Explorer. Hopefully they will add the functionality at least at Edge.
>
>
>>Which leaves only the SSL-Bump functionality in Squid to MITM the traffic.
> This functionality does not help much as the problem is the credentials
> sent over clear text to proxies .
>

"credentials" does not necessarily mean passwords.

TLS also sends credentials in clear. It just happens those credentials
are called certificates. Likewise all auth schemes in HTTP (except
Basic) send security tokens of various types - not passwords.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Panagiotis Bariamis
>"credentials" does not necessarily mean passwords.

>TLS also sends credentials in clear. It just happens those credentials
>are called certificates. Likewise all auth schemes in HTTP (except
>Basic) send security tokens of various types - not passwords.

When referring to credentials I mean basic ldap authentication for squid servers.
Those are sent in plain text (well base64) in every request. So my concern is the client to proxy encryption so as to protect those credentials.

On Fri, Apr 20, 2018 at 9:48 PM, Amos Jeffries <[hidden email]> wrote:
On 21/04/18 06:40, Panagiotis Bariamis wrote:
>>Unfortunately the answer there is "no" in regard to IE support. AFAIK
>>the MS team working on IE also have no plans to add it. IE is formally
>>on its way towards deprecation so major new functionality like that is
>>highly unlikely to happen. Their Edge browser may be a different story.
> Well if they add in in Edge it is going to be system wide as in Internet
> Explorer. Hopefully they will add the functionality at least at Edge.
>
>
>>Which leaves only the SSL-Bump functionality in Squid to MITM the traffic.
> This functionality does not help much as the problem is the credentials
> sent over clear text to proxies .
>

"credentials" does not necessarily mean passwords.

TLS also sends credentials in clear. It just happens those credentials
are called certificates. Likewise all auth schemes in HTTP (except
Basic) send security tokens of various types - not passwords.

Amos


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Amos Jeffries
Administrator
On 21/04/18 06:55, Panagiotis Bariamis wrote:

>>"credentials" does not necessarily mean passwords.
>
>>TLS also sends credentials in clear. It just happens those credentials
>>are called certificates. Likewise all auth schemes in HTTP (except
>>Basic) send security tokens of various types - not passwords.
>
> When referring to credentials I mean basic ldap authentication for squid
> servers.
> Those are sent in plain text (well base64) in every request. So my
> concern is the client to proxy encryption so as to protect those
> credentials.
>

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.

 <http://www.squid-cache.org/Versions/v3/3.5/manuals/negotiate_kerberos_auth.html>
 <http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_kerberos_ldap_group_acl.html>

That is the recommended Best Practice form of authentication with MSIE
and avoids the need for TLS solely to secure the credentials. Other
reasons for TLS remain, but are less important.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Panagiotis Bariamis
>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 , 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 .

On Sat, Apr 21, 2018 at 12:19 AM, Amos Jeffries <[hidden email]> wrote:
On 21/04/18 06:55, Panagiotis Bariamis wrote:
>>"credentials" does not necessarily mean passwords.
>
>>TLS also sends credentials in clear. It just happens those credentials
>>are called certificates. Likewise all auth schemes in HTTP (except
>>Basic) send security tokens of various types - not passwords.
>
> When referring to credentials I mean basic ldap authentication for squid
> servers.
> Those are sent in plain text (well base64) in every request. So my
> concern is the client to proxy encryption so as to protect those
> credentials.
>

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.

 <http://www.squid-cache.org/Versions/v3/3.5/manuals/negotiate_kerberos_auth.html>
 <http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_kerberos_ldap_group_acl.html>

That is the recommended Best Practice form of authentication with MSIE
and avoids the need for TLS solely to secure the credentials. Other
reasons for TLS remain, but are less important.

Amos


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Client to proxy encryption for Internet Explorer

Amos Jeffries
Administrator
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users