Re: large campus network ... sugestions
Hello,
Sorry I did not explain fully. Yes, Bluecoat does a MITM. It sees
where you want to go (say, an HTTPS page), and establishes an SSL
session with it. It, then, generates an SSL certificate signed by
"him" saying "he" is the URL your are trying to visit. All traffic
between you and the Bluecoat appliance is encrypted through SSL. It
is then unencrypted, checked, and encrypted again through SSL towards
the server. So for each outgoint SSL session, there are actually two:
one towards the "external world" and one to the machine initiating the
SSL connection (the user). When set up this way, these appliances
usually have several cryptographic hardware accelerators, to be able
to create and sign these certificates on the fly, and encrypt and
decrypt the communications with them, and analyzing them in case they
shuld be filtered.
If you do not have the CA inside the Bluecoat appliance as a trusted
CA, then your browser (or whatever program you are using) would
complain. In Windows environments, to trust the Bluecoat's CA can be
easily achieved by setting it that way in the Active Directory
policies.
Regards,
Jonas.
On Dec 15, 2007 4:23 PM, Roman Medina-Heigl Hernandez <roman@rs-labs.com> wrote:
> How does Bluecoat deal with the fact that HTTPS connections are secured
> point-to-point? If Bluecoat (or whatever) does some kind of MITM, client
> browser would detect it and HTTPS would be broken. I still don't get the
> point...
>
> Cheers,
> -Roman
>
> Jonas Andradas escribió:
>
> > Hello Roman,
> >
> > Thanks for the clarification. Indeed, if an SSL tunnel is made
> > through port 443, then anything could go in there, and it would be
> > impossible to inspect. I don''t know of any Open Source or Free
> > software that can solve this. Bluecoat does have this kind of product
> > in appliances, which act as SSL ends, inspecting all traffic, and
> > generating on the fly SSL certificates... Of course, they are not
> > cheap at all... (maybe around $20.000 each).
> >
> > Best regards,
> >
> > Jonas.
> >
> > On Dec 15, 2007 8:53 AM, Roman Medina-Heigl Hernandez <roman@rs-labs.com> wrote:
> >> Hi Jonas,
> >>
> >> I didn't explain well... L7 filtering is easily defeated by SSL-wrapping
> >> any TCP-service on 443 port so you can install a SSL'rized SSH or Squid
> >> server (for instance) on that port and use it to freely surf the net :)
> >> Your firewall will only see aparently-legit SSL connections to an
> >> aparently-legit destination port (443). Hacker win, admin loose :-)
> >>
> >> I repeat it: I don't know of any solution able to defeat this and would
> >> like to know if you have some idea to detect these more-or-less "advanced"
> >> bypass cases.
> >>
> >> Kind regards.
> >>
> >>
> >> Jonas Andradas escribió:
> >>> For Layer-7 filtering, you could check
> >>>
> >>> Application Layer Packet Classifier for Linux:
> >>> http://l7-filter.sourceforge.net/
> >>>
> >>> Kernel Iptables Layer 7: http://l7-filter.sourceforge.net/HOWTO-kernel
> >>>
> >>>
> >>> On Dec 14, 2007 6:53 PM, Roman Medina-Heigl Hernandez <roman@rs-labs.com> wrote:
> >>>> Willi Mann escribió:
> >>>>
> >>
> >>>> If you want to permit HTTPS, you have to allow CONNECT to (at least)
> >>>> 443/tcp. So it's easy to tunnel through that port and get a "clean"
> >>>> internet connection.
> >>>>
> >>>> I don't know of any solution (level 7 filtering, etc) able to defeat this
> >>>> kind of tricks.
> >>
> >> --
> >>
> >> Saludos,
> >> -Roman
> >>
> >> PGP Fingerprint:
> >> 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
> >> [Key ID: 0xEAD56742. Available at KeyServ]
> >>
>
> --
>
>
> Saludos,
> -Roman
>
> PGP Fingerprint:
> 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
> [Key ID: 0xEAD56742. Available at KeyServ]
>
Reply to: