Search squid archive

Re: explicit forward proxy to server requring client authentication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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@xxxxxxxxxxxxx> 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

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux