Security Basics mailing list archives
RE: Preventing tunnels through HTTPS proxies
From: "Ken Kousky" <kkousky () ip3inc com>
Date: Wed, 17 Jun 2009 20:48:03 -0400
This is really one of the most fundamental challenges information assurance faces in the coming years. IPSec end-to-end tunnels will be even more pervasive than the ubiquitous HTTPS tunnels. The only way filter and inspection technologies will be able to reside in the network, rather than on the end nodes, is to have a man-in-the-middle architecture as suggested with the dual SSL tunnels. This works for services which can tolerate the latency caused by decrypt-inspect-re-encrypt systems including email and web traffic but it won't work for real-time communications like voice and video (VoIP stuff). Very serious work needs to be done to address the collision of end-to-end crypto, a core feature of IPSec and the world of m-i-m inspection tools we've built our networks around. Even firewalls and deep packet inspection will be unable to address end-to-end crypto of real time communications. In God and VoIP traffic we trust? KWK -----Original Message----- From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Jared Curtis Sent: Wednesday, June 17, 2009 2:22 PM To: Michal Ludvig Cc: security-basics () securityfocus com Subject: Re: Preventing tunnels through HTTPS proxies If you forced all traffic through a proxy server which then would respond back with a spoofed cert for a domain signed by a local CA you could then inspect the traffic. This would be fairly resource intensive process, 2 SSL connections per session, plus generating certs on the fly, and traffic inspection. On top of all that you're being pretty nasty with your users and opening potential security issues. Of course this is a bit crazy, if you're concerned about data being pushed out via SSL-VPN then you should white list permitted IPs/domains on your proxy and/or firewall and deny traffic to all other destinations. To identify a SSL-VPN connection from a standard HTTPS connection would be difficult. It would require some research but I would suspect that a SSL-VPN connection is more active than an HTTPS session. If this is the case than you could create a process that if an SSL session sends more than X data alert you with the source and destination IPs. Once you have a "suspect" destination IP you could than investigate whether or not it's an SSL-VPN or valid HTTPS site. Of course I'm making all this up without doing any research on it, so take it with a huge grain of salt. On Tue, Jun 16, 2009 at 5:48 PM, Michal Ludvig<mludvig () logix net nz> wrote:
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. 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 ------------------------------------------------------------------------
------------------------------------------------------------------------ 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 ------------------------------------------------------------------------ __________ NOD32 4163 (20090617) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------
Current thread:
- Preventing tunnels through HTTPS proxies Michal Ludvig (Jun 17)
- Re: Preventing tunnels through HTTPS proxies Mariusz Kruk (Jun 17)
- RE: Preventing tunnels through HTTPS proxies Erik Soosalu (Jun 17)
- Re: Preventing tunnels through HTTPS proxies Morgan Reed (Jun 18)
- RE: Preventing tunnels through HTTPS proxies Erik Soosalu (Jun 18)
- RE: Preventing tunnels through HTTPS proxies Mariusz Kruk (Jun 19)
- RE: Preventing tunnels through HTTPS proxies Erik Soosalu (Jun 17)
- Re: Preventing tunnels through HTTPS proxies Mariusz Kruk (Jun 17)
- RE: Preventing tunnels through HTTPS proxies Ken Kousky (Jun 18)
- Message not available
- Re: Preventing tunnels through HTTPS proxies Aarón Mizrachi (Jun 18)
