Sorry to resurrect such an old thread, but I was wondering whether it is now possible with the new blocking mode in pihole 4.0, to configure pihole with pixelserv-tls? I understand that pihole devs don’t wish to implement pixelserv-tls themselves, but as far as I can tell, it should be possible for a user to implement it themselves? With the new blocking mode set to IP, am I right in thinking the pihole redirects blocked domains to the IP of the pi itself? In which case, if you have pixelserv-tls running on the pi (using ports 80 and 443), instead of the pihole webserver, you can get the benefits of quickly blocked https domains? How exactly does the IP blocking mode work in 4.0?
Thanks for the reply. Yeah I had already read that article, but I wasn't sure which ports were used by pihole in the redirect. As it is, I went ahead and tested out pihole 4.0 with pixelserv-tls, and it seems to be working, so I figured out it must keep 80 and 443.
So for anyone else interested, I don't have the pihole webserver running, and instead have the pixelserv-tls server running on my pi. The pihole has the BLOCKINGMODE=IP-NODATA-AAAA setting in /etc/pihole/pihole-FTL.conf which redirects pihole blocked domains to the pixelserv-tls server. Having installed the Pixelserv CA on my devices, and trusted it, the devices don't have to wait for a non-resolution, and instead blocked domains are almost immediately served a pixel sized nothing answer in place of the blocked domains, even for https redirects. The benefits of this should be a slight speed increase.
Having tested this for the last half hour or so, I can confirm that the pixelserv-tls servstats page show that it is working, with the accepted HTTPS counter going up by the tens as I browse, and no ads are visible.
I doubt the pihole devs will actively encourage this setup, as they don't wish pihole to act as a MITM on https requests, but if a user stumbles on this post and is aware of the advantages and disadvantages, this setup should work 
Well, I wouldn't go that far, but there is something I still don't fully understand (but I'm always willing to learn!):
In which way is the configuration with pixelserv-tls advantageous comparted to the NULL blocking mode of Pi-hole v4.0? By serving the IP address 0.0.0.0 for all A requests, no client will at all even try to load any HTTPS content. This should be even faster than serving some dummy pixel. Furthermore, it seems easier to not have to add the certificate on each client, so I'm just curious what are the benefits.
Well don't hold me to this 100%, but as I understand it, I believe with a NULL response to HTTPS requests, what is actually happening is that the request times-out and the device sees it as a handshake error. I believe this is why AB-Solution, which is the most popular ad-block software that runs on Asus-Merlin routers (and, for me, comes a close second to PiHole), recommends using it in conjunction with pixelserv-tls, rather than its out-of-the-box standard setting of null (0.0.0.0) responses. It even provides methods of downloading and combining itself with pixelserv-tls from within its own setup menu.
When the request is instead immediately answered by a pixel that is signed by a trusted CA from within your LAN, this speeds up the loading of pages with ads served via https domains. Further, with a pixel-sized response, you can also get rid of big blank spaces where ads would normally be.
To be honest, I don't know if the speed increase when compared with a NULL response will be all that noticeable. And, like you said, it certainly is more hassle to install a CA on each device that uses your network for proper HTTPS ad blocking, so whether or not it's worth it will be up to each user.
EDIT: I found the benchmarks done which show that responses using pixelserv-tls is faster than a NULL response Have a read This also has a more accurate explanation of why this is.
The way I understand it, pixelserv-tls has value in it's ability to block https requests and improve performance:
From https://kazoo.ga/pixelserv-tls-more-is-less/
With ads increasingly served over HTTPS, any adblock solutions combined with lighttpd, ngnix or any general purpose webserver won't be able to process HTTPS requests. Hence, fancy charts are increasingly only telling a diminishing story of statistics.
pixelserv-tls comes to the rescue. But some people ask why they want to redirect ad requests to a web server? They aren't interested in statistics. The same people want to keep things simple and let browsers bump into wall and continue to hit 0.0.0.0.
https://kazoo.ga/pixelserv-tls-2-1-scores-a-in-tests/ has test results. It would be a nice feature to give the user the option to enable or not enable pixelserv-tls like Diversion does. I looked into adding pixelserv-tls six months ago but hit a wall. I may take a look at the new version.
The reason that you see resistance from the developers is the way that any TLS blocking solution works.
See [ASUSWRT] Use Pixelserv CA to issue a certificate for WebGUI · kvic-z/pixelserv-tls Wiki · GitHub
In order for pixelserv-tls to operate, it has to impersonate every TLS certificate request from the client. This is bad security practice. It's also problematic in that you have to insert a self-signed Certificate Authority on each client in order to keep the clients from rightly responding that the TLS certificate they received was modified from the one expected.
4 Likes
Yeah, and I can see why you wouldn't want to be responsible for that if you don't want to. It's a perfectly reasonable stance to take from a security perspective. Although, I wouldn't go so far as to say it's "bad" per se - more, not "normal" security practice. It is breaking the usual chain of trust, and "technically" it is introducing a Man-In-The-Middle. But the key word here is trust. With any security measurements that we currently have implemented, there will always need to be an element of trust needed. As it stands, we have to trust the CAs. But this isn't always a good thing, as you only have to see that Symantec have recently been struck off as a trusted CA because of bad security practices. With pixelserv-tls, you are just instead trusting a self-generated CA on your own LAN device. Again, there is trust that needs to be had - trust that your device is safe from being hacked into. But I would argue that if you have someone on your network who is able to get into your Linux machine and get to the ca on the pi, you have much bigger problems already, anyway.
Finally, I would point out that there are several pieces of security software from legit companies that offer security by installing their own CA on your device, as, in the end, it is the only feasible way to offer protection for https traffic. Again, ultimately it comes down to trust - in this case trusting the security companies over the original CAs. In the end, I think it is up to the user to make that choice on their own, but, as with so many things, there are arguments both for and against it.
1 Like
Without wanting to trigger a new discussion, I want to express my doubts and disagree partially. I may trust you and others who can install pixelserv-tls themselves that they make their Pis difficult for intruders to enter the board. However, if we'd at any point offer an automated version of having it installed in any automated fashion alongside Pi-hole, then also the less experienced users will be able to get it up.
We are aware of quite a number of Pi-holes that are completely open to the Internet (often all ports are reachable). Shockingly, few of them even permitted login with pi/raspberry. I think I don't have to say anything more. Now imagine what may happen: If you are able to conquer a foreign Pi-hole, then the harm you can do is not that large. Assume you redirect www.paypal.com to some other server and want to grab your credentials. They will fail as the client's browser will complain loudly that the connection cannot be trusted.
Imagine now that you have a custom CA installed on all of your clients with unlimited trust. Once someone conquered the device, they can now actually steal your credentials - they can do it even locally on your device, no need to actually steal the CA as the Raspberry can itself authenticate as the requested domain.
The major problem is that one can imagine too many dangerous situations and, in my eyes, the potential benefit over our default NULL blocking just seems too small. However, I perfectly agree with
and we intentionally don't make it hard to use pixelserv-tls if you want to (it's one of the reasons why the IP blocking mode is still there).
3 Likes