[squid-users] split horizon dns proxy

[Amos Jeffries]

On 18/06/2015 9:23 a.m., Jeff Scarborough wrote:
> I am currently using Squid 3.1 that comes packages in RHEL 6.  I have this
> line in my config:
>   http_port 80 intercept
> 
> I have a split horizon dns.  This means if you lookup any address for my
> domain from the internet you get the address of the squid proxy server.
> However if you lookup the same name from my proxy server you get an
> internal RFC1918 IP address for the specific name.
> 
> Using squid 3.1 this works great.  A user tries to connect to a URL and by
> DNS resolution is sent to the proxy server, the proxy server then does a
> DNS lookup of the name in the URL and gets the actual address and sends the
> request to the correct place.

Sigh. Dont do that.

> 
> When I try and upgrade to anything beyond 3.2 this breaks.  I am finding
> references that intercept as of Squid 3.2 NAT is required. Reference from
> an email post in 2013:
> 
> In Squid since 3.2 if
> the original TCP details are not found in the NAT records some
> restrictions are placed on what happens with the request and response.
> 
> 
> My question is, is there anyway back to the old behavior?

No.

>  What are the restrictions mentioned?

CVE-2009-0801
 Remote attacker able to inject into proxy cache arbitrary content for
arbitrary URLs. This is then delivered by the corrupted proxy to any
client fetching that URL with full assurance that it is the original
content.

The restrictions placed on Squid are:

a) NAT errors are no longer silently ignored.

b) The IP address of the server being contacted by the client is used as
origin unstead of DNS lookup.

> 
> You may ask why I am not using the accel mode as this is quite obviously a
> reverse proxy.

Indeed.

>  The reason is I could not get accel to work with the RTSP
> server we are using.  I suspect because the Content-length returned by the
> RTSP server is invalid as it is unknown since it is streaming video and the
> length of the content is not known until a user stops the playback.

RTSP != HTTP. Squid-3.1 and older are corrupting the RTSP traffic
messages as they travel through the proxy, by injecting HTTP mandatory
header values. The RTSP software may be ignoring that or coping with it
somehow.

Squid-3.2 and later will take such unknown-length content and
Transfer-Encode it. Which will screw with RTSP in a different way.

RFC 2326 section 4.4 "Note that RTSP does not (at present) support the
HTTP/1.1 "chunked" transfer coding(see [H3.6]) and requires the presence
of the Content-Length header field."


We used to see this with ICY protocol (abuses port 80) where strange
popping sounds would be injected into the radio stream by a proxy. That
was actually the chunked encoding headers every few KB counting and
checksum'ing the payload data.

> 
> When I configure the proxy using accel I can get normal text pages back as
> expected but the video fails with TCP_MISS_ABORTED this happens on all
> version of squid.

If intercept works but accel doesn't in 3.1 and older I suspect that had
more to do with squid listening on port 80. RTSP uses port 554 and
reverse proxies by default preserve the port information.

> 
> The reason I am trying to upgrade Squid is to be able to do all of this
> using HTTPS.
> 

Now thats just jumping from the hotplate into the fire. The security
protections addded in 3.2 for plain-text messages are a tame sub-set of
the restrictions on TLS connections.


There is no hope but to convert this to an actual reverse-proxy, an
actual intercept proxy, and either way to stop RTSP going through it.
Squid supports natively HTTP/1.x, HTTPS, ICY/SHOUTcast, and FTP - all
other protocols must be transfered via HTTP CONNECT tunnels.


PS. if you want to sponsor RTSP support being added to Squid I/we are
open to it.

Amos