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
