Look like I got bad request 400
Awsome solution; thanks for sharing -weird thing is that it doesnt seem to work for the Brave Browswer, i get:
This site can’t be reached
https://doubleclick.net/ is unreachable.
There's a small error in this line:
Instead it should be:
Then you shouldn't get a 400 - bad request.
A post was split to a new topic: Custom block page is not working with v5.0
For the website to be displayed correctly in Google Chrome, MS Edge, Opera, Vivaldi, Brave etc. browsers, you must change the extension from .htm to .html
I don't believe that is true. The webserver is the software that cares what the extension is.
That's fine, the
lighttpd configuration determines what file extensions it serves and what rendering engine is used to serve it.
Thanks to this post, I was able to setup my customized block page.
Any clue to get it working also for https?
I already own a nginx letsencrypt proxy with 80 and 443 ports open.
Defining the blocking page on it could be useful?
Blockpages don't work on HTTPS/TLS. You can't impersonate a TLS site (without creating a Man-In-The-MIddle attack on yourself.)
Doesn't work with the current strategy. Other products out there are able to do it, a different strategy to solve this problem must exists.
Sure, create your own Certificate Authority (and all the associated security hardening required for it) and push that CA to all the devices browsers or certificate stores and you can do it.
The only way to impersonate a TLS site is to set up an authority that has implicit trust to impersonate ANY domain they want.
Sorry, I haven't been on here in a long time... Incase you didn't find an answer:
Someone suggested below that the following is missing a forward slash at the beginning of the file location:
This was assuming that Pi-Hole knows its own location in the drive structure. You can try modifying this to match the file structure of your installation to see if that helps.
Correct, it shouldn't care what extension, especially when ".htm" is part of the HTML standard. ".htm" was used because DOS and Windows 3.1 only supported 3 character file extensions. But it appears to no longer work in the newer version of pi-hole. Instead the page is served as a download instead of a viewable page. That sounds like a bug of some sort. I also found that the block page now only appears if you put in the Pi-Hole's IP address (and only when you change the extension to ".php"). Something has changed. (Correction... it does still work with an actual 404 error with the .php extension)
Please note: I don't know much about protocol standards so be kind
Regarding blocking "https", at what point does the url lookup become encrypted? When I type in a url into my browser, I don't specifically type in an https. Shouldn't the block occur before the site has been determined to be an https site? Shouldn't any outside request be blocked through checking the block lists by url before determining if the site actually exists?
From the start. And if the domain is on the HSTS preload list or has been visited prior with HSTS headers then you won't be able to do the equivalent of a downgrade attack to disable the forced TLS.
Is anyone talking with Mozilla about legitimate DNS filtering and how it can be done with this new security concept? It sounds like it is going to undermine Pi-Hole's abilities completely.
No, it just means blockpages don't work. Which is fine, we plan to remove the feature anyways.
Edit: And STS is built in to TLS, there's no way it's coming out of being overridden.
Is there going to be a replacement for the Block pages? People like being able to have a custom page.
No, there will not be a replacement out of the box. Reason: They don't work for HTTPS/TLS sites and everyone is moving towards HTTPS/TLS so they are useless.
The only other solution is to create a man-in-the-middle attack and push your own certificate authority but you can't load certificates on to IOT devices. And leaving a certificate authority laying around is a horrendous idea.