Traditionally, DNS-level filtering for SSL has been problematic because the block page SSL certificate would never match the host header requested by the browser.
https://badactor.co access would be presented with
https://someblockurl.com certificate. This would result in the end-user having to approve an SSL mismatch warning, illustrated to the right, which incidentally, is exactly what bad actors would do with DNS poisoning attacks. This makes it very difficult to train end-users when to ignore and when to heed warnings like that!
Our approach is different. By default, all TCP port 443 (used for TLS/SSL connections) that attempt to connect to the block page server are rejected (a TCP reset). This achieves the following results:
- End-user device response is immediate, so the user isn’t waiting and wondering what’s going on
- Bandwidth usage is reduced
- Device resources are never congested due to wait times
Some DNS-based SSL blocking approaches, will offer a DNS answer of
0.0.0.0 which achieves the above results as well, but then cannot present the end-user with anything helpful.
What we do want, is for the end-user to have some sort of feedback to indicate what just happened. This is where our browser extension comes in handy. To see it in action, here’s a short demonstration:
And here’s a direct link to the knowledge base article with further details and extension access.
Now you can enjoy a user-friendly SSL block page experience!