Re: [squid-users] Client Certificate Authentication

 On Tue, 15 Mar 2011 16:19:29 +0100, Jaime Nebrera wrote:
> Hi again Amos,
>
> After some extended reading of BlueCoat manual I have been able to
> undertand how they do the things, and how confused were the guys of
> the other team.

 Aha. BC.

>
> The first thing that shows up very clearly:
>
> "HTTPS applications that require browsers to present client
> certificates to secure Web servers do not work if you are
> intercepting
> traffic. Create a policy rule to prevent the interception of such
> applications."
>
> So if the remote webserver requires a certificate itself, this is a
> clear "no way" unless we use the proxy certificate instead of the
> browser one.
>
> Second comes the fact on how it intercepts the traffic. This, as
> stated, is only valid for server side certificates without client
> side.
>
> The proxy connects to the remote server on its behalf and checks
> the validity of the certificate the remote webserver employs. If Ok,
> then creates a new one on the fly and makes the browser believe its
> connecting to the remote server. Of course, this would trigger a lot
> of warnings on browser side, thus the self signed certificate
> generated by the proxy has to belong to a CA that is trusted bu the
> browser.
>
> Is this possible with squid?

 This is their version of SSLBump. Both behave identically for breaking
 into forward-proxy CONNECT requests.

 I'm not certain if they have gone so far as to intercept port 443
 native traffic though. It is theoretically possible, but has the exact
 same limits. We have avoided implementing it so far in Squid. Doing so
 is clearly over the boundary of LAN firewall MITM security and into the
 area of enabling remote attackers.

>
> Then comes the auth stuff you clearly pointed out was not possible
> at this stage not due to squid faulty, but lack of browser support. I
> was aware they were not employing stunnel or such, thus something
> different was there.
>
> What they do is provide a website under their control and instruct
> the browser to use it, say auth_gateway.eneotecnologia.com That one
> of
> course is SSL enabled.
>
> The browser connects to it, recieves a server certificate, its ok,
> its prompted to provide its own certificate and sends that info to
> the
> web server. Now, that information is used to auth the client (is the
> certificate ok) as well as to extract user information from the
> certificate itself (name, email etc)
>
> That webserver provides that information to the proxy and voila,
> you have a user to check against LDAP or whatever.
>
> I believe this "webserver" is within the "proxy" itself, and this
> should be a "helper" within squid.
>
> Is this done? Would it be doable?

 This site bounce is not done in code by Squid.
  It would be configured by setting up Squid with two ports for
 forward-proxy and reverse-proxy side by side. The forward proxy traffic
 would hit a deny_info to do the bounce and both would process through
 some ACL recording and permitting clients IP sessions. You would have to
 be careful about clients visiting through other proxies (shared IP
 screws with the session).

 Just mentioning for completion,
  I've thought you may want to try with a stunnel or SSH setup like a
 VPN tunnel to a squid https_port. The client browser being unaware if
 possible that its actually going through the tunnel. Alongside that the
 browser configured to use the proxy as a regular forward proxy. This
 would result in:

  Client passing CONNECT to squid, thus the cert goes through the
 CONNECT to the remote web server.
 PLUS
  stunnel/ssh silently wraps the client->Squid link in a second layer of
 encryption using the same cert.

 That would produce the SSO effect. Though doubling the encryption has a
 performance impact. This is a side effect of using certificates to
 actually physically encrypt the entire data stream. SSO done with
 credentials does not touch the data stream so does not have this
 noticable effect.

>
> Well, sorry for any "noise" in prior emails, but to be honest,
> understanding other people when they just say it works with BlueCoat
> is a bit hard :D Thank they do have a great manual

 No problem. I understand perfectly :)

 Amos

>
> Very kind 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
Received on Wed Mar 16 2011 - 00:31:29 MDT