xt_tls not blocking URLs in Chrome Incognito mode

[UNKOWN-MK]

I am using xt_tls to block URLs by applying an iptables rule. The rule I am using is as follows:
sudo iptables -A OUTPUT -p tcp --dport 443 -m tls --tls-host "www.facebook.com" -j DROP

The rule works as expected in Firefox, where the URL is blocked.
However, when I try to access the same URL in Chrome's Incognito mode, the URL is not blocked, and I am able to access the site.
currently i am using:
Chrome Version : 128.0.6613.119
IdeaCentre-AIO-3-24ITL6:~$ modinfo xt_tls
filename: /lib/modules/6.8.0-40-generic/updates/xt_tls.ko
alias: ipt_tls
version: 0.3.5
description: Xtables: TLS (SNI) matching
author: Nils Andreas Svee [email protected]
license: GPL
srcversion: 05C6A9AD424B405607401E8
depends: x_tables
retpoline: Y
name: xt_tls
vermagic: 6.8.0-40-generic SMP preempt mod_unload modversions
parm: max_host_sets:host set table capacity (default 8) (int)

[d485er]

Are you sure the site was opened using TCP? It might have been UDP (QUICK protocol).

[UNKOWN-MK]

Thank you for your response! I appreciate your suggestion regarding the use of TCP or UDP (QUIC protocol).

I checked and confirmed that the site is being accessed via TCP. However, I'm still encountering the same issue where the rule works in Firefox but fails in Chrome's Incognito mode.

I have attached a screenshot that shows the current behavior. Please let me know if you have any other suggestions or if I need to adjust any settings.

Thanks again for your help!

[d485er]

Unfortunately, your screenshot does not open...
I also see that sometimes blocked domain is accessible.
I've never seen problem with wget/curl, xt_tls works with them like a charm.
But Firefox, for example, uses some tricks. You can see it in my screenshot.

[Lochnair]

@UNKOWN-MK As a rule keep an eye out for ECH too, if that's in use the outer SNI will be different from the inner SNI where the domain you actually want to block is. At a glance it doesn't look like this applies to Facebook though.

It would be helpful with a packet capture from both and/or logs from xt_tls with debug logging enabled

@d485er Right, xt_tls isn't able to defragment the packets so that'll go through if the SNI isn't in the first fragment yes.
It's possibly the TCP stack in question sees the drop as packet loss and retries with lower MSS or something, hard to tell without the capture.

As far as I can tell from searching, dropping a packet from an already established connection won't remove that connection from conntrack. The alternative would be to use REJECT or possibly use connmarks to make sure any future packets get dropped too

[d485er]

In my example, SNI was exactly in the first fragment.

I attached the dump.
flibusta.pcapng.dmp