bug: can't be used as a whitelist

[damo2929]

configuration only works as hard drop blacklist. tested with ubuntu 22.04

Works as drop all the time even when using -j REJECT ??

root@test:~# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 4 packets, 448 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcp dpt:https TLS suffix-match hostset blacklist
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:https

list contains

root@test:~# cat  /proc/net/xt_tls/hostset/blacklist

 16 google.co.uk

setting up to use as a whilelist

root@test:~# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1067 packets, 128K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED tcp dpt:https
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:https TLS suffix-match hostset blacklist
   12   720 DROP       tcp  --  any    any     anywhere             anywhere             tcp dpt:https

list configuration

root@test:~# cat  /proc/net/xt_tls/hostset/blacklist

 0 google.com

curl hangs indefinitely but should have been successful

root@test:~# curl -4 -v https://google.com
*   Trying 142.250.179.142:443...

[Lochnair]

This isn't really a bug in xt_tls per se. In your first example for blacklisting, if the packet doesn't match the TLS rule, it will continue down the chain to the accept rule, the TCP connection will be established, and the next packet will contain the TLS handshake and xt_tls can do it's thing

However in your whitelisting example there isn't a way for the TCP connection to establish, because there's no rule to let the 3-wayhandshake through.

So here's what you need to do:

sudo iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
sudo iptables -t mangle -A OUTPUT -p tcp --dport 443 -m tls --tls-host "google.com" -j MARK --set-mark 0x100
sudo iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

sudo iptables -A OUTPUT -m mark --mark 0x100 -j ACCEPT
sudo iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 443 -j DROP

What this does is accept any new TCP connections on port 443, then when the TLS handshake comes, it will go through the mangle table, if it matches your domains a firewall mark will be set and saved. Then when it and any further packets for that connection goes through the filter table it will be accepted.

I tested this locally on my laptop, so you'll have to adapt it for forwarding traffic on a router for example