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.
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?
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?
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
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
--
Jaime Nebrera - jnebrera@xxxxxxxxxxxxxxxxxx
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
