lighttpd doc

[gstrauss]

What does this PR aim to accomplish?:

lighttpd doc

document how to use lighttpd with deprecated or removed pi-hole features (such as BLOCK_IPV4, BLOCK_IPV6) to pave the way for future pi-hole releases to be less-invasive with regards to overwriting the system-provided lighttpd.conf.

Link documentation PRs if any are needed to support this PR:

pi-hole/pi-hole#5066

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code and I have tested my changes.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)
6. I have checked that another pull request for this purpose does not exist.
7. I have considered, and confirmed that this submission will be valuable to others.
8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
9. I give this submission freely, and claim no ownership to its content.

---

• I have read the above and my PR is ready for review. Check this box to confirm

[netlify]

✅ Deploy Preview for pihole-docs ready!

Name	Link
🔨 Latest commit	f8bef64
🔍 Latest deploy log	https://app.netlify.com/sites/pihole-docs/deploys/6635ca38fddf9d0008b5de9c
😎 Deploy Preview	https://deploy-preview-824--pihole-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[PromoFaux]

I've not done a full read of this yet, but it may be worth adding a link the new page in the ftldns/blockingmode section under the relevant blocking mode

[gstrauss]

I've not done a full read of this yet, but it may be worth adding a link the new page in the ftldns/blockingmode section under the relevant blocking mode

Makes sense. Noted. I'll wait for some more feedback and then will make a batch of doc changes.

When I recently read the pi-hole code and wrote pihole.lua, there was a lot of code to support the older BLOCK_IPV4 and BLOCK_IPV6 modes, which are no longer the pi-hole defaults (which, e.g. serve a NULL RR 0.0.0.0). Are BLOCK_IPV4 and BLOCK_IPV6 useful? In what cases? We know that BLOCK_IPV4 and BLOCK_IPV6 are more expensive, and much more so with TLS. Would it work better if lighttpd had a way to be configured to reject unknown TLS SNI (server name indication) with a TLS alert rather than the current behavior where lighttpd serves a default certificate which does not match with client SNI? I have some ideas how to do that, but it would be more effort than my writing pihole.lua, so I do not want to embark on that if it is likely to be a waste of time.

[gstrauss]

While in the doc here, I see that there is a reference to ESNI. That has been replaced by ECH, for which support is currently available in numerous browsers, and support is actively being developed at some CDNs and in some server-side TLS libraries. Will pi-hole support generating bogus DNS RRs for ECH keys? I am still learning about ECH, too, ...

[DL6ER]

Are BLOCK_IPV4 and BLOCK_IPV6 useful? In what cases?

The default Pi-hole blocking mode (serving the null addresses) turned out to have the best cross-system compatibility (we tested Linux, Windows, Mac OS, a few Android versions, iOS, and a few embedded devices). Still, people are free to experiment themselves. The only option where they might reach the lighttpd server at all is the IP option. My personal feeling is that > 99(.9?)% of all users simply use the default option and those that customize probably want to show their own blocking page and do appropriate modifications themselves such as pointing to a local piselserv-tls instance.

That has been replaced by ECH

Do you have any reference for this? Note that TLS Encrypted Client Hello is still a standard in draft status and not fully published. Even when browser makers (Firefox in this example) and some CDNs (Cloudflare in this example) put up bold statements that ESNI is being replaced (or has already been) by ECH, this doesn't mean it is true for all. Another example where you can see this are HTTPS/SVCB DNS RR types which are in draft mode, too, but Apple decided to roll them out on all iOS powered devices.

Will pi-hole support generating bogus DNS RRs for ECH keys?

That's not a thing. Compared to ESNI, there is no DNS involved in ECH handshakes. Also, this isn't really necessary. As we can already block the first DNS query, there is no way the handshake can even occur in the first place.

[gstrauss]

That has been replaced by ECH

Do you have any reference for this?

I am not sure what references would satisfy you. Here is one from almost two years ago:
https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

Note that TLS Encrypted Client Hello is still a standard in draft status and not fully published.

Yes, ECH is still a draft. That is why I wrote the sentence:

That has been replaced by ECH, for which support is currently available in numerous browsers, and support is actively being developed at some CDNs and in some server-side TLS libraries.

"actively being developed" is the phrase I wish to highlight to you.

ECH is the successor to ESNI.
Effort is underway (underway; not even close to done!) to add support to openssl.
https://github.com/sftcd/openssl/tree/ECH-draft-13c

However, given that ESNI support is still marked experimental in browsers and to my knowledge not enabled by default (if still supported at all), is the section of the pi-hole doc referencing ESNI still relevant to non-highly-technical users?

Will pi-hole support generating bogus DNS RRs for ECH keys?

That's not a thing. Compared to ESNI, there is no DNS involved in ECH handshakes. Also, this isn't really necessary. As we can already block the first DNS query, there is no way the handshake can even occur in the first place.

Related to BLOCK_IPV4 and BLOCK_IPV6 modes, and related to strict-transport-security, this might be relevant to someone who might want to mint their own local cert and trust it in their local browsers, and possibly serve some content rather than DNS RR to 0.0.0.0.

That said ...

The default Pi-hole blocking mode (serving the null addresses) turned out to have the best cross-system compatibility (we tested Linux, Windows, Mac OS, a few Android versions, iOS, and a few embedded devices).

Thank you for that answer. I'll conclude that it is not worth pondering further unless new use cases come up.

[gstrauss]

@yubiuser would you please ask again for others to review? It is approaching a year since you last requested that others review. Thanks.