Otdfbt

Currently, my IPtable indiscriminately sends all incoming request to my Squid transparent proxy. However, since I need SSL to work, I need a way to avoid intercepting SSL traffic.

Idea

1. example.com -> IP= 100.100.100.1


2. http access to example.com -> Send to Squid proxy


3. https access to example.com -> Intercept request for 100.100.100.1:443; instead of sending it to Squid proxy, redirect it back to the ip of example.com 100.100.100.1

Is it possible to do this in iptable? Thanks!

Edit: I'm adding more information about my setup.

1. End-Client


2. DNS Server


3. Squid Box

Due to specific requirement, I have to send traffic to the Squid transparent proxy using DNS redirection rather than typical router/gateway redirection.

Interception Method

• User Requests www.example.com


• DNS server points www.example.com to Squid Server


• Squid server intercepts www.example.com request

Current IP Table Rules

• Forward Port 80 to Port 3128 (Squid port)


• Forward Port 443 to Port 3128 (Squid Port)

Apparently, you are using a typical router/gateway to forward traffic to Squid, you can just forward port 80 and ignore 443 because 443 traffic will go directly, bypassing Squid.

Unfortunately, with my current setup, if I don't forward 443, any https connection will simply timeout.

The only solution now is to intercept all 443 request, map the each domain with each unique IP address, and send the request back to the original source IP.

I tried using Rinetd to forward 443 to the original website's IP address. Unfortunately, this method will forward all my 443 traffic to only 1 IP address because it won't differentiate the request IP.

For example, I map 443 to the IP of Gmail.com. When I visit https://gmail.com, it will work fine. However, if I visit https://hotmail.com, it will still send me to the IP of gmail.com

I need to find a way to map each IP with each domain so when I visit gmail.com, it will forward to the IP of gmail; when I visit hotmail.com, it will forward me to the IP of hotmail.com

What you're describing is a "transparent SSL proxy", which effectively doesn't exist (for the forward case; it could work for SSL accelerators). Let's see why:

1. The client attempts to resolve serverfault.com.


2. Your "fictitious DNS" server returns the address of the Squid box.


3. The client connects to squidbox:443 and attempts to start a TLS session.


4. 
   

   At this point, certificates need to be exchanged, etc.

   
   
   

   However…how does the Squid box know what site is really being accessed (ie what remote host to connect to)? The client doesn't tell the SSL server what site it's expecting – it relies on the server to know that already! This is part of the security features of SSL.

   
   

It's the same problem with iptables – how would it know what host the client really wanted? That information is simply not available (because the "fictitious DNS" server has thrown it away).

The only way I know to proxy SSL is via the CONNECT method; and for that, you need to specify the Squid box as an explicit proxy.

Honestly, the problem is the DNS redirect. I'm baffled about why you can't use iptables to redirect port 80 and leave 443 alone.

You can not redirect the https traffic (443) to any port, using iptables. Squid does not process https requests in transparent mode (only http):

PD: eth1 localnet and eth0 internet

You can do this: Redirect http traffic LAN (eth1) to a squid proxy transparent-port 8080 (http). In squid.conf must be the rule: http_port 8080 intercept

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080

And open 443 port to localnet

iptables -A INPUT -i eth1 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp --dport 443 -o eth0 -j ACCEPT

You can not do this: Redirect https traffic LAN (eth1) to a squid proxy non-transparent-port 3128 (https) (Fake Rule). It does not matter if in squid.conf the rule exists: http_port 3128

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 3128

Alternatives:

1. Squid-in-the-middle SSL Bump


2. Use a filtering by DNS instead of Proxy (like pi-hole). But it's slower than squid and it does not filter the protocol DNS over HTTPS