Introduction & Squid ports

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Introduction & Squid ports

Nicolas Kovacs
Hi,

I'm new to this list, so let me introduce myself. I'm a 50-year old
Austrian living in Montpezat (South France), and I'm the manager of a
small IT company with a focus on Linux and free software.

I've been using Squid for a few years, but only as a transparent HTTP
proxy. Here's my blog article (in French) about that configuration on
CentOS 7:

https://blog.microlinux.fr/squid-centos/

These last two weeks I've been experimenting quite a lot with using
Squid as a transparent HTTP+HTTPS proxy. I've also written a blog
article about this setup:

https://blog.microlinux.fr/squid-https-centos/

This configuration is running quite nicely, though I still have to sand
down a few rough edges. I went through quite a lot of trial and error,
using the Squid wiki as well as a handful of tutorials I found on the
Internet.

Here's the section of my squid.conf file defining ports:

--8<-------------------------------------------------------------
# Ports du proxy
http_port 3130
http_port 3128 intercept
https_port 3129 intercept ssl-bump \
  cert=/etc/squid/ssl_cert/amandine.sandbox.lan.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
--8<-------------------------------------------------------------

And here's the corresponding section of my firewall script:

--8<-------------------------------------------------------------
# Commandes
IPT=/usr/sbin/iptables
SYS=/usr/sbin/sysctl
SERVICE=/usr/sbin/service

# Internet
IFACE_INET=enp2s0

# Réseau local
IFACE_LAN=virbr0
IFACE_LAN_IP=192.168.2.0/24

# Serveur
SERVER_IP=192.168.2.1

...

# Squid
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3128 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
  --dport 80 -j REDIRECT --to-port 3128
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3129 -j ACCEPT
$IPT -A PREROUTING -t nat -i $IFACE_LAN -p tcp ! -d $SERVER_IP \
  --dport 443 -j REDIRECT --to-port 3129
$IPT -A INPUT -p tcp -i $IFACE_LAN --dport 3130 -j ACCEPT
$IPT -A INPUT -p udp -i $IFACE_LAN --dport 3130 -j ACCEPT
--8<-------------------------------------------------------------

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

So I wonder why it wasn't possible to have something like this:

http_port 3128 transparent
https_port 3129 transparent ssl-bump

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?

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?

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

Cheers from the sunny South of France,

Niki Kovacs

--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : [hidden email]
Tél. : 04 66 63 10 32
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Introduction & Squid ports

Amos Jeffries
Administrator
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
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Introduction & Squid ports

Nicolas Kovacs
Le 11/03/2018 à 10:17, Amos Jeffries a écrit :

> 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.

Thanks very much for your detailed answer !

Cheers !

Niki

--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : [hidden email]
Tél. : 04 66 63 10 32
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users