[squid-users] explicit forward proxy to server requring client authentication

[Robert W Weaver]

>> 18.05.16 3:11, Robert W Weaver пишет:
>>> The issue is I need to connect to a site that requires client
>>> authentication.  Don't want to put the key and cert on each individual
>>> user, so instead want the key and cert on the proxy.
>>> Diagram:

>>> User A ---> Squid S ---> Server B
>>>         ^            ^
>>>         |            +-- TLS client authentication
>>>         +-- cleartext okay

On Wed, 18 May 2016 17:48:26 +1200, Amos Jeffries <squid3 at treenet.co.nz> 
wrote:

> On 18/05/2016 10:05 a.m., Yuri Voinov wrote:
>> 
>> ..... and a bit below in squid.conf.documented we can see.....
>> 
>> # SSL OPTIONS
>> #
>> 
-----------------------------------------------------------------------------
>> 
>> #  TAG: sslproxy_client_certificate
>> #    Client SSL Certificate to use when proxying https:// URLs
>> #Default:
>> # none
>> 
>> #  TAG: sslproxy_client_key
>> #    Client SSL Key to use when proxying https:// URLs
>> #Default:
>> # none
>> 
>> Ta-daaaaaaaa!
> 

> You are the one getting it wrong here Yuri :-(

I am celebrating Yuri's ta dah.  The clue to squid.config.documented was 
crucial, and the specific hint to sslproxy_client_* was what was missing.

From S to B is now working properly.  Squid is now in the middle, and is 
performing authentication to server B properly.

> * clientca= is for listening ports. He wants that conectio to be 
cleartext.

> * sslproxy_* directives are for generic DIRECT connections. He wants a
> specific proxy<->server connection to be TLS authenticated.

> For the S<->B connection to use client certificates. cert= and key= on
> the cache_peer directive defining that link are correct.

> But there are twe other details that need to happen for it to work:
> * the server actually challenge for the proxies 'client' cert, and
> * the server trust the CA which signed that cert.

This is happening.  I'd generated a CSR and had the CA that is the "owner" 
of server B sign it for me.  We are cool.

> The world of "not working" is a very big place. We need more details of
> *how* its not working in order to have any guideposts towards what the
> problem actually is. As Yuri used to say a lot, my psychic friend is on
> holiday.

It is now working to an acceptable point, although there is an enhancement 
that would be nice.  Right now,

1.  A connects to S, requests https://B/some/image.png
2.  S connects to B over TLS, performs client authentication, gets 
/some/image.png (or pulls from cache)
3.  A converts to TLS to S, pulls down data.

This is fine, its just that there is an unnecessary encrypt/decrypt 
between A and S.  The connection is inside a controlled data center (on 
the same switch, perhaps on the same ESX host) so I'm not concerned about 
security -- not to mention the cached data isn't especially sensitive. 

So this last bit is just an enhancement, a nice to have.  Its the opposite 
of SSL termination for accelerators, so I suspect its possible, just don't 
know how to do it.

Coffee (or a favorite beverage) all around!

--woody

-- 
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160518/b4f0e808/attachment.html>