Can't block kisskh on Smoothwall

[Rob_D]

Hi all,

 

We've been asked to block kisskh on our Smoothwall, I've got the urls in a block policy, which I've moved to the top while I'm testing, and an HTTPS decrypt and inspect policy (also at the top). The Policy tester says the site should be blocked.

But when I test it, the site loads fine most of the time. Occasionally it will blocked, but then it will start working again if I close and reopen the browser.

The only thing I see in the webfilter logs is https://media.themoviedb.org whcih is blocked anyway.

 

Any ideas?

 

 

 

 

[3s-gtech]

Is it getting around your proxy entirely, perhaps due to an exception in your PAC file or similar?

[sigma]

and the mirrors?

https://kisskh.co

https://kisskh.do/
https://kisskh.com.pl
https://freehd24.site/drama/
https://kisskh-co.bitbucket.io
https://kiss-kh.my/

https://kissasia.me/

https://kisskh.asia/

 

Downloadable apps:

https://kisskh.at/

 

They all seem to have different streaming sources and players.

[Rob_D]

3 hours ago, 3s-gtech said:

Is it getting around your proxy entirely, perhaps due to an exception in your PAC file or similar?

We've got transparent proxy set up.

 

1 hour ago, sigma said:

and the mirrors?

Got  most of them in the block rule. At this point, I'd be happy to get even one of them to be blocked.

[CrootUK]

Are you blocking QUIC on firewall? and ECH catergory on filter?

Edited July 17, 2025 by CrootUK

[tom_newton]

Definitely sounds like quic/http3 

[sigma]

21 minutes ago, tom_newton said:

Definitely sounds like quic/http3 

The .co domain is behind Cloudflare, so that’s probably the case. 

[tom_newton]

Could be ech, in which case it would appear in the logs as Cloudflare-ech

[sigma]

I ran this earlier on a random film on the .co domain

 

https://urlscan.io/result/01981a01-7ddb-7777-b5bd-561c0e22fbe2/#summary

 

This is the home page 

 

https://urlscan.io/result/019819f9-8eca-7148-9723-3bfc9f68de8e/#transactions

[mavhc]

So you're not decrypting the TLS and only relying on headers and dns for filtering? Or only intercepting TCP 443 and not UDP 443?

[sigma]

After reporting most of these to Netsweeper yesterday, they are all showing as category "Copywrite Infringement" this morning.  

[Rob_D]

10 hours ago, CrootUK said:

Are you blocking QUIC on firewall? and ECH catergory on filter?

We've had QUIC blocked for a while (since the last time I had this problem), but not ECH.

 

My reading of this help article suggests that I shouldn't need to block ECH if I've got HTTPS Decrypt and inspect turned on. But blocking ECH does seem to have got it reliably blocking (and it does show cloudflare ech in the logs).

[tom_newton]

If you have D&I on then you shouldn't need to block ECH - but it's best practice to do so anyway