Pihole returns its pihole ip address for ‘’blocked’’ domains. HTTP ads get a blank or 1x1 pixel ad, https ads get their traffic rejected based on that ruleset. Am I reading it incorrectly?
You can set it up to work in this way. However, according to Pi-Hole wiki, they seem to suggest users to reject both HTTP and HTTPS requests through iptables.
Also my very first comment was exactly addressing to the usage scenario you just described. HTTPS requests are still slow with iptables rejection when compared to being served by
pixelserv-tls.
Regardless if someone calls pixelserv a MITM attack, there’s something to be said for questioning having a non password protected private key to a CA that you’ve trusted the root cert for on your computer. I accept the risk and very much appreciate how pixelserv-tls works.
pixelserv-tls can accept a password protected CA key.
So ideally what I could do is to tell users to create a password protected CA key by default, and prompt users to enter the password to unlock and load the CA key on every startup of
pixelserv-tls.
Having thought through the common server environments of
pixelserv-tls, I didn't go with this playbook.
Look, most users run
pixelserv-tls on a router always in 'root'ed mode of operation. I'm sure people will find entering password to unlock CA key on each launch more trouble than help as a security.
A compromised router or system isn't a MITM attack by
pixelserv-tls. Let's be very clear about it. Pi Linux can be compromised I'm sure, could we call Pi-Hole a MITM attack?
Also note that if people want your CA key to be password protected,
pixelserv-tls already supports it, and it actually supports it from the very first day two years or so ago.
So please stop calling pixelserv-tls a MITM attack from now on.