Re: [squid-users] Client Certificate Authentication

From: Jaime Nebrera <jnebrera_at_eneotecnologia.com>
Date: Tue, 15 Mar 2011 14:05:17 +0100

   Hi Amos,

   Ok, I have been able to discuss this a bit with the other team.

   First of all, they have clarified the certificate stuff. As you
stated, the proxy would use its own certificate against remote sites, as
the other way would be a complete mess.

   So the browser validates against the proxy with its own certificate
and then the proxy uses its own to validate against the remote site.
This allows to break the tunnel in two pieces and inspect the session
for caching / virus etc

   Second, it seems Bluecoat (the proprietary alternative) is able to
auth the user using a certificate, I guess, making itself a webserver
instead of a standard proxy. We dont know exactly how this is done, let
me investigate a bit further.

   Regards

On 15/03/11 12:29, Amos Jeffries wrote:
> On 15/03/11 23:04, Jaime Nebrera wrote:
>> Hi Amos,
>>
>>>> I didnt know this. Might it be that they are confused and that they
>>>> might be using Kerberos or something like that that in essence is based
>>>> in certificates?
>>>
>>> What do you mean by "they" being confused? You earlier said you were
>>> setting this up. My answer was based around your question.
>>
>> Yes, we are setting this on our own but on premise of certain specs. I
>> was asked to see if it was possible to do the same "through the proxy"
>> as other team is doing with end "web sites"
>>
>
> Ah, well.
> Normal HTTPS "through a proxy" uses a CONNECT tunnel. The encryption
> inside that is end-to-end from client to the website server. The proxy
> itself does not get involved (unless the MITM case is setup, then the
> certificate breakage is the MITM admins problem/fault not yours).
>
> Certificate validation *to* the proxy. As I said needs stunnel at the
> client end to wrap the browsers traffic. One day hopefully the browsers
> will encrypt, but today that is not a reality. Squid is ready for it now
> just in case.
>
>
>>> They likely do it similar or the same way Squid does. With MITM and
>>> generating a new fake certificate. You asked for ways to do it *without*
>>> MITM, and relaying on a specific existing client certificate set at the
>>> browser end of the transaction. The fake certs used in MITM do not pass
>>> validation such as a server checking for specific client certs does.
>>
>> Mmm, I understand this is only doable with a MITM deployment as in
>> essence you would be forging the original user. I raised the question
>> that this was a security concern bby itself, but I believe would be the
>> only way.
>>
>
> For the end-to-end use of one certificate yes. If the system can cope
> with two certs client->Squid and Squid->webserver, then the MITM need
> disappears and the stunnel type setup can be used to clients with a
> separate Squid cert to servers.
>
> Amos

-- 
Jaime Nebrera - jnebrera_at_eneotecnologia.com
Consultor TI - ENEO Tecnologia SL
C/ Manufactura 2, Edificio Euro, Oficina 3N
Mairena del Aljarafe - 41927 - Sevilla
Telf.- 955 60 11 60 / 619 04 55 18
Received on Tue Mar 15 2011 - 13:05:21 MDT

This archive was generated by hypermail 2.2.0 : Tue Mar 15 2011 - 12:00:01 MDT