Custom 404 error page?

I’m sure this has been asked before, but I’m darned if I can find the topic :frowning:

I am using a script to build a blocklist.conf file that redirects adservers to 0.0.0.0

It currently displays the “Hmm. We’re having trouble finding that site.” message under firefox - which is better than the ads, but I would prefer to display a blank page or perhaps a page with just a “.” on it.

What is the best way to achieve this ??

Best regards and TIA
Dave

I assume that you have a HTTPS connection here. In that case, the proxy cannot send an error page. It will be generated by the browser instead.

For most of them, it simply shows that there was “a connection issue” or something else rather cryptic looking for the user. I am not aware that this can easily be changed.

So, is there no way to redirect bad https links to a meaningful page as with http ??
In places I have worked the 404 page took customers to a help page with links to contact numbers/customer service/etc.
That strikes me as something of a backward step.

BTW Yes these are HTTPS links to ad sites but there is no “proxy” on my setup, just redirection via the unbound system.

Regards,
Dave

Hi Dave,

So, is there no way to redirect bad https links to a meaningful page as with http ??

not really, as such kinds of redirections is precisely what a we are trying to avoid
by validating DNSSEC, enforcing HTTPS across all places and prevent downgrades to HTTP.

In places I have worked the 404 page took customers to a help page with links to contact numbers/customer service/etc.

Since IPFire’s web proxy is not able to intercept HTTPS/TLS connections for security
reasons (as discussed here), I am afraid you cannot display a custom
error page to your users if they are trying to reach HTTPS destinations.

That strikes me as something of a backward step.

It depends. Intercepting TLS looks like a MITM attack to clients (and servers, if they
notice TLS behaviours of their clients closely enough), opening up a huge abuse vector.
Further, it requires additional code to be executed on IPFire (currently, the Squid proxy
is compiled without SSL/TLS support), processing untrusted data.

Ultimately, adding support for this causes more security trouble than it solves.

If you want to run such a setup - I happen to administer them in professional environments -,
building dedicated server farms with secure CA storage is a better idea anyway, which goes
beyond the job of a firewall distribution.

Thanks, and best regards,
Peter Müller