What's new

Pihole vs. Absolution

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Omg... 2mil domains... that’s f a lot of ads! U sure that is no duplicate?
What list you using? From where. Maybe I can increase mine if needed.
I only have around 400k and I seldom see ads. If I see any, simply blacklist them accordingly. Currently I have 41 manual blacklist.
Close to but not exactly 2 mill, no duplicates pi hole removes that.
 
Actually the pi hole dev's stated they don't block https ads because or the certificates and they didn't want to preform a man in the middle attack, plus their blocking is dns based not proxy based.

I don't want to be sounding like stepping on others toes in 'selling' their products. Based on your quotes, a couple of things said by Pi-Hole devs are simply wrong.

Btw, pixelserv-tls is not a proxy. Neither it's MITM. All are DNS based adblock we're talking about here.

The technology behind DNS based adblock is fairly simple. Everyone is about doing the same. pixelserv-tls is perhaps the most advanced piece of tech in this regard tailored for adblock. If you want to understand DNS based adblock, do some google or read the first link in my previous post.
 
I don't want to be sounding like stepping on others toes in 'selling' their products. Based on your quotes, a couple of things said by Pi-Hole devs are simply wrong.

Btw, pixelserv-tls is not a proxy. Neither it's MITM. All are DNS based adblock we're talking about here.

The technology behind DNS based adblock is fairly simple. Everyone is about doing the same. pixelserv-tls is perhaps the most advanced piece of tech in this regard tailored for adblock. If you want to understand DNS based adblock, do some google or read the first link in my previous post.
Go read their forum I could have easily miss quoted them. My new interest in about sloution is due to the fact it blocks HTTP ads.
I don't particularly care what I use aslong as it gets the job done is all I'm concerned about.
 
No, thanks. I read their wiki before. But I never used Pi-Hole, and no plan to :D
The method of pacer interception was referring to as the man in the middle attack or similar was my point even read a few posts back here and is brought up in regards to HTTPs blocking, just my point.
 
Some forum members here can do better tech education than me. I'm also not interested in a debate. So I'll stop myself here.

The same topic had been briefly run through on the OpenWRT forum among a few ppl including myself: https://forum.lede-project.org/t/adblock-support-thread/507/381

just fyi. Perhaps some of you could get a bit useful info out of it regarding MITM.
 
I've deployed and used both of them in multiple scenarios. Both work well. I like the wildcard blocking pihole does. I like the https option on ABS + pixelserv-tls.

ABS is lightweight and has a smaller physical footprint
Pihole is easier to whitelist and blacklist things as needed.

Someone mentioned a performance hit on https stuff with pihole. Thats easy to mitigate with iptables rules. Its also simple to make an openvpn instance use your pihole for dns.

Both work very well. I like not having a separate box at my mobile worksite.
 
Someone mentioned a performance hit on https stuff with pihole. Thats easy to mitigate with iptables rules.

Was that someone me? :)

You cannot mitigate with iptables rules to bring back performance. I also have doubt in benefit of using iptables rules in such case.
 
Here are the details if you anyone wants to read them.
https://discourse.pi-hole.net/t/is-there-a-point-to-use-pi-hole-at-all/5201/4
I do not consider what pixelserv-tls does a man in the middle attack. I was surprised with their point of view.

Seems to me Pi-Hole dev's have little ideas about information they've been disseminating to users for years. In that sense, their issue is bigger than the adblock dev on OpenWRT.

From Pi-Hole devs:
1. pixelserv-tls is MITM attack
2. Pi-Hole can also do HTTPS adverts if users install a cert on their own (from their Wiki/FAQ)
3. Now in this thread from Pi-Hole forum, Pi-Hole is only a DNS solution. Not serving any HTTP/HTTPS adverts.

From me:
1. Pi-Hole devs are categorically wrong about pixelserv-tls.
2. >99% wrong. It's not that Pi-Hole can simply install a cert and HTTPS magically work. LOL

Regarding #3, did Pi-Hone use or are they still using lighttpd to serve empty HTTP adverts? I don't know. I've never used Pi-Hole. I had the impression they used lighttpd to serve HTTP adverts.
 
Was that someone me? :)

You cannot mitigate with iptables rules to bring back performance. I also have doubt in benefit of using iptables rules in such case.

They explain their approach here and here...

Note that the iptables change is on the pi-hole, not on the router...
 
They explain their approach here and here...

Note that the iptables change is on the pi-hole, not on the router...

I don't see a reason why Pi-Hole devs suggested those iptables rules. Seems useless. I could be missing some crucial info about how Pi-Hole's DNS work.

Are they returning 0.0.0.0? some other ip? or something else?

If it's 0.0.0.0, client won't hit those iptables rules on Pi.

If it's other ip, then the iptables rules will reset/reject all HTTP/HTTPS. Then in the first place, Pi-Hole shall simply return 0.0.0.0 instead of doing all these extra processing on Pi and back and forth between clients and Pi.
 
Regarding #3, did Pi-Hone use or are they still using lighttpd to serve empty HTTP adverts? I don't know. I've never used Pi-Hole. I had the impression they used lighttpd to serve HTTP adverts.

I think they still use lighty...

Pixelserv-tls should run fine on a pi...

Would run really nice on ubuntu - either as a container, snap, or a dpkg instance - @kvic - have you considered that?
 
I think they still use lighty...

Pixelsrv-tls should run fine on a pi...
yeah, I would also think pixelserv-tl shall fit nicely into Pi-Hole.

Would run really nice on ubuntu - either as a container, or a metal instance - @kvic - have you considered that?

Shall work too. I encourage people in need to create such installation for others. The containers shall be minimal in size. I would bet less than 1MB if not less...
 
Shall work too. I encourage people in need to create such installation for others. The containers shall be minimal in size. I would bet less than 1MB if not less...

Container would be a decent approach - docker is supported on rasbian stretch, and makes things pretty straightforward for updates - similar approach for vps or ubuntu on a small home server or NAS (QNAP for example, supports Docker, as do other NAS vendors)
 
Was that someone me? :)

You cannot mitigate with iptables rules to bring back performance. I also have doubt in benefit of using iptables rules in such case.

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?

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.
 
Here are the details if you anyone wants to read them.
https://discourse.pi-hole.net/t/is-there-a-point-to-use-pi-hole-at-all/5201/4
I do not consider what pixelserv-tls does a man in the middle attack. I was surprised with their point of view.
I see well it would be nice if I could run ab solution on a sbc, especially if I end up getting a new router that can't run scripts like the gt-ac 5300 issue being that I need a router with atleast 6 land ports and I haven't got enough room to strap in a switch where my 88u is sitting I'm really going to miss it when I give it away.
 
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.
 
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.



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.

Angry already... lol..
In the event where they can reached your CA, your network is already compromised. It is no longer about mitm anymore... your whole network is almost GGed.
 
I saw some thing on a pi hole thread and I have to ask does ab solution support GNU Extended Regular Expressions for blocking domains?
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top