[squid-users] Introduction & Squid ports

[Amos Jeffries]

On 11/03/18 20:51, Nicolas Kovacs wrote:
> 
> This configuration works perfectly and gives me no errors or whatsoever,
> though I don't quite understand why I need all these ports. When I used
> only HTTP, I had this configuration
> 
> http_port 3128 transparent

Which receives port-80 syntax traffic.

> 
> So I wonder why it wasn't possible to have something like this:
> 
> http_port 3128 transparent

Which (still) receives port-80 syntax traffic.

> https_port 3129 transparent ssl-bump
> 

Which receives port-443 syntax traffic.

> I'm not sure about how the "intercept" mode works. As far as I
> understand, connections to port 80 get redirected to port 3128 by the
> firewall, but what then? Does "http_port 3128 intercept" mean that Squid
> redirects these again and sends them to its internal port 3130?

The "intercept" mode flag tells Squid it is receiving traffic from a NAT
system. So the IP addresses need special handling, and so does the HTTP
message syntax.

> 
> Similarly, connections to port 443 get redirected to port 3129 by the
> firewall, so far so good. But I don't understand how to read "https_port
> 3129 intercept". Again, does this mean that Squid redirects these to its
> internal port 3130, along with HTTP connections?

"https_port" -> receiving HTTP wrapped in TLS (aka HTTPS),
"3129"       -> listening on port 3129,
"intercept"  -> for traffic delivered from a NAT system.

NP: "transparent" is deprecated since it does _not_ mean *transparency*.


> 
> In short, my configuration works, but I'd like to get a better grasp on
> *how* it works.

The how is a bit complex and less important than the "what". The best
place to start IMO is RFC 7230 section 5.3, which describes the
differences in HTTP messages (ie the syntax) which are delivered to
origin servers (port 80) or to proxies (port 3128).
 <https://tools.ietf.org/html/rfc7230#section-5.3>


In your config you changed your 3128 to receiving port-80 (origin-form)
syntax with "intercept". So port 3130 was necessary to takeover
receiving of the normal proxy traffic.

The TLS wrappers on HTTPS need special handling to decrypt so that needs
another port setup to do that decryption first and HTTP message handling
after. "https_port" directive sets up a port for that.

NP: the "ssl-bump" flag does not mean simply receiving HTTPS traffic, it
means specifically decrypting HTTPS traffic destined *to another server*
- ie MITM at the TLS level. Which can be done for port-443 traffic OR
for CONNECT messages in the proxy (port-3128) syntax traffic. Thus it is
applicable on both https_port and http_port traffic respectively.


HTH
Amos