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