Blacklist separate blocking mode controls

[ahasbini]

Is there a way where one could define the blocking mode for the entries in the black list to be different from the blocking mode of the FTL config?

As an example to support the statement, I started off by configuring the adlist with the different lists available online. After sometime using the PiHole, I realized some entries in the query log that are candidates of blocking and so added them to the blacklist. The thing is I was hoping to set the block mode for the entries in the blacklist to be IP, while keeping the block mode for the adlist to be NULL. My thought is stemming from the idea of what if and how a user on the network tries to access a blacklisted entry, IP would be a bit more convenient as it will display an HTML page of the PiHole if the user was entering the url in the browser url bar. I think that when the user enters the url or fqdn it is "usually" without the http/https prefix, so like just entering www.example.com (instead of http://www.example.com or https://www.example.com) and then hitting enter which the browser starts first by accessing the http port and then (in some browsers) displays the "Not Secure" indicator near the url bar. Any indicators would be ignored by the user as long as the HTML page of the PiHole gets loaded and that would be clearer for the user what exactly is going on instead of seeing the browser DNS lookup failure which could mean several reasons. This could also work out if the user enters the url with https prefix as sometimes they also ignore the safety warning and continue to the website, that would still land them on the default HTML page of the PiHole which should clarify things for the user in the same manner.

Thank you for your time in reading the above.

P.S.: I recently started using PiHole and I'm enjoying it, for that I want to thank all for the efforts.

[ahasbini]

Any feedback would be appreciated, I just hope I get to read some before the topic gets closed

[Coro]

Feature requests shouldn't close automatically. This may be a forum mistake.

[Coro]

@ahasbini

My thought is stemming from the idea of what if and how a user on the network tries to access a blacklisted entry, IP would be a bit more convenient as it will display an HTML page of the PiHole if the user was entering the url in the browser url bar.

Most browsers already contains a HTTPS table. You cannot navigate to the HTTP page even when you have never visited it before. This to prevent MITM attacks earliest on.

[jfb]

@ahasbini

I just hope I get to read some before the topic gets closed

It's a feature request. It will stay open until it is either implemented or determined to be out of scope.

[DanSchaper]

@Coro

Most browsers already contains a HTTPS table.

What is HSTS Preloading

HSTS Preloading is a mechanism whereby a list of hosts that wish to enforce the use of SSL/TLS on their site is built into a browser. This list is compiled by Google and is utilised by Chrome, Firefox and Safari. These sites do not depend on the issuing of the HSTS response header to enforce the policy, instead the browser is already aware that the host requires the use of SSL/TLS before any connection or communication even takes place. This removes the opportunity an attacker has to intercept and tamper with redirects that take place over HTTP. This isn't to say that the host needs to stop issuing the HSTS response header, this must be left in place for those browsers that don't use preloaded HSTS lists.

From HSTS Preloading

[ahasbini]

Thanks for the info on HSTS. I had a go at testing it out and I believe there are different scenarios where HSTS gets triggered in my current browser (Chrome Version 90.0.4430.93).

So for example if start by entering "google.com" in the url bar, the browser first performs a GET using HTTP (extracts are from dev tools network tab: Link Address, Request Headers, Response Headers):

Link Address=http://google.com/

>> GET / HTTP/1.1
>> Host: google.com
>> Connection: keep-alive
>> Pragma: no-cache
>> Cache-Control: no-cache
>> DNT: 1
>> Upgrade-Insecure-Requests: 1
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
>> Accept-Encoding: gzip, deflate
>> Accept-Language: en-US,en;q=0.9
>> Cookie: HSID=...; OGPC=...:; SID=....; SEARCH_SAMESITE=...; SIDCC=...

<< HTTP/1.1 301 Moved Permanently
<< Location: http://www.google.com/
<< Content-Type: text/html; charset=UTF-8
<< BFCache-Opt-In: unload
<< Date: Sun, 23 May 2021 09:10:51 GMT
<< Expires: Tue, 22 Jun 2021 09:10:51 GMT
<< Cache-Control: public, max-age=2592000
<< Server: gws
<< Content-Length: 219
<< X-XSS-Protection: 0
<< X-Frame-Options: SAMEORIGIN

It is in the second request that redirects from HTTP to HTTPS (I think HSTS is triggered here):

Link Address=http://www.google.com/

>> GET / HTTP/1.1
>> DNT: 1
>> Upgrade-Insecure-Requests: 1
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

<< HTTP/1.1 307 Internal Redirect
<< Location: https://www.google.com/
<< Non-Authoritative-Reason: HSTS

I can see a similar behavior happening when I try "amazon.com" and "facebook.com".

The second behavior which I believe HSTS is being triggered from the start is when I use a one of the previous tested domains with a "www" prefix, the browser is immediately creating a TLS connection (supposedly) and adding the HTTPS prefix to the url with first request being the below:

Link Address=https://www.google.com/

>> authority: www.google.com
>> pragma: no-cache
>> cache-control: no-cache
>> sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
>> sec-ch-ua-mobile: ?0
>> dnt: 1
>> upgrade-insecure-requests: 1
>> user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
>> accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
>> x-client-data: ....
>> sec-fetch-site: none
>> sec-fetch-mode: navigate
>> sec-fetch-user: ?1
>> sec-fetch-dest: document
>> accept-language: en-US,en;q=0.9
>> cookie: HSID=...; SSID=...; APISID=...; SAPISID=...; __Secure-3PAPISID=...; OGPC=...; SID=...; __Secure-3PSID=...; SEARCH_SAMESITE=...; OTZ=...;...

<< alt-svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
<< bfcache-opt-in: unload
<< cache-control: private, max-age=0
<< content-encoding: br
<< content-length: 38005
<< content-type: text/html; charset=UTF-8
<< date: Sun, 23 May 2021 09:50:00 GMT
<< expires: -1
<< server: gws
<< set-cookie: 1P_JAR=2021-05-23-09; expires=Tue, 22-Jun-2021 09:50:00 GMT; path=/; domain=.google.com; Secure; SameSite=none
<< set-cookie: OTZ=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=www.google.com
<< set-cookie: OTZ=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.www.google.com
<< set-cookie: OTZ=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=google.com
<< set-cookie: OTZ=; expires=Mon, 01-Jan-1990 00:00:00 GMT; path=/; domain=.google.com
<< set-cookie: SIDCC=...; expires=Mon, 23-May-2022 09:50:00 GMT; path=/; domain=.google.com; priority=high
<< set-cookie: __Secure-3PSIDCC=...; expires=Mon, 23-May-2022 09:50:00 GMT; path=/; domain=.google.com; Secure; HttpOnly; priority=high; SameSite=none
<< strict-transport-security: max-age=31536000
<< x-frame-options: SAMEORIGIN
<< x-xss-protection: 0

Nevertheless, if the browser would directly start using HTTPS instead of HTTP, in my opinion it would still be clearer for the user to eventually (after bypassing some ssl warnings if needed) see the pihole "blocked page" instead of some browser error that needs a higher technical understanding:

On a side note, I realized that pi-hole lighttpd needs to be re-configured to expose SSL port for the host as a start to support showing the blocked page with HTTPS.

[DanSchaper]

@ahasbini

(after bypassing some ssl warnings if needed)

Don't train users to ignore BIG SECURITY ISSUES.

How do you know that those ssl warnings are your warnings and not someone truly phishing or stealing your users information?

[ahasbini]

I agree, in that case then one could create a Certificate Authority chain which generates certificates for the hostname and they should be installed on the personal devices to prevent this issue. That seems reasonable and achievable in a local LAN network albeit the lighttpd or some alternative might need figuring out for this to work.

[ahasbini]

@DanSchaper

How do you know that those ssl warnings are your warnings and not someone truly phishing or stealing your users information?

Actually, I agree that phishing is possible when connected in a different network that doesn't have pihole, but how could it be achieved in a local network with pihole ensuring the correct IP address in the DNS responses or even blocking any of those hostnames with phishing activity based on the adlist?