search

Lochnair / xt_tls

Filter TLS traffic with IPtables
GNU General Public License v3.0
227 stars 45 forks source link

Reset TCP session at matching SNI #71

Open d485er opened 2 weeks ago

d485er commented 2 weeks ago

Currently, xt_tls just drops a packet if it finds a matching. Therefore https client sends TLS "client hello" several times and makes an unnessesary load. To prevent this is it possible to drop TCP connection via iptables rule or is it needed to send TCP RST packet?

Lochnair commented 2 weeks ago

To be pedantic, xt_tls doesn't drop anything by itself, it's up to the administrator to configure the firewall rules to their preference.

But yes you're likely right that you'll have to send a TCP RST to stop the client from trying again, e.g.:

sudo iptables -A OUTPUT -p tcp --dport 443 -m tls --tls-host "www.facebook.com" -j REJECT --reject-with tcp-reset
d485er commented 2 weeks ago

It's true for OUTPUT chain but not for FORWARD chain(I`ve checked it on "Red Hat 7.6" and "Ubuntu 22"). With iptables -A FORWARD -p tcp --dport 443 -m tls --tls-host "www.facebook.com" -j REJECT --reject-with tcp-reset TCP RST doesn't send. Other options like icmp-net-unreachable, icmp-proto-unreahable, icmp-host-prohibited, etc work in FORWARD chain but without impacting to client's behaviour.

d485er commented 2 days ago

Sorry, I was wrong. TCP RST is now being sent successfully. During my tests it was being dropped by the rule in the OUTPUT chain due to a misconfigured rule (on both servers).