Re: Preventing tunnels through HTTPS proxies

[Aarón Mizrachi <unmanarc () gmail com>]

On Miércoles 17 Junio 2009 17:04:20 alessandro telami escribió:
> Proxies like the ones from Blue Coat can do SSL Interception and  other
> similar things. The client is given a Certificate signed by the proxy that
> his browser will trust, so the proxy becomes an endpoint and is capable of
> decrypting the traffic. The proxy will then re encrypt the data and send it
> to the destination server, who then will present its certificate to the
> proxy (now becoming the client). The proxy receives the response back from
> the destination server, decrypt it, apply rules to it, re encrypt it with
> his own key and serve it to the original client as it were coming from the
> destination server. This goes on back and forth.
> POST requests can also be blocked at the proxy level, or allowed if they're
> destined to a trusted destination.
The problem is to define trusted destinations... can be a large scale painful 
work. 

Accepting every certificate at proxy level, as i said before, could be a 
security weakness. Otherwise, accept only the good ones*, could be very 
restrictive and could impact the usability of internet and productivity of 
your company... 

The big problem is to create a customized policy who defines who are the 
trusted sites with bad certs... 

And... even if you block post on "non-trusted" sites, you can use the user-
agent string to pass data, the URL also, or even the DNS name with a dns 
tunneling technique who receive packets encoded on subdomains requests with a 
low MTU.

Then, all strategies will be oriented on heuristics to determine a sequence of 
unusual rare events (left to be programmed by someone... i don't know a 
working solution for that issue).
-----

* good certificate acceptance policy: who are signed by a trusted CA 
organization, match the site name, is not revoked, signature is valid, and fit 
the time constraints. (I don't know if i forget something)

-
(i don't know if it exist today)
I think that "SSL proxy protocol" term need to be filled, and if it doesn't 
exist, we must promote a public protocol for that.

What i mean?
SSL where designed to be a locked p2p thing. Well, what i propose is a formal 
SSL proxy with key management support:

Client ----(SSL Proxy Protocol)------> Main Server ------(SSL)-----> Outside

Motivation:
You trust in your company and servers, and maybe your company need to protect 
you from threats like virus, spam or something badly... But SSL connection 
locks this possibility, and MitM solutions aren't completely reliable because 
they couldn't delegate the certificate acceptance to the final client.

I know that we won't see a protocol like this in a short-term.

---------------------------
(Also, i don't know if it exist today)
Then, i propose another specific alternatives on HTTPS-HTML:

Do it by Javascript or HTTP protocol (A temporary solution), you may use 
redirection inside the HTTPS.The sequence of events is like this: 

- You request a website like https://www.website.com/ from your browser
- The "mitm https proxy" checks if there is  a valid certificate or has been 
accepted before, if it's, pass it.
- If not... the proxy will send to the client a javascript html website asking 
for website confirmation and exposing the risks and reasons because the 
certificate was denied. 
- If the end-user accept the javascript popup, it will load an URL accepting 
it.  An url trigger certain certificate-domain-internalip relation as safe by 
some time period or session period. 
- Next step is a redirect to the main requested website, i prefer use HTTP 
Location header... but it could be javascript too. 

Considerations:

- You never know when a website calls: <img 
src="https://img.somedomain.com/visualvalidation.php?";>, then, this image will 
be replaced by HTML text and won't be processed by the browser, not asking the 
user for certificate acceptance.

--------
This HTTPS-HTML-Javascript solution is very easy to implement. I think that i 
could write a code for that. I really don't know if it exist yet.

> Cheers
>
> > From: unmanarc () gmail com
> > To: security-basics () securityfocus com
> > Subject: Re: Preventing tunnels through HTTPS proxies
> > Date: Wed, 17 Jun 2009 16:34:18 -0430
> > CC: mludvig () logix net nz
> >
> > On Martes 16 Junio 2009 20:18:17 Michal Ludvig escribió:
> > > Hi all,
> > >
> > > as you probably know it's very easy to bypass egress filters on a
> > > network as soon as there's an internal HTTPS proxy available. There are
> > > many packages laying around for all kinds of operating systems that
> > > make setting up a tunnel or VPN through such proxies a breeze.
> > >
> > >
> > > I wonder how to prevent these abuses? Clearly the traffic pattern for a
> > > VPN will be distinguishable from a genuine HTTPS traffic - but how to
> > > detect it? Alternatively playing a man-in-the-middle on the proxy,
> > > decrypting all the traffic, inspecting that it's indeed HTTP and
> > > encrypting back with a key signed by a private CA that all the desktops
> > > in the corporation would trust may be another option. Any other ideas?
> > >
> > >
> > > It would, in fact, be enough to learn that it was a VPN traffic
> > > afterwards, we don't necessarily need to kill the tunnel in realtime
> > > (although it would be nice). Since this kind of proxy abuse is
> > > forbidden by the company IT policy the trespasser's managers would deal
> > > with it at the HR level anyway. However net ops will have to provide
> > > some evidence.
> > >
> > >
> > > Does anyone know of any tools that can be used for this detection?
> > > Ideally something open source (or commercial but not insanely
> > > expensive) that could be used in conjunction with a Squid proxy? Other
> > > suggestions are welcome as well.
> >
> > I know that some proxies could be used for mitm and filtering, (i don't
> > remember technical details now...  its with MITM SSL technique and not
> > with "CONNECT" http proxy command as you said).
> >
> > However... the main issue is: the SSL certificate management.
> >
> > This will be extremely harmful for availability or security, or either.
> > Certificates of each page can't be handled by your browser now...
> >
> > If you block every non-accepted certificate at proxy level, the
> > availability of many websites will be dramatically affected.
> >
> > Otherwise, if you accept every certificate, secure sites like online
> > banks and webmails will be compromised. Bad enough to discard this
> > method.
> >
> > ----------------------
> >
> > And also, have in mind some things... i don't think that i will be so
> > useful.
> >
> > An attacker could even use undetectable covert channels over HTTPS using
> > the POST HTTP command.
> >
> > with the "HTTP POST" command, the attacker could send encrypted packets
> > over it, acting as a website posting some info... and then... the
> > endpoint could call a tun/tap packet writer to put the packet on a tunnel
> > virtual interface.
> >
> > The returning packets comes from http post responce... All of this looks
> > like HTTP(s) legitim traffic.
> >
> > The only pattern that you can detect is the frequency of http queries...
> > But... again, its also relative... an attacker could put a delay on his
> > http vpn system to avoid detections.
> >
> > The attacker could also open two channels.  One for posting packets and
> > one for receiving packets constantly. This connection could be a
> > simulation of a big download, but its a VPN.
> >
> > > Thanks
> > >
> > > Michal
> > >
> > > -----------------------------------------------------------------------
> > > - This list is sponsored by: InfoSec Institute
> > >
> > > Need to pass the CISSP? InfoSec Institute's CISSP Boot Camp in both
> > > Instructor-Led and Online formats is the most concentrated exam prep
> > > available. Comprehensive course materials and an expert instructor
> > > means you pass the exam. Gain a laser like insight into what is covered
> > > on the exam, with zero fluff!
> > >
> > > http://www.infosecinstitute.com/courses/cissp_bootcamp_training.html
> > > -----------------------------------------------------------------------
> > > -
> >
> > --
> > Ing. Aaron G. Mizrachi P.
> >
> > http://www.unmanarc.com
> > Mobil 1: + 58 416-6143543
> > Mobil 2: + 58 424-2412503
> > BBPIN: 0x 247066C1
>
> _________________________________________________________________
> With Windows Live, you can organise, edit, and share your photos.
> http://clk.atdmt.com/UKM/go/134665338/direct/01/

-- 
Ing. Aaron G. Mizrachi P.    

http://www.unmanarc.com
Mobil 1: + 58 416-6143543
Mobil 2: + 58 424-2412503
BBPIN: 0x 247066C1

Attachment: signature.asc
Description: This is a digitally signed message part.