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