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
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
