ATS 4.1.2 Forward Proxy/Cache HTTPS proxy configuration

["Peterman, Matthew D." <pe...@buckeyemail.osu.edu>]

Hello!
I’m running ATS 4.1.2 on Ubuntu 12.04.3 as a forward proxy for the caching purposes.
I’m using policy based routing in my Juniper SSG 140 (Screen OS) to route traffic to my ATS on port 8080. As of now I only have traffic destined for port 80 TCP hitting the ATS, but I would like to also direct SSL traffic there as well, but I am running into a snag. 
If I manually configure the ATS as an HTTP & HTTPS proxy on my Mac, a linux box or an iOS device, both HTTP and HTTPS traffic have no issues being proxied through the ATS, and all downloads - even iOS and Mac App store downloads cache just fine (which is a major point of this ATS setup). However, if I configure in my SSG 140 to also route both port 80 and port 443 destined traffic to the ATS (so that manual configuration is not required on devices) no SSL traffic will work anymore. Web browsers will say a secure connection could not be established. 
What can be done to replicate the behaviors being performed when an HTTPS proxy is manually defined on a device using the routing features in the SSG140, so that devices require no configuration once on the network. 
Thank you for your hard work making the Internet faster!

--
Matt Peterman
614.905.0099
peterman.48@buckeyemail.osu.edu

Re: ATS 4.1.2 Forward Proxy/Cache HTTPS proxy configuration

["Peterman, Matthew D." <pe...@buckeyemail.osu.edu>]

Leif,
Thank you for the clarification. As it turns out app downloads for iOS and Mac App store seem to be caching fine with just port 80 being routed to the ATS , so ATS is doing just what I needed.
Thank you!
Matt


--
Matt Peterman
614.905.0099
peterman.48@buckeyemail.osu.edu<ma...@buckeyemail.osu.edu>
On Jan 9, 2014, at 10:56 AM, Leif Hedstrom <zw...@apache.org>> wrote:


On Jan 8, 2014, at 3:49 PM, Peterman, Matthew D. <pe...@buckeyemail.osu.edu>> wrote:

Hello!
I’m running ATS 4.1.2 on Ubuntu 12.04.3 as a forward proxy for the caching purposes.
I’m using policy based routing in my Juniper SSG 140 (Screen OS) to route traffic to my ATS on port 8080. As of now I only have traffic destined for port 80 TCP hitting the ATS, but I would like to also direct SSL traffic there as well, but I am running into a snag.
If I manually configure the ATS as an HTTP & HTTPS proxy on my Mac, a linux box or an iOS device, both HTTP and HTTPS traffic have no issues being proxied through the ATS, and all downloads - even iOS and Mac App store downloads cache just fine (which is a major point of this ATS setup). However, if I configure in my SSG 140 to also route both port 80 and port 443 destined traffic to the ATS (so that manual configuration is not required on devices) no SSL traffic will work anymore. Web browsers will say a secure connection could not be established.
What can be done to replicate the behaviors being performed when an HTTPS proxy is manually defined on a device using the routing features in the SSG140, so that devices require no configuration once on the network.
Thank you for your hard work making the Internet faster!

There’s not much you can do. HTTPS proxy works by telling the UA where the proxy is, at which point, the UA (“client”) uses the CONNECT method to use the proxy as a simple packet forwarder. There’s no standard way of doing intercepting proxy for HTTPS; The issue, of course, is that the proxy does not know how to terminate SSL connections for all of the internet (it doesn’t have the appropriate certificates).

That much said, you might want to take a look at e.g. http://wiki.squid-cache.org/Features/SslBump . This is pretty intrusive, in that you basically make Squid act as a man-in-the-middle attacker. But this is, afaik, the only way to do intercepting HTTPS proxying that actually gets to see the payload of the packets. The Charles Proxy has a similar feature as well (http://www.charlesproxy.com). There are no open source implementations for this for ATS, afaik. It’s possible (but I have not tested), that you can make a certificate with a wildcard CN (“*”), and then allow ATS to terminate all of the internets. Since this is not a normal setup (it’s kinda evil), we have not spent any time on it (well, at least I haven’t).

Cheers,

— Leif

Re: ATS 4.1.2 Forward Proxy/Cache HTTPS proxy configuration

[Leif Hedstrom <zw...@apache.org>]

On Jan 8, 2014, at 3:49 PM, Peterman, Matthew D. <pe...@buckeyemail.osu.edu> wrote:

> Hello!
> I’m running ATS 4.1.2 on Ubuntu 12.04.3 as a forward proxy for the caching purposes.
> I’m using policy based routing in my Juniper SSG 140 (Screen OS) to route traffic to my ATS on port 8080. As of now I only have traffic destined for port 80 TCP hitting the ATS, but I would like to also direct SSL traffic there as well, but I am running into a snag. 
> If I manually configure the ATS as an HTTP & HTTPS proxy on my Mac, a linux box or an iOS device, both HTTP and HTTPS traffic have no issues being proxied through the ATS, and all downloads - even iOS and Mac App store downloads cache just fine (which is a major point of this ATS setup). However, if I configure in my SSG 140 to also route both port 80 and port 443 destined traffic to the ATS (so that manual configuration is not required on devices) no SSL traffic will work anymore. Web browsers will say a secure connection could not be established. 
> What can be done to replicate the behaviors being performed when an HTTPS proxy is manually defined on a device using the routing features in the SSG140, so that devices require no configuration once on the network. 
> Thank you for your hard work making the Internet faster!

There’s not much you can do. HTTPS proxy works by telling the UA where the proxy is, at which point, the UA (“client”) uses the CONNECT method to use the proxy as a simple packet forwarder. There’s no standard way of doing intercepting proxy for HTTPS; The issue, of course, is that the proxy does not know how to terminate SSL connections for all of the internet (it doesn’t have the appropriate certificates).

That much said, you might want to take a look at e.g. http://wiki.squid-cache.org/Features/SslBump . This is pretty intrusive, in that you basically make Squid act as a man-in-the-middle attacker. But this is, afaik, the only way to do intercepting HTTPS proxying that actually gets to see the payload of the packets. The Charles Proxy has a similar feature as well (http://www.charlesproxy.com). There are no open source implementations for this for ATS, afaik. It’s possible (but I have not tested), that you can make a certificate with a wildcard CN (“*”), and then allow ATS to terminate all of the internets. Since this is not a normal setup (it’s kinda evil), we have not spent any time on it (well, at least I haven’t).

Cheers,

— Leif