What is SSL/HTTPS decryption detection on testfiltering.com?
When a website uses HTTPS (SSL/TLS), its traffic is encrypted. To inspect and filter web content (for policy enforcement, filtering, or security testing), the encrypted traffic must first be decrypted ("SSL decryption"). Decryption detection on testfiltering.com means that testfiltering.com will recognise when SSL decryption is successfully applied — allowing you to verify that your filter or proxy is correctly decrypting secure traffic.
How do I enable decryption detection for testfiltering.com?
Ensure you have configured your filtering/proxy solution to perform SSL/TLS decryption (inspection) for HTTPS traffic.
-
Add the shared list “testfiltering.com - allow list” to your configuration:
This is a shared, locked-down list that cannot be edited by customers.
It is provided to allow testfiltering.com’s decryption-detection mechanism to function properly.
-
There are two ways to integrate that list:
Assign it to your filtering groups (as a shared list).
if you are using a "Client filter" brand then you can add this your Client filter exceptions list or if you do not have access to this you can request your Netsweeper support team by emailing Support@netsweeper.com.
By doing so, traffic to testfiltering.com will be allowed and the decryption-detection logic will trigger correctly.
What if the test doesn’t immediately show that decryption is working?
It is possible — especially on first run — that the site does not immediately detect the decryption. In some cases you may need to run the test twice before testfiltering.com properly picks up on the rules and marks decryption as “working.”
What if I use a Client filter setup?
If you operate using the “Client filter” brand (i.e. remote filtering on client devices), you can still benefit from decryption detection. In that case:
Ask your Netsweeper support team to include “testfiltering.com - allow list” in your Client filter brand configuration, You can contact Netsweeper support by emailing support@netsweeper.com
Once included, your client devices will apply the allow-list when reaching testfiltering.com — enabling proper decryption detection for HTTPS traffic.
Who should I contact if decryption detection still fails?
If after adding the shared list and running the test twice you still see failures:
Check your proxy/filter’s SSL-inspection configuration (certificate trust, root CA, target policies).
Ensure there are no conflicting exclusions or “no-decrypt” rules that might bypass HTTPS inspection (e.g. for certain sites, IPs, or categories). This matches common practices when managing SSL decryption policies.
Contact Netsweeper support by emailing support@netsweeper.com
Does Netsweeper use contextual or inline filtering?
Netsweeper does not currently support contextual filtering or inline filtering. This approach helps reduce the risk of over blocking, improves consistency across different environments, and avoids unnecessary disruption to access to legitimate educational content.
Rather than relying on filtering methods that may increase false positives or introduce inconsistent behaviour, Netsweeper’s approach is designed to prioritise accuracy, reliability, and alignment with safeguarding requirements.
How does Encrypted Client Hello (ECH) affect detection?
Encrypted Client Hello is designed to hide domain information during the TLS handshake. This can limit visibility for filtering and security technologies unless traffic is decrypted or otherwise controlled at the network or device level.
As a result, third-party testing sites may report “Not detected” even where filtering is functioning as intended.
How do HTTP/3 and QUIC affect detection?
HTTP/3 uses QUIC over UDP, which cannot be filtered through traditional inspection methods unless QUIC is blocked or downgraded at the firewall or network edge. If QUIC is permitted, some traffic may bypass inspection, which can also lead to a “Not detected” result on third-party tests.
Why can test results differ from actual filtering behaviour?
Third-party test sites are designed to identify specific inspection or blocking behaviours. They do not always reflect the full range of filtering approaches used in production environments. For that reason, a “Not detected” result may reflect the limitations of the test rather than a failure of filtering.